# The Core Taxonomy

**Kiduna Core Taxonomy · Canonical Version 1.3.8 · August 1, 2026 · the v1.3.8, v1.3.7, v1.3.6, v1.3.5, and v1.3.4 Amendments below govern; the v1.3.3 base follows verbatim and is read through them · the one-page reading is [The Final Taxonomy, Summarized](taxonomy-summary.html)**

**Status:** Canonical working taxonomy  
**Version:** 1.3.3  
**Date:** July 19, 2026

**Supersedes:** Version 1.3.2  
**Scope of this revision:** Clarifies the Field as an always-present but not necessarily continuously visible context; makes ongoing and collective Realm agency explicit; clarifies focused Panels and Scenes without prescribing a fixed Studio layout; and identifies current design terms that remain non-canonical.

---

# VERSION 1.3.8 — AMENDMENT OF AUGUST 1, 2026 (THE FINAL CANON TAXONOMY)

**Taxonomy updated.** Classification: owner-ruled structural revision — the final canon taxonomy of the application. Governs over the amendments and base below where they conflict. The functional consequences for the first release are specified in the [Initial Release Functional Specification](initial-release-functional-spec.html); the one-page reading is [The Final Taxonomy, Summarized](taxonomy-summary.html).

## 1. The eight Scenes

The application is composed of **eight canonical Scenes** — the working contexts a member moves among. Every Scene is one verb long:

- **Atlas — Discover.** Navigation and discovery: explore the space of Realms, **Inspect** anything, **Join** what admits you. Realms render clustered by relation. Atlas is where the **Gravity** algorithms live: everything is present, arranged in orbits of importance; what is far away is simply less relevant *to you, now* — when something becomes relevant (a search, a surge of attention, new activity), it comes forward and grows; the member can always pan and zoom to any orbit and override the arrangement. Atlas is read-only: nothing is edited from Atlas.
- **Studio — Create.** Where Realms take their character: **Wisdom** (the knowledge bases), **Presence** (the system prompts), **names**, **icons and interface Elements** — original SVGs, built and changed in Studio. Studio is what makes a veterans Realm different from a cricket Realm different from a politics Realm.
- **Commons — Organize.** People: who to connect with, whose Wisdom to learn from, how Relationships and collaboration form. Commons is scoped to **Realms** — Allies and Offers are met elsewhere; here the objects are the containers people share.
- **Workbench — Build.** The maker's sandbox: members implement their own **Abilities** — and the agents and automations composed from them. Workbench passes real work to **Claude Code and Codex** through the Workbench plugin (the package protocol of Create from Within); as it matures it is where members connect their own MCP servers, add small amounts of code against a clear API, and design and sequence their own loops. The more members can safely do their own things here, the better the system works — and safety is the Workbench trust model (below).
- **Forum — Govern.** Proposals, voting, allocating Resources — the governance of every Realm that has any. **Votes are never weighted by money**: every member the same weight. Releasing a duna's own token is a later Forum capability, not a launch feature (§5).
- **Exchange — Settle.** Buy Compute; move between $KIDUNA and USDC, wallet to wallet. Deliberately simple; duna tokens join when ready (§5). (Settle replaces Trade as this Scene's verb.)
- **Garden — Enjoy.** Where built things get *used*. The veteran's service, the course, the campaign tool, the rideshare, the tourism guide, the medical navigator, the store — every app the members build is entered and lived in from the Garden. Each app is a deployed **Scene**, entered through a **Portal**, rendering its experience through the composition grammar (below).
- **Vault — Store.** The wallet-shaped Scene: on-ramp, off-ramp, and storage — fiat in, $KIDUNA out, balances held. **Vault is web-only**: one place to go, deliberately.

**Scene, defined (ruled — one sense, and Portals return).** There is only one sense of the word. **A Scene is a unique area — a room, a scenario, a place — rendered in Flutter/Flame with its sprites, tiles, and interface elements: a cohesive set of Media connected to the full Kiduna stack.** A Scene is *not* "a Media system attached to a Realm" — that v1.3.4 reading is superseded; the Scene is the composed place itself. The eight canonical Scenes above are the launch set, built by the system. **Builders create their own Scenes** — in Studio and in the Workbench — and deploy them as unique ways to Enjoy or otherwise use Realms, under the Workbench trust model below (Realm containment, Builder role, inspection, Sentinel acceptance). A Garden app is exactly a deployed Scene; the composition grammar below is the interface vocabulary a Scene renders through. **Scenes connect through Portals — that is how you navigate from Scene to Scene.** This reinstates Portals, superseding their v1.3.4 elimination; the design record's portal grammar (tap to enter, the abortable crossing, press-and-hold reserved for signatures) stands.

**The Workbench trust model (ruled).** What members build in the Workbench are **Abilities** — the same Capacity the platform itself ships (Impart Abilities), now member-implemented — together with the Automations composed from them. The safety model is **Realm containment, role, and inspection**, not review boards:

- A custom Ability operates **only within the Realms where it is explicitly deployed**. There is no global deployment and no ambient capability.
- Deployment requires the **Builder role in that Realm**, and deployment is itself a named, deterministic Action.
- **The Builder and the Ability are inspectable.** Inspect returns the Ability's author, history, provenance, and reach. If you trust the Realm and you are part of it, you can trust the Ability deployed there — that is the whole trust chain, and it is the same person-vouched logic as Kinship Codes, applied to capability.
- **The plugin checks credentials.** The Claude Code / Codex seam verifies the Builder's authority at hand-off and at return, so a package can only deploy properly within its Realm.
- A Builder may make an Ability **public**: Builders in other Realms can adopt it, and inspection carries the full history wherever it travels.
- **Sentinels run the acceptance protocol** — checks for prompt injection, malicious code, and bugs — and the protocol **handshakes with the coding-agent plugin** to double-check flagged items. A returning package lands as a draft; nothing deploys until acceptance passes; violating packages quarantine as evidence, never entering as drafts or Records (the standing package-manifest rule).

What remains on this subject is engineering specification, not owner decision: the wire-level package format and the sandbox runtime, commissioned with the architecture document in the [Initial Release Functional Specification](initial-release-functional-spec.html).

**The Garden interface model (ruled): the composition grammar.** Every app renders through a **vocabulary of interface primitives** — cards, panels, lists, maps, schedules, tiles, chips, action cards — with rules for combining them; Studio (and Ki) authors app experiences by composing, and a **deterministic renderer** draws them. This is the v1.3.4 law — stable Media, dynamic composition, no preset screens — applied to the Garden, and it preserves the command boundary by construction: a grammar cannot invent an action; money and votes stay behind named commands no matter what the composition does. The primitive set is deliberately small — on the order of fifteen, ruthlessly held there. **Archetypes are the grammar's starter content, generative is its ceiling:** the launch apps (the veterans' service, the course, tourism, the store) ship as *authored compositions in the grammar* — archetype speed without archetype lock-in — and after launch Ki composes arrangements generatively *within* the grammar: Ki may arrange primitives, never invent them, and Actions always render as deterministic chips and action cards. If launch pressure ever forces hard-coding an app, it is hard-coded as a composition-in-waiting (the same data shapes), never as bespoke screens.

## 2. Surfaces are form factors

**A Surface is a form factor**, not a product: the canonical Surfaces are **Desktop web** (the Field with Ki beside it), **Mobile**, the **Chrome Sidebar** (the browser extension), and **CTV** (the connected television — the shared big screen, driven by the mobile devices in the room, several people at once). Every Scene reaches every Surface except Vault, which is web-only. The two modes remain **Chat and Live**; the official homes (kiduna.app, kiduna.studio, kiduna.express, kiduna.live, kiduna.one, kidunaverse.com) remain the entry points; [Surfaces](surfaces.html) is read through this ruling. **First-release scope (ruled): a basic version of all four Surfaces — CTV included — ships in the initial release.** No surface waits for a later wave; depth varies, presence does not.

**Allies are in every view (ruled).** The people render wherever the member is — every Scene, every Surface — and selecting an Ally opens it: who it represents, its Presence, how to engage.

**The brief's two-working-distances framing is historical.** "Studio the desktop surface / Live the mobile surface" is read through this amendment: **Studio is a Scene, not a Surface — and so is the rest of that framing.** The Surfaces are the four form factors above; what a member is doing anywhere is a Scene; starting points and journeys per Surface are design work, not canon.

## 3. The Seven Elements

The Kiduna Canon is composed of **seven Elements**: **Realms · Actors · Media · Allies · Resources · Actions · Offers.**

**Offers is admitted as the seventh Element** — a first-class thing in its own right, not a Realm kind and not folded into Resources or Actions (this supersedes v1.3.4's "Offerings are Realms"). The v1.3.7 reading stands: the Ally is the Field-visible Element and the Source stands behind it. The working definitions, plainly: Realms are what can be entered; Actors are all agents that are not Allies; Media are stable stored content — files, images, documents, structures — some of which feed the Wisdom vector stores; Allies are the members' representatives; Resources are what things cost and how they're paid for; **Actions are the deterministic, reserved operations that intelligence is never allowed to improvise** — moving money, issuing tokens, finalizing a vote — specified, typed, executed only through the command boundary; Offers are what is put forward for others to take up.

## 4. The Six Capacities (final)

The capability layer is settled at **six Capacities**, each a verb paired with what it builds:

1. **Inform with Wisdom** — the vector database: knowledge, context, what the agent knows.
2. **Instruct for Presence** — the system prompt: how the agent carries itself.
3. **Empower with Connections** — integrations: third-party systems and software the agent can reach.
4. **Enable with Automations** — deep agents, triggers, standing processes that continue without being asked twice.
5. **Impart Abilities** — skills: markdown-defined know-how the agent can be handed.
6. **Align for Coherence** — Sentinels and values: what watches the work and keeps it true.

This settles the capacity verb set and supersedes the five-capability list (Wisdom informs · Presence instructs · Abilities enable · Automations sustain · Connections reach): **Coherence joins the capability layer as its sixth member**, and Abilities and Automations are distinct on purpose — an Ability is know-how, an Automation is a standing process.

## 5. The economic rails (ruled)

**The economy is on the blockchain from day one — and the intelligence, not smart contracts, runs it.**

**The wallets are real.** Every account (Source) has a **FROST wallet**. Of the Realms: every **Organization** (DUNA) has a **Squads wallet**; **Alliances** have Squads wallets; **Institutions** have Squads wallets; **Communities and Relationships hold no wallets of their own**. Everything the economy needs happens **wallet to wallet, orchestrated by agentic AI** — with every movement a named, deterministic Action behind the command boundary.

**What is dropped is the external token platform, whole.** Launchpads with min/max raise structures; **futarchy** — pass/fail trading tokens bought with USDC, where more money buys a greater voice (rejected outright: it contradicts equal voting); automatic percent-to-DEX liquidity mechanics; founder rights to draw monthly from the treasury without a vote; a separate cryptocurrency for every project — the whole apparatus built so that the token *is* the point. None of its Solana programs are needed: **every function it performed is performed by our orchestration and deterministic systems, above the real wallets.** No new blockchain code is required to launch; the system decentralizes enforcement over time.

**Liquidity is never fragmented.** At launch there is **one currency: everything runs on $KIDUNA.** Other duna tokens arrive **when ready** — a later capability, not a launch feature (this supersedes the earlier same-day reading of this section, under which dunas released tokens from an internal ledger at launch with fixed 20/20 liquidity pairing; those release mechanics will be specified when the economy is detailed).

**The utility model is the point.** $KIDUNA pays for intelligence. The **Agency Premium**: each duna decides what its LLM costs; part of that premium flows into the duna's treasury; the waterfall distributes the rest. The value of the currency is the agency it buys, not the trading of it.

**The economy will be detailed in full** — its own document and its own nightpaper are commissioned; until then, this section and [Real Work, Real Money](real-work-real-money.html) govern. The registered/unregistered grammar and the audit trail run on the real wallets from day one.

## 6. Voting is equal

Governance voting is **never weighted by money invested or tokens held** — every member votes with the same weight, in every Realm. (This extends the standing holdings-recognition rule: no role, badge, standing — and now no voting power — ever derives from balances. It is also why futarchy-style pay-for-voice governance is rejected in §5.)

## 7. Themes — the intention layer

**Themes are not an eighth Element.** They are a cross-cutting taxonomy layer in the Kinship Graph — `hasTheme` edges applicable to Realms, Allies, and Offers. Elements say what a thing *is*; Capacities say what it *can do*; **Themes say what it's about** — the intention signal, and the organizing key for Atlas icons and discovery.

Rules in force: a **fixed top-level spine** (so the icon system stays designable) with **open-ended sub-themes** beneath it — folksonomy, promoted into the spine by Ecosystem adoption (§12); **at most three Themes per Realm**, so tagging stays a signal and not noise; Themes **aggregate up the Realm nesting**, so Atlas can answer "show me everything happening in Health across Kinship Duna"; **theme-affinity matching** is a Graph capability — Allies carry theme signals from their members' Realms, and the Graph routes introductions across them (the solar-install alliance finds the veterans' housing organization on its own). Cluster names are internal and iconographic; member-facing copy uses the plain theme names.

The spine — **26 Themes in 6 clusters**:

**People & Care** — 1. **Health & Wellbeing** (fitness, nutrition, disability, caregiving) · 2. **Mental Health & Recovery** (therapy, addiction recovery, grief) · 3. **Relationships & Family** (partnership, parenting, elders, friendship) · 4. **Service Communities** (veterans, military families, first responders)

**Society & Justice** — 5. **Justice & Solidarity** (human rights, solidarity movements, refugees, economic justice) · 6. **Civic Life & Governance** (democracy, elections, policy, public institutions) · 7. **Community & Mutual Aid** (neighborhoods, volunteering, mutual-aid networks) · 8. **Safety & Resilience** (disaster relief, preparedness, public safety)

**Culture & Play** — 9. **Arts & Culture** (music, film, visual art, performance, literature) · 10. **Heritage & Identity** (diaspora, language, indigenous communities, LGBTQ+) · 11. **Spirit & Meaning** (faith, spirituality, philosophy, mindfulness) · 12. **Sports & Recreation** (leagues, outdoors, adventure) · 13. **Games & Entertainment** (gaming, fandom, nightlife, live events) · 14. **Storytelling & Journalism** (local news, podcasts, publishing — never named "Media"; that word belongs to the Element)

**Place & Planet** — 15. **Travel & Tourism** (hospitality, destinations, guides) · 16. **Environment & Climate** (conservation, sustainability, wildlife) · 17. **Energy & Infrastructure** (solar, grid, water, broadband, transit) · 18. **Housing & Place** (housing access, placemaking, homelessness) · 19. **Food & Agriculture** (restaurants, farming, food systems) · 20. **Animals** (pets, animal welfare, rescue)

**Work & Wealth** — 21. **Work & Trades** (labor, careers, crafts, co-ops) · 22. **Business & Markets** (small business, startups, retail, professional services) · 23. **Money & Finance** (personal finance, community finance, investing)

**Knowledge & Frontier** — 24. **Education & Learning** (K-12, higher ed, skills, tutoring) · 25. **Science & Research** · 26. **Technology & Digital Life** (software, AI, privacy, digital rights)

## 8. AI-native, and done means done

The interface is **AI-native**: no fixed menus, no procedural navigation — dynamic composition under the v1.3.4 rule that everything is a prompt except deterministic Actions. And the release standard is **complete, not minimum**: the first release is judged done when the Scenes work across the Surfaces as specified — the deliberate refusal of the MVP habit is itself canon.

## 9. The canonical Realm types (final)

**Ecosystem · Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell.**

Ten types, closed by ruling. This settles the reconciliation the v1.3.7 amendment left open: **Ecosystem joins the product-level set** (Kinship Duna, the Genesis Realm, is the Ecosystem — and remains both Ecosystem and Organization per the standing v1.3.5 rule); **Offering is retired as a Realm type** (Offers is an Element, §3); **Member Realm is retired as a type** (the member's standing is carried by the Source, their wallet, and their Ally — not by a typed Realm). The definitions of Program, Cell, and Concept stand as previously amended. New Realm types only by canon amendment, as before.

## 10. The privacy hierarchy (ruled)

**An Element may carry more privacy than its context, never less.** Something marked public is only *really* public if it lives in a public Realm; within any Realm, an item can be made private or secret — but nothing inside a private or secret context can be more exposed than the context itself. Privacy composes downward: the Realm sets the floor, members may raise it item by item, and no setting can lower it. (This is the interface-facing law that the four access levels enforce architecturally.)

## 11. Connected, or not present (ruled)

**There is no offline mode.** If you are not connected, you cannot use the system. Anything available for download can be downloaded — a download is just a download, not an offline working state. This supersedes the offline-preparation language of the Studio + Live brief (offline capture, offline Action preparation, sync-conflict machinery): none of it is built.

## 12. The adoption rule (ruled)

**Any Realm can adopt anything that is public or offered to it — the Realm decides.** And when **the Ecosystem** (the Genesis Realm, Kinship Duna) adopts something through its regular governance, it becomes available everywhere. One rule covers custom Abilities, Scenes, sub-themes, vocabulary, and whatever comes: local adoption is free choice; universal standing is an Ecosystem governance act. (For Themes this settles promotion: a sub-theme joins the canonical spine when the Ecosystem adopts it — §7's "promoted when usage earns it" is read through this rule.)

## 13. The platform floors (adopted recommendation)

Recorded as the working floors, owner-adjustable: **Desktop web** — designed for 1280px and up; functional to 1024px with Ki collapsible; below that, the mobile rendering takes over. **Mobile** — iOS 16+ and Android 10 (API 29)+, 360×640 minimum, portrait primary. **CTV** — Android TV / Google TV on Android 10+, 1080p minimum. **Accessibility** — **WCAG 2.2 AA is the formal baseline**, met through Flutter semantics (VoiceOver/TalkBack names, visible focus, non-color status, reduced motion, 200% text scaling, the standing 44px touch targets); nothing formally exceeds AA at launch. The design repository (§7 note below) carries the visual floors.

**On the icon system (ruled):** the Theme icons — and all icons, symbols, and graphics across the eight Scenes — are built as **the design repository**: one consistent, growing library that populates the universe. Production work, not an open canon question.

## 14. The name (ruled)

**"Kidunaverse" is retired, everywhere and permanently. The name is Kiduna** — the system, the application, the world: one word. Rules of application: historical documents, ratified specifications, and the v1.3.3 base below keep their original wording and are **read** with the substitution; addresses and filenames keep their spellings until re-homed (kidunaverse.com remains an address, not a name — the account lives there and is called simply **the account**); no new writing uses the old word. Where the app and another home would both read "Kiduna," prefer the plain role — the app, the account, the extension.

---

# VERSION 1.3.7 — AMENDMENT OF JULY 26, 2026

**Taxonomy updated.** Classification: owner-ruled additions, from the [Studio + Live Working Design Brief v0.1](studio-live-brief.html). Governs over the amendments and base below where they conflict.

## 1. The Ally is the Field-visible Element; the Source stands behind it

A **Source** is the person in the data and governance model — literally the human. Their visible, Source-approved identity in the Field is their **Ally**: the Ally appears as an Element in the Field; the Source does not. The six Elements are accordingly read as **Realms · Actions · Resources · Media · Allies · Actors** at the Field level, with Sources remaining first-class in the data and governance model behind their Allies (refining the v1.3.4 list, which named Sources directly).

An Ally is a Source-approved visual identity of a person inside Kiduna. It is **not** a legal identity, a bot, a digital twin, an inferred psychological profile, or evidence of private activity.

## 2. Canonical Ally states

The canonical Ally states are **Open · Engaged · Focused · Dreaming**. States describe real product context and must never be inferred from biometrics, facial expression, private conversations, or hidden activity.

## 3. Concept admitted as a Realm type

The canonical Realm-type set at the product level is **Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell** — **Concept** is admitted as a first-class Realm type (the bounded context for an idea, body of thought, or theme). Base types the brief does not name (Ecosystem, Member Realm, Offering) retain their infrastructure standing; their product-level rendering is an open reconciliation item on [Open Questions](open-questions.html).

## 4. Ki speaks in the third person

Ki is the orchestration layer, not an Element in the Field, and never becomes a character, avatar, or Realm object. **Ki never refers to itself in the first person** — Ki always speaks in the third person, referring to itself as Ki, never "I."

## 5. The fourth persona is Danny

The permanent design personas are **Alice · Bob · Carol · Danny** (lineage: Alice→Bob, Carol→Danny). Danny supersedes David as the fourth persona name.

# VERSION 1.3.6 — AMENDMENT OF JULY 22, 2026 (SECOND)

**Taxonomy updated.** Classification: owner-ruled addition. Governs over the amendments and base below where they conflict.

## The Handshake (generalized)

A **Handshake** is a single-use verification word agreed **out-of-band** between two people. It is Kiduna's person-to-person verification instrument: identity is vouched by a human who knows you, never by an email provider, a phone carrier, or Kiduna itself.

Two canonical uses:

1. **Onboarding** — the Host sets a Handshake and passes it out-of-band with the one-time Kinship Code; the invitee enters both to register. (This is the "secret handshake" of the registration page — same instrument, first use.)
2. **Connecting — forming a Relationship.** When two Sources connect in the system: one asks Ki to connect, tells Ki who the other person is, and states the Handshake they agreed out-of-band. When the other Source confirms the connection, they must enter the Handshake. If they don't know it, it's not the right person, and the Relationship does not form.

Rules: **a Handshake can only be used once**; it is agreed out-of-band (Kiduna never transmits it between the parties); it is never stored beyond verification; a failed Handshake fails quietly and safely (no confirmation of who was expected). The Handshake composes with trust levels and Cloaked Sources — it verifies personhood across the boundary without disclosing identity to the system.


**Taxonomy updated.** Classification: owner-ruled additions. Governs over v1.3.4 and the base where they conflict.

1. **Presence renames Stance.** The capability layer is now: Wisdom informs · **Presence instructs** · Abilities enable · Automations sustain · Connections reach. (The word is free since Source replaced its former use; a Source's Wisdom and Presence are the two most important things they add and keep updating.)
2. **Host** — the Source who invited you; your Gen-1 upline. UI shows the Host by name or Code Name, not the word.
3. **The secret handshake** — canonical name for the single common word the Host sets and the invitee must enter (with the one-time Kinship Code) to register.
4. **Code Names are not unique.** Spaces allowed; real identity discouraged. Every Source has a GUID underneath; disambiguation is systemic, and any Source may privately rename anyone for themselves — nicknames translate via GUID. No public handles; the handle concept is retired from onboarding.
5. **Guest (additional sense):** an invited person exists in the system as a Guest until they register and become a Member.
6. **Kinship Duna is both an Ecosystem AND an Organization** — the container of everything else. **"Kiduna" is the short form of Kinship Duna**; kiduna.ai is its website.
7. **Language rule: always "in Kiduna," never "on Kiduna."**
8. **Creator/Builder default distribution:** of ongoing Compute purchases, lineage takes 18%; **the remaining 12% (relative to the initial 30%) is split by default between Creators — measured by Compute/token flow through their Wisdom and Presence — and Builders — measured by flow through their agents.** Forums may raise or lower these defaults.
9. **The Resources page** is canonical: the web-only personal nexus (kiduna.ai) — portable identity (seed phrase, key share, public key), wallet limited to $KIDUNA/USDC/Badges on Solana, on/off-ramps (Stripe in, Sphere out), earnings by category and Duna, recirculation and impact metrics, goals set conversationally with Ki (right panel; same Flutter/Flame technology; read-only in Surfaces), the invite flow and the aggregate invitee CRM (never private detail). Card payments land in the Duna bank account, move on-chain via Sphere, then distribute — lineage sees the pending cut marked "paid by card."
10. **Public member pages** reserved at kiduna.ai/code_name with "Join me in Kiduna" (placeholder).

---

# VERSION 1.3.4 — AMENDMENT OF JULY 21, 2026

**Taxonomy updated.** Classification: owner-ruled structural revision. Where this amendment conflicts with the v1.3.3 base below, **the amendment governs**. A clean full rewrite becomes v1.4.

## 1. The Six Elements

The Kiduna Canon is composed of **six Elements**: **Realms · Actions · Resources · Media · Sources · Actors.** Everything in the system is one of these six, a property attached to one, or a composition of them. "Element" now refers to these six; the v1.3.3 §7 interface "Elements" are renamed **Media components** (see §4 below).

- **Realms** — what can be entered, explored, addressed, acted within (unchanged in substance).
- **Actions** — typed, ultimately deterministic operations (unchanged in substance).
- **Resources** — what can be consumed, allocated, or drive transformation. "A Resource is really money — and money is two things: Information and Resource." Compute, USDC, wallet contents, treasury balances, capacity. **Badges are NOT Resources** (they cannot be consumed).
- **Media** — stable, stored content and structure: files, video, audio, images, documents, JSON structures, Labels, icons, lines, widgets, Panel shapes, Scene assets, Wisdom items. **Records are Media produced by Actions** (verification-bearing — this answers v1.3.3's open question about Record). **Badges are Media of the Record kind.** **Artifact survives as a Media subtype** (persistent file-like Media); the origin taxonomy (Generated · Imported · External) and verification-as-state carry to Media unchanged.
- **Sources** — **a Source is a human participant.** The term **replaces "Presence"** everywhere. All v1.3.3 §4 Presence kinds persist as Source kinds: Singular, Plural, Visitor, Guest, Member, **Cloaked Source** (Persona · Alias · Mask unchanged). The word regains its full weight: the Source is where authority originates.
- **Actors** — **all agents are Actors; the Ally/Actor type separation ends.** **Ki is the universal Actor** — one coherent Ki across Kiduna, every Source's ally in function, its relationship shaped per Source; every other Actor kind (Envoy, Operator, Sentinel, Worker, Supervisor, Integration Actors) is unchanged. Only a Source directs Ki on their own behalf; the Source-of-authority rule is untouched.

Properties, not Elements: Roles, Permissions, Privacy, Visibility, Trust, Lifecycle attach to Elements. Governance is Actions inside Realms. Treasuries are Resource collections. Offerings are Realms. Wallets and Kinship Codes are Resources.

## 2. Scenes are Media systems; Portals are eliminated

**A Scene is a Media system attached to a Realm, operated by Actors.** §9.2 (Portals) is struck: there is no entering or exiting through Portals; Scene presentation loads within a Surface as part of its Realm, under the Realm's identity, permissions, and Records.

## 3. Stable Media, dynamic composition

Media is stable and stored — a course's name (a Label), Panel shapes, defined structures persist. What the agentic system composes on the fly is the **arrangement**: which Media, which Actions, in what layout, for this Source, now. No preset screens; no fixed navigation. Two inputs feed one system — acting in the Field and talking to Ki — and everything is a prompt except deterministic Actions.

## 4. Types, Labels, and Inspect

Realm types remain canonical at the infrastructure level; any Realm may be freely **relabeled** in the UI (a Program shows as "Course," an Organization as "cell"). **Inspect is a first-class Action**: "Inspect X" works on any Element via Ki, and every Element rendered in the Field carries a clear inspect affordance returning its true type, containment, permissions, and provenance. New Realm types only by canon amendment.

## 5. New Realm type: Cell

**A Cell is a Source's four-generation downline plus their Gen-1 upline (the one who invited them).** You are in your inviter's Cell; your Cell is who you're organizing. It forms automatically as invitations are accepted ("grow your cell"); its purpose is care — people happy, productive, not stuck; it surfaces on the Organizer's Resources page (consumption and earnings); it holds **no treasury** — lineage flows are deterministic. (Cell replaces "Clan.")

## 6. Program, defined

A **Program** is a Realm organized around a sustained purpose that contains and coordinates Projects, Communities, cohorts, Actors, Media, and its own Wisdom over time. A Project delivers a defined outcome; a Program carries the purpose across many outcomes. A course is a Program wearing a different Label. (This answers v1.3.3's open question; Program is a first-class Realm type.)

## 7. Invitation and onboarding (the person-vouched identity)

Personal invitations only at launch. An invite is a **one-time link plus a Secret Code set by the inviter** (the Secret Code and the invite password are one thing). The invitee opens the link, enters their **Code Name** (the single name field — display name and call-me name collapse into it; changeable later), enters the Secret Code, sets their own password — and they're in. **No email, no mobile number, no third-party validation anywhere in onboarding: the verification is the inviter.** The inviter declares privately: who it's for, what they're invited to, the trust level, and the relationship context — never shown to the invitee, but informing greeting, presentation, and connection. This is how a Cell forms. Multiple identities and anonymity are supported (Cloaked Sources); Kinship Codes are NOT reduced by this — the full open-internet mechanism stands; inside the system, Realm containment simply makes privacy painless.

## 8. Further rulings in force

- **Launch frame:** Kiduna 1.0, August 10, the state capital. Joining auto-enrolls the Source in **Kinship Duna and Dunaversity**; beyond that automatic registration Dunaversity holds no privileged position. Invite-only at launch — the Guest concept remains canon (Realms define member and guest levels; guests pay more without upfront Compute), inactive until opened.
- **One vector database** for everything, with granular access resolved by the graph and Realm containment; Wisdom Drops are logical scopes, not separate stores. Vector · Graph (Apache AGE) · SQL remain the trio; permission is answered by the graph before any content is fetched.
- **Authorization grammar extended:** Source-set per-Action thresholds; press-and-hold duration proportional to gravity; **dual-Source hold** (two people holding simultaneously) for the gravest acts.
- **AT Protocol / DID: deferred** — removed from the trust-authority list; centralized until server software ships, then a real federation protocol.
- **AML/KYC posture (owner statement, 2026-07-21):** Stripe and Sphere carry their own KYC/AML; wallet-connect onboarding is available; due diligence with both is complete and they have cleared the systems. No Kiduna-side KYC is required for Compute or Offering purchases.
- **The public language** (cited from kiduna.ai): *The internet connected pages. Social connected profiles. **Kiduna connects agency** — people and agents organized to act together.* An ally that knows you · people worth building with · organizations that can act.

---

# THE v1.3.3 BASE (verbatim; read through the amendment above)

The Kidunaverse is a unified agentic environment composed of:

1. the **Field**;
2. **Surfaces**;
3. **Realms**;
4. **Presences**;
5. **Agents**;
6. **Agent Capabilities**;
7. **Elements**;
8. **Panels**;
9. **Scenes and Portals**;
10. **Artifacts**;
11. **Actions**;
12. **Roles**;
13. **Authority and Permissions**;
14. **Privacy and Visibility**;
15. **Trust**;
16. **Lifecycle Status**;
17. **Governance**;
18. **Offerings**;
19. **Treasuries**; and
20. **Compute**.

These are the primary elements of the Kiduna Canon, Graph, protocol, and interface.

---

# 1. The Field

The **Field** is the complete living and navigable environment of the Kidunaverse.

It includes the network's Realms, activity, agency, Wisdom, memory, relationships, Presences, work, play, and other forms of participation.

The Field is always present as the context of participation, but it does not need to be continuously visible or represented as a map. A Surface may focus attention on one Realm, Panel, Scene, conversation, or body of work while the Presence remains within the Field.

It is the way a Presence perceives, enters, explores, and acts across the network.

Anyone participating in Kiduna is participating in the Field.

The Field provides a continuous context in which:

- Realms can be entered and explored;
- Presences and Agents can be encountered;
- Artifacts and relationships can be understood;
- Actions can be initiated;
- Elements can be moved, copied, opened, or transformed;
- Panels can be placed over the current context;
- Scenes can be entered through Portals; and
- Ki remains available through voice, chat, and direct interaction.

The Field also provides continuity while:

- other Realms and their authorized Actors remain active;
- Automations and long-running Actions continue within their authority;
- Realms contribute, respond, relate, or request attention;
- changes elsewhere become relevant to the current Presence or Focus; and
- a Presence moves between focused work and broader orientation without losing context.

A Surface should make material activity or attention needs understandable and make broader context reachable. This does not require the Surface to expose every active Realm, relationship, or process at once.

The Field is not a desktop, file manager, website, or collection of disconnected applications.

It is a living, navigable, contextual environment.

A Presence does not need to navigate rigid menus or manually arrange every object. The system generates useful representations based on the Presence’s:

- current goal;
- current Realm;
- Role;
- relationships;
- permissions;
- recent activity;
- available Wisdom; and
- immediate context.

Visual interaction feeds the same agentic system as conversation.

Tapping an Element, typing into a box, moving an object, pressing a button, or speaking to Ki are all ways of providing context and initiating Actions.

The Field contextualizes everything in relation to:

- where it belongs;
- what it contains;
- what contains it;
- who may access it;
- how it is related to other things;
- what may be done with it; and
- which Agents may act within or upon it.

The Field must not imply that a Presence is the only active center of the environment. Other Realms and Presences may possess their own agency, goals, relationships, commitments, and authorized activity. Their activity remains subject to authority, permissions, privacy, visibility, policy, Trust, and the production of appropriate Records.

---

# 2. Surfaces

A **Surface** is a device-specific way of accessing the Field.

The Field is one environment. Surfaces are the different windows through which it is experienced.

A Surface determines how the Field is displayed and controlled, but it does not create a separate version of the Kidunaverse.

## 2.1 Kiduna Studio

**Kiduna Studio** is the primary Surface for desktop and laptop computers.

It is optimized for:

- building;
- creating;
- organizing;
- researching;
- coding;
- designing;
- operating complex workflows;
- managing large collections of Artifacts;
- working across multiple Realms; and
- supervising long-running work.

Studio may connect with desktop agentic systems such as:

- Claude Cowork;
- Claude Code;
- ChatGPT;
- Codex; and
- other compatible development or knowledge-work environments.

These connections may operate through:

- plugins;
- APIs;
- MCP servers;
- local services;
- command-line tools; or
- other approved interfaces.

These systems extend Studio but do not replace Ki, the Field, or Kiduna’s authority and permission model.

## 2.2 Kiduna Live

**Kiduna Live** is the primary mobile and tablet Surface for iOS and Android.

It is expected to be the way most people interact with the Kidunaverse.

Live is optimized for:

- conversation with Ki;
- navigation of the Field;
- communication;
- approvals and confirmations;
- governance participation;
- payments;
- Presence management;
- controlling other Surfaces;
- interacting with nearby Realms and Scenes; and
- receiving contextual updates.

Kiduna Live may control Kiduna TV, projectors, installations, and other connected Surfaces.

## 2.3 Kiduna TV

**Kiduna TV** is the Surface for:

- connected televisions;
- projectors;
- large displays;
- stages;
- festivals;
- concerts;
- public installations; and
- other large-screen environments.

Kiduna TV is normally controlled through Kiduna Live rather than through a conventional television remote.

It may display:

- shared Realms;
- performances;
- community gatherings;
- governance sessions;
- presentations;
- public information;
- interactive environments;
- live Agents; and
- Scenes.

Kiduna TV is not limited to conventional television interfaces. It may operate on:

- ultra-short-throw projectors;
- stage displays;
- projection mapping systems;
- installations;
- interactive walls; and
- other large-format visual systems.

## 2.4 Kiduna Express

**Kiduna Express** is the browser Surface, initially delivered through a Chrome extension with a persistent sidebar.

Express allows a Presence and Ki to navigate and act across the open internet.

It can:

- identify registered Realms and Institutions;
- display trust and verification context;
- detect relevant Kinship Codes;
- communicate with Agents operating on other websites;
- communicate through social-media accounts;
- interact with external services;
- connect browser activity to the Field;
- support safe agentic commerce;
- preserve context across websites;
- identify possible scams, impersonation, phishing, or prompt injection; and
- make Kiduna functionality available without leaving the current webpage.

Express is not a separate Kidunaverse.

It extends the Field into the browser and the open internet.

---

# 3. Realms

A **Realm** is anything that can be entered, explored, addressed, acted within, or communicated with.

A Realm may:

- contain Presences;
- contain Agents;
- contain Artifacts;
- contain Elements;
- contain other Realms;
- possess Wisdom and Stance;
- establish Roles and Permissions;
- conduct governance;
- hold resources;
- maintain a Treasury;
- make Offerings;
- act through Agents; and
- maintain relationships with other Realms.

A Realm may remain active while a Presence is focused elsewhere. Through authorized Agents, Automations, policies, and relationships, a Realm may:

- continue bounded work;
- receive and evaluate contributions;
- maintain state;
- respond to changes;
- make Proposals;
- request attention;
- coordinate with another Realm; and
- produce Records.

Ongoing Realm activity does not create independent authority. Every Agent Action must remain traceable to a Source of authority, current permissions, applicable policy, and the Realm in which the authority applies.

Realms are where work is organized and carried out.

They are generated automatically from the Canon and Graph. A Presence may organize and move things within a Realm, but the Realm is not defined by a fixed visual arrangement.

A Realm is a semantic and agentic context before it is a visual space.

Realms may be nested.

A Presence may move:

- across the Field;
- into a Realm;
- from one Realm into a nested Realm;
- between related Realms; or
- from a Realm into a Scene through a Portal.

Elements may be moved, copied, or referenced across Realms, subject to:

- authority;
- permissions;
- privacy;
- visibility;
- custody;
- provenance; and
- Realm policy.

## 3.1 Realm Types

### Ecosystem

An **Ecosystem** is a broad Realm within which other Realms coordinate through shared:

- infrastructure;
- protocols;
- standards;
- markets;
- services;
- identity systems;
- trust systems; or
- governance.

An Ecosystem may contain:

- Institutions;
- Organizations;
- Alliances;
- Communities;
- Projects;
- Offerings;
- relationships;
- shared Agents;
- shared Treasuries; and
- shared resources.

### Institution

An **Institution** is a particularly significant Realm representing an established external legal, civic, educational, commercial, financial, or social entity.

Examples include:

- governments;
- universities;
- corporations;
- foundations;
- courts;
- banks;
- standards bodies;
- public agencies; and
- other recognized legal or institutional entities.

An Institution may:

- control verified domains;
- issue credentials;
- exercise legal authority;
- maintain authoritative records;
- enter agreements;
- delegate authority; and
- interact with other Realms through authorized Agents.

### Organization

An **Organization** is a coordinated Realm with its own:

- identity;
- membership;
- governance;
- Treasury;
- policies;
- Agents;
- Offerings; and
- operations.

A DUNA is one legal form an Organization may take.

### Alliance

An **Alliance** is a Realm in which multiple Presences or Realms coordinate around a shared objective without necessarily forming a new Organization.

An Alliance may be:

- temporary;
- recurring; or
- permanent.

An Alliance may have:

- members;
- Roles;
- Agents;
- Artifacts;
- a shared Treasury;
- lightweight governance;
- agreements; and
- projects.

### Community

A **Community** is a Realm formed primarily around shared:

- identity;
- affinity;
- interest;
- practice;
- experience;
- place; or
- relationship.

### Project

A **Project** is a Realm organized around a defined body of work, goal, problem, or outcome.

A Project may contain:

- participants;
- Roles;
- tasks;
- Agents;
- Artifacts;
- budgets;
- milestones;
- decisions;
- Automations;
- Offerings;
- a Treasury; and
- related Projects.

### Relationship

A **Relationship** is a Realm representing a persistent connection among two or more Presences or Realms.

A Relationship may contain:

- history;
- commitments;
- conversations;
- permissions;
- shared Artifacts;
- obligations;
- agreements;
- Agents;
- memories;
- goals; and
- accumulated context.

### Member Realm

Every known member may have a personal Realm.

A Member Realm may contain:

- the member’s Presence;
- Ki’s context for that member;
- private and secret Artifacts;
- personal relationships;
- connected accounts;
- goals;
- memories;
- Automations;
- permissions;
- a personal Treasury; and
- nested Realms.

The Member Realm is distinct from the Presence through which the member appears.

### Offering

An **Offering** may itself be represented as a Realm.

This allows a Presence to enter the Offering and:

- explore its terms;
- communicate with its Agents;
- inspect related Artifacts;
- make selections;
- negotiate;
- purchase;
- subscribe; or
- participate.

### Other Realm Types

Additional Realm types may include:

- events;
- gatherings;
- agreements;
- campaigns;
- funds;
- properties;
- causes;
- products;
- services;
- domains;
- public spaces;
- games;
- performances; and
- programs.

A new Realm type should be created when something requires persistent:

- context;
- containment;
- relationships;
- communication;
- authority;
- identity;
- resources; or
- agency.

---

# 4. Presences

A **Presence** is the way a person, group, or Realm appears and participates in a particular context.

Presence replaces the general use of terms such as “user” or “persona.”

A Presence may be:

- singular;
- plural;
- identified;
- unidentified;
- public;
- private;
- cloaked;
- temporary; or
- persistent.

A person may maintain continuity across contexts while appearing differently within each Realm.

A Presence may have different:

- Roles;
- permissions;
- names;
- visibility;
- attributes;
- representations;
- relationships; and
- trust levels

in different Realms.

A Presence is not necessarily a separate underlying identity. It is the contextual manifestation of an identity or collective within the Field.

## 4.1 Singular Presence

A **Singular Presence** represents one person or independently acting entity.

## 4.2 Plural Presence

A **Plural Presence** represents multiple people or entities acting together.

Examples include:

- a team;
- an Organization;
- an Alliance;
- a household;
- a delegation;
- a council; or
- another coordinated group.

A Plural Presence may act through:

- an authorized Agent;
- a designated Role;
- delegated authority;
- governance; or
- the combined authority of its participants.

## 4.3 Visitor

A **Visitor** is a Presence whose underlying identity has not been authenticated.

A Visitor may enter through:

- a public website;
- a chatbot;
- email;
- social media;
- a public Scene;
- Kiduna Express; or
- another external channel.

The system should treat a Visitor as a continuing Presence when continuity can be established safely and legitimately.

Continuity may be based on:

- a social-media account;
- an email address;
- a browser or device identifier;
- a prior conversation;
- a cryptographic identifier;
- an IP address;
- answers to identifying questions; or
- other available signals.

The purpose of continuity is to improve support, context, and capability—not to build advertising profiles or target the Visitor for marketing.

Information associated with a Visitor remains subject to:

- privacy;
- consent;
- retention rules;
- disclosure restrictions; and
- applicable law.

## 4.4 Guest

A **Guest** is an identified and authenticated Presence that is not a member of the current Realm.

A Guest may be permitted to:

- view;
- ask questions;
- communicate;
- attend;
- purchase;
- use designated services; or
- contribute in explicitly authorized ways.

A Guest has no inherent right to add Artifacts, Elements, Wisdom, context, or other material to the current Realm.

The Realm may grant a Guest limited contribution permissions through:

- a Role;
- an invitation;
- a policy; or
- a specific authorization.

A Guest does not receive the baseline rights, privileges, or governance authority granted to Members of the Realm.

## 4.5 Member

A **Member** is a Presence recognized as a member of the current Realm.

Membership provides the baseline rights established by the Realm.

These may include:

- voting;
- proposing;
- participating in governance;
- adding to the Realm;
- creating Artifacts;
- using Agents;
- holding Compute;
- receiving distributions; and
- assuming additional Roles.

A Member’s actual authority is determined by the Realm’s policies rather than by a universal definition of membership.

## 4.6 Cloaked Presence

A **Cloaked Presence** is a Presence whose underlying identity is concealed from one or more audiences.

A Cloaked Presence assumes a **Persona** and appears under an **Alias**.

The Persona may include:

- an Alias;
- an image or visual form;
- a voice;
- a profile;
- selected credentials;
- selected relationships;
- a history;
- a reputation; and
- context-specific disclosures.

The connection between a Cloaked Presence and its underlying identity is governed by a **Mask**.

The Mask determines:

- who may know the underlying identity;
- which attributes may be proven without disclosure;
- whether trust or reputation carries across contexts;
- what Actions may be taken;
- what records are linked;
- when the Cloaked Presence expires; and
- under what authority the Presence may be unmasked.

A Cloaked Presence should not be treated as a different person unless it represents a genuinely distinct legal or collective identity.

---

# 5. Ki and Agents

An **Agent** is a software entity capable of:

- perceiving context;
- reasoning;
- communicating; and
- taking Actions.

Every Agent acts from a **Source** of authority.

## 5.1 Ki

**Ki is the Ally.**

There is one coherent Ally across the Kidunaverse rather than a collection of fictional personal assistants presented as unrelated characters.

Ki is available to every Presence.

Ki’s relationship, context, permissions, memories, Stance, and available Wisdom differ according to:

- the Presence;
- the Realm;
- the current Role;
- privacy;
- permissions;
- relationships;
- active goals; and
- available Connections.

A member may shape how Ki works with them by changing:

- Ki’s Stance as it applies to them;
- their personal context;
- available Wisdom;
- memories;
- preferred interaction patterns;
- connected accounts;
- permissions;
- goals; and
- Automations.

These changes personalize the relationship without creating the illusion that each configuration is a completely separate Ally.

Ki knows what is:

- public;
- private;
- personal;
- secret;
- Realm-specific;
- relationship-specific; and
- unavailable in the current context.

Ki must not disclose or use information outside the permissions and context through which it was obtained.

Ki may reflect Wisdom contributed by multiple Presences or Realms only within the permissions, purpose, and disclosure rules that govern that Wisdom. Ki must not reveal private or personal contributions, imply access that an Organization or administrator does not possess, invent consensus, erase attributable disagreement, or convert a person's relationship with Ki into a surveillance channel.

Ki may communicate through every Surface and may help a Presence:

- understand information;
- make decisions;
- communicate;
- coordinate with others;
- operate tools and accounts;
- participate in governance;
- manage long-running work;
- supervise Actors;
- navigate the Field; and
- move between Realms and Scenes.

## 5.2 Actors

Every Agent other than Ki is an **Actor**.

Actors perform defined functions for Presences or Realms.

### Envoy

An **Envoy** represents a Presence or Realm in:

- deliberation;
- negotiation;
- governance;
- voting;
- decision markets;
- diplomacy; or
- other interactions.

An Envoy exercises delegated authority but does not originate that authority.

### Operator

An **Operator** operates systems, services, infrastructure, accounts, workflows, or resources.

### Sentinel

A **Sentinel** observes:

- relationships;
- risks;
- permissions;
- system integrity;
- trust;
- safety;
- coherence; and
- compliance with policy.

A Sentinel may:

- advise;
- intervene;
- restrict;
- redirect; or
- escalate

within its assigned authority.

### Worker

A **Worker** performs bounded productive work such as:

- research;
- drafting;
- analysis;
- coding;
- design;
- administration;
- moderation; or
- production.

### Supervisor

A **Supervisor** coordinates, evaluates, directs, or approves the work of other Actors.

### Integration Actor

An **Integration Actor** represents or operates an external service or communication channel.

Examples include:

- Gmail Actor;
- Bluesky Actor;
- Calendar Actor;
- Browser Actor;
- GitHub Actor;
- Payment Actor; and
- Research Actor.

An Integration Actor remains subject to the same authority and permission model as any other Actor.

---

# 6. Agent Capabilities

Every Agent may possess five primary capability layers.

## 6.1 Wisdom — What the Agent Knows

**Wisdom** is the information and context available to an Agent.

It may include:

- documents;
- memory;
- conversations;
- structured records;
- knowledge graphs;
- vector databases;
- relationship history;
- policies;
- Realm context; and
- current situational context.

Wisdom informs the Agent.

## 6.2 Stance — How the Agent Approaches Its Work

**Stance** defines the Agent’s:

- mission;
- values;
- priorities;
- obligations;
- loyalties;
- boundaries;
- operating principles;
- professional standards;
- system instructions; and
- prohibited behavior.

Stance instructs the Agent.

## 6.3 Abilities — What the Agent Knows How to Do

**Abilities** are reusable capabilities, tools, procedures, and skills.

Examples include:

- research;
- writing;
- negotiation;
- coding;
- design;
- financial analysis;
- governance participation;
- communication;
- planning; and
- operating external applications.

Abilities enable the Agent.

## 6.4 Automations — What the Agent Can Continue Doing

**Automations** are:

- triggers;
- schedules;
- loops;
- harnesses;
- workflows;
- recurring processes;
- condition watches; and
- long-running Actions.

Automations sustain and trigger activity.

## 6.5 Connections — What the Agent Can Reach

**Connections** provide access to:

- accounts;
- APIs;
- MCP servers;
- databases;
- wallets;
- bank accounts;
- external applications;
- devices;
- communication services; and
- other systems.

Connections extend reach but do not independently grant authority.

Every use of a Connection remains subject to:

- permissions;
- privacy;
- visibility;
- Role;
- Realm policy; and
- the Source of authority.

---

# 7. Elements

An **Element** is a system-native visual or interactive representation that may appear in:

- the Field;
- a Realm; or
- a Panel.

Elements are part of the Kiduna interaction system.

They may represent:

- Realms;
- Presences;
- Agents;
- Artifacts;
- Actions;
- relationships;
- status;
- trust;
- choices;
- information;
- controls; or
- context.

Elements may be:

- generated automatically;
- placed manually;
- moved;
- copied;
- transformed;
- grouped;
- connected;
- opened;
- collapsed;
- inspected; or
- acted upon.

An Element may be moved or copied between Realms by dragging it across the Field, subject to permission and privacy rules.

Moving an Element may change its location or context.

Copying an Element may create:

- another representation;
- a reference;
- a linked instance; or
- a new underlying object.

The system must clearly distinguish between:

- moving a representation;
- copying a representation;
- moving the underlying object;
- copying the underlying object; and
- creating a reference.

## 7.1 Element Types

### Icon

An **Icon** is a compact visual symbol representing an object, Action, state, Agent, Realm, or capability.

### Label

A **Label** is a textual identifier or annotation attached to another Element or location.

A Label may display:

- name;
- type;
- status;
- Role;
- trust;
- privacy;
- ownership;
- relationship; or
- other concise context.

### Shape

A **Shape** is a visual container or object used to represent, group, emphasize, or organize information.

Shapes may carry semantic meaning and are not merely decorative.

### Connector

A **Connector** visually represents a:

- relationship;
- flow;
- dependency;
- authority path;
- lineage;
- communication channel;
- transfer; or
- navigation path.

A Connector should express the type and direction of the relationship it represents.

### Widget

A **Widget** is an interactive Element that displays information or allows a Presence to provide input or initiate an Action.

Examples include:

- buttons;
- forms;
- sliders;
- voting controls;
- charts;
- media players;
- approval controls;
- message composers;
- inspectors;
- timelines; and
- status displays.

## 7.2 Element System

New Element types may be created and added to Kiduna, but they must conform to the system specification.

The specification may govern:

- typography;
- color;
- spacing;
- scale;
- movement;
- responsiveness;
- accessibility;
- interaction;
- trust representation;
- privacy representation;
- confirmation behavior; and
- semantic meaning.

This allows the system to expand without becoming visually or behaviorally incoherent.

---

# 8. Panels

A **Panel** is an organized group of Elements presented in front of the Field or current Realm.

A Panel does not replace the current context. It overlays it.

A Panel may become the visually dominant place of focused work without causing the Presence to leave the Field or current Realm. A conversational or work Panel may therefore occupy most of a Surface while the larger context remains available through continuity, context signals, and an explicit path back to broader orientation.

Panel dominance is an attention treatment, not a change in semantic containment, authority, privacy, visibility, or Realm membership.

A Panel may be:

- fixed;
- movable;
- collapsible;
- temporary;
- persistent;
- contextual;
- personal; or
- shared.

## 8.1 Panel Transparency

A Panel exists on a continuum between **Opaque** and **Clear**.

### Opaque

The Panel visually dominates or obscures the Field or Realm behind it.

### Clear

The Panel allows the Field or Realm to remain fully visible.

### Translucent

The Panel partially reveals the Field or Realm while retaining its own visual organization.

The system should understand Panel opacity as part of attention and interaction.

For example:

- a highly opaque Panel indicates that the Presence is primarily working within the Panel;
- a translucent Panel indicates simultaneous attention to the Panel and underlying Realm; and
- a clear Panel may provide lightweight controls without interrupting the Field.

Opacity may affect presentation and contextual emphasis, but it must not silently change:

- permissions;
- authority;
- privacy;
- visibility; or
- data access.

---

# 9. Scenes and Portals

## 9.1 Scenes

A **Scene** is a bounded visual or interactive environment that runs within a Surface.

Scenes may use:

- isometric environments;
- tiles;
- sprites;
- game objects;
- custom interfaces;
- generated imagery;
- imported assets;
- animation;
- sound;
- spatial interaction; and
- their own visual systems.

A Scene does not need to conform visually to the general design language of the Field, Realms, Panels, or system Elements.

A Scene is used when a bounded visual, spatial, interactive, simulated, performative, or game-like environment materially improves understanding or participation. A Scene may be used frequently even when a broad visual presentation of the Field is used rarely.

A Scene is not the Field itself, a general map of the network, or merely a larger Panel. Its bounded behavior, visual system, state, and entry or exit conditions distinguish it from the surrounding Realm and Surface.

A Scene may function like a self-contained:

- application;
- game;
- simulation;
- performance;
- installation; or
- experience.

Scenes remain connected to the Kidunaverse’s:

- identity;
- Agents;
- permissions;
- Actions;
- Artifacts;
- Compute;
- Treasuries;
- governance;
- trust;
- privacy; and
- event systems.

A Scene must load within a Surface.

It does not exist as a separate access layer outside the Field.

## 9.2 Portals

A **Portal** is an explicit connection between:

- a Realm and a Scene;
- a Scene and a Realm; or
- two Scenes.

A Presence enters or leaves a Scene through a defined Portal.

A Realm connected to a Scene should provide:

- a Portal into the Scene;
- a corresponding route back;
- clear identity and authority context;
- the permissions that apply inside the Scene; and
- continuity of relevant state.

A Portal may preserve or transform:

- Presence;
- Role;
- permissions;
- representation;
- inventory;
- context;
- progress; and
- Realm relationships.

Any transformation must be explicit and governed by policy.

Leaving a Scene through a Portal should preserve the relevant conversation, selected Elements, Records, permissions, and return context unless policy or the nature of the Scene requires an explicit transformation or reset.

---

# 10. Artifacts

An **Artifact** is a persistent object containing information, media, code, configuration, evidence, or work product.

Examples include:

- documents;
- webpages;
- websites;
- images;
- video;
- audio;
- messages;
- social posts;
- datasets;
- software;
- proposals;
- agreements;
- Agent configurations;
- Scenes;
- maps;
- models; and
- recordings.

## 10.1 Artifact Origin

### Generated

Created within Kiduna by a Presence, Agent, or system process.

### Imported

Brought into Kiduna from an outside source.

### External

Remains outside Kiduna but is referenced or accessed through a Connection.

Examples include:

- a public webpage;
- a Google Drive file;
- a GitHub repository; or
- an external database record.

## 10.2 Verification

**Verification** is a state, not an origin type.

An Artifact may be verified for:

- provenance;
- authorship;
- integrity;
- timestamp;
- custody;
- source;
- authority; or
- correspondence with an external record.

Verification may use:

- hashes;
- signatures;
- Kinship Codes;
- registry records;
- attestations; or
- other forms of proof.

---

# 11. Actions

An **Action** is a typed operation that:

- changes state;
- creates something;
- communicates;
- transfers value;
- exercises authority; or
- affects a Presence, Realm, Agent, Artifact, Treasury, or external system.

Examples include:

- create;
- invite;
- message;
- seek;
- research;
- build;
- publish;
- post;
- email;
- connect;
- trade;
- buy;
- sell;
- offer;
- accept;
- pay;
- transfer;
- register;
- vote;
- delegate;
- appoint;
- approve;
- enter;
- move;
- copy; and
- execute.

Actions should be expressed as specific domain commands rather than broad technical CRUD operations.

Examples include:

- `enter_realm`
- `assume_role`
- `create_artifact`
- `move_element`
- `copy_element`
- `enter_scene`
- `send_email`
- `invite_member`
- `submit_proposal`
- `purchase_compute`
- `propose_treasury_payment`
- `sign_wallet_transaction`
- `delegate_authority`
- `request_attention`
- `contribute_wisdom`
- `relate_realms`

Each Action should declare:

- the acting Agent;
- the Presence or Realm represented;
- the Source of authority;
- the current Realm;
- the applicable Role;
- the target;
- the required permissions;
- the applicable policies;
- the inputs;
- the expected effects;
- reversibility;
- risk level;
- confirmation requirements; and
- the resulting event or record.

The reasoning that proposes an Action may be probabilistic.

Execution must be:

- deterministic;
- authorized;
- auditable; and
- event-producing.

An Action performed while the affected Presence is focused elsewhere must still satisfy the same authorization, audit, visibility, notification, recovery, and Record requirements as an Action performed in the foreground.

---

# 12. Roles

A **Role** is a contextual position held by a Presence within a Realm.

A Presence may hold:

- multiple Roles in one Realm;
- different Roles in different Realms;
- temporary Roles;
- elected Roles;
- appointed Roles;
- earned Roles; or
- paid Roles.

Roles are Realm-specific unless explicitly federated across Realms.

A Role may determine:

- goals;
- responsibilities;
- permissions;
- visibility;
- authority;
- compensation;
- eligibility;
- expectations;
- reporting relationships; and
- governance rights.

Roles do not imply access to private or secret information unless that access is explicitly granted.

## 12.1 Baseline Participation Roles

### Visitor

A Visitor is an unidentified or unauthenticated Presence.

### Guest

A Guest is an identified and authenticated Presence that is not a member of the current Realm.

Guest permissions are limited to those explicitly granted by the Realm.

### Member

A Member is a Presence holding the baseline rights of membership in the current Realm.

## 12.2 Contribution Roles

### Creator

A **Creator** adds or develops non-code elements of the system.

A Creator may contribute:

- Wisdom;
- Stances;
- memories;
- context;
- Artifacts;
- Agents;
- Automations;
- Connections;
- Realm content;
- visual Elements; and
- operating configurations.

Creators may build extensively within the system without changing the software codebase.

### Builder

A **Builder** creates or modifies software.

A Builder may contribute through:

- APIs;
- MCP servers;
- plugins;
- integrations;
- applications;
- repositories;
- GitHub;
- infrastructure; or
- the Kiduna codebase.

### Catalyst

A **Catalyst** forms or initiates a new Realm.

A Catalyst may:

- establish the Realm’s initial purpose;
- recruit initial participants;
- assign initial Roles;
- configure initial governance;
- establish initial Stance;
- initiate funding or Compute;
- appoint initial Actors; and
- guide the Realm through formation.

Catalyst is a leadership Role, but its continuing authority is determined by the Realm’s governance.

### Founder

A **Founder** is an early member recognized under a Realm’s founding rules.

For a DUNA, Founders may be:

- the first 100 members to join; or
- where the DUNA conducts an initial Compute sale, the eligible members who join and purchase Compute before that sale closes.

The Realm must define its exact Founder qualification rule.

Founder status may provide recognition, rights, or benefits, but does not inherently provide permanent control.

### Luminary

A **Luminary** is a Presence recognized for contributing a major work, breakthrough, body of knowledge, or other exceptional contribution to a Realm.

Luminary status may be:

- honorary;
- functional;
- compensated; or
- some combination of these.

## 12.3 Administrative Roles

### Wizard

A **Wizard** has administrative authority within a particular Realm.

A Wizard may administer:

- Realm structure;
- Roles;
- Elements;
- Agents;
- configurations;
- approved Connections;
- policies; and
- operations

within explicitly granted permissions.

A Wizard cannot:

- inspect information merely because it exists in the Realm;
- override privacy;
- reveal secret information;
- bypass a Presence’s permissions;
- assume authority that has not been granted;
- override Treasury governance; or
- treat administration as ownership.

### Mage

A **Mage** has administrative authority across an Ecosystem.

A Mage may coordinate and administer shared Ecosystem systems within explicitly granted authority.

A Mage cannot:

- override Realm sovereignty;
- inspect private or secret information without permission;
- supersede valid Realm governance;
- bypass a Presence’s authority;
- override Treasury signing or governance requirements; or
- convert Ecosystem administration into centralized control.

Neither Wizards nor Mages are superusers.

There is no universal administrative account with unrestricted access to the Kidunaverse.

The system remains:

- decentralized;
- composable;
- governed by explicit authority;
- protective of privacy; and
- resistant to invisible administrative override.

---

# 13. Authority and Permissions

**Authority** determines what a Presence, Realm, or Agent is legitimately empowered to do.

**Permission** determines whether a particular Action is currently allowed.

Authority originates with a Presence or Realm and may be:

- retained;
- delegated;
- limited;
- conditional;
- time-bound;
- revocable; or
- further delegable.

Permissions are connected directly to:

- the Presence;
- the Agent acting for it;
- the Realm;
- the Role;
- the current goal;
- the Action;
- the target;
- visibility;
- privacy;
- duration;
- conditions;
- risk;
- policy; and
- Source of authority.

A Role may grant permission to:

- create within a Realm;
- add Wisdom;
- modify Stance;
- add context;
- write to memory;
- add to a vector database;
- create or configure Agents;
- establish Automations;
- add Connections;
- invite Presences;
- publish;
- spend;
- trade;
- govern;
- appoint Roles; or
- administer specified systems.

Permissions should be explicit enough that the system can answer:

- Who may do this?
- Through which Role?
- In which Realm?
- For which goal?
- Using which Agent?
- Against which target?
- With what visibility?
- Under what conditions?
- For how long?
- Who may change or revoke the permission?

## 13.1 Action Authorization Levels

### Autonomous

The Agent may perform the Action without asking each time.

Example: draft an email and save it to the member’s drafts folder.

### Confirmed

The Agent must receive lightweight confirmation before acting.

Example: send a routine email.

### Deliberate

The Action requires elevated confirmation because it is consequential, difficult to reverse, or high-risk.

The interface may require:

- press-and-hold;
- explicit review;
- a second factor;
- a delay;
- additional signatories; or
- an explanation of consequences.

### Governed

The Action requires authority from:

- a Role;
- a policy;
- a Forum;
- a vote;
- a market;
- a multisignature process; or
- another governance mechanism.

### Prohibited

The Action may not be performed under the current circumstances.

The interface used to authorize an Action is not itself the permission.

A button, toggle, slider, or press-and-hold control is only the means through which the underlying authority decision is expressed.

---

# 14. Privacy and Visibility

## 14.1 Privacy

**Privacy** describes how information may be accessed, used, retained, or disclosed.

### Public

Available to anyone.

### Private

Available only to explicitly authorized Presences, Realms, or Agents.

### Secret

Highly restricted information requiring elevated protection and explicit access.

Examples include:

- cryptographic keys;
- recovery material;
- private credentials;
- protected security information; and
- highly sensitive confidential records.

### Personal

Information belonging to or concerning a particular member and governed by:

- that member’s authority;
- the applicable Realm;
- relevant agreements; and
- applicable law.

Personal is not simply a stronger form of privacy.

Personal information may be public, private, or secret, but it remains associated with a human member and their rights.

Privacy may be represented through fields such as:

- classification;
- owner;
- subject;
- access policy;
- permitted uses;
- retention policy;
- disclosure restrictions; and
- deletion rights.

## 14.2 Visibility

**Visibility** determines who may discover or perceive a Realm, Presence, Agent, Artifact, Element, Action, Treasury, or relationship.

Visibility is related to permission but is not identical to it.

A Presence may be able to know that something exists without being able to open it.

A Presence may be able to view something without being able to modify it.

A Presence may be able to modify something without being able to disclose it publicly.

Visibility rules must be enforceable at the:

- Graph layer;
- Agent layer;
- Action layer;
- storage layer; and
- interface layer.

---

# 15. Trust

**Trust** is a contextual assessment of whether a Presence, Realm, Agent, Artifact, Connection, Action, or claim may be relied upon for a particular purpose.

## 15.1 Low Trust

The default when identity, authority, integrity, behavior, or provenance has not been sufficiently established.

## 15.2 Medium Trust

Some relevant claims have been established, but material uncertainty remains.

## 15.3 High Trust

The necessary identity, authority, provenance, security, and behavioral requirements have been established for the relevant Action or context.

Trust must not be treated as a single permanent reputation score.

Trust is:

- contextual;
- evidence-based;
- purpose-specific;
- revocable;
- time-sensitive; and
- subject to policy.

Something may have high trust for one Action and low trust for another.

---

# 16. Lifecycle Status

**Lifecycle Status** describes where something is in its operational, administrative, or legal lifecycle.

Common statuses include:

## 16.1 Draft

Exists but has not been formally issued, published, registered, or activated.

## 16.2 Published

Has been made available to its intended audience.

## 16.3 Registered

Has been recorded in an authoritative registry or system of record.

## 16.4 Active

Is currently operating and permitted to perform its intended function.

## 16.5 Pending

Awaiting approval, activation, verification, or another required event.

## 16.6 Suspended

Temporarily prevented from operating.

## 16.7 Archived

Retained as a historical record but no longer active.

## 16.8 Revoked

Previously granted status, authority, or validity has been withdrawn.

## 16.9 Expired

No longer valid because a defined period has ended.

## 16.10 Dissolved

Formally ended as an operating Realm or legal entity.

Statuses are not necessarily sequential.

For example, an Organization may be registered but not yet active.

---

# 17. Governance

**Governance** is the process through which a Realm creates, changes, and applies collective authority.

## 17.1 Forum

A **Forum** is the environment in which Proposals are:

- introduced;
- discussed;
- evaluated;
- amended;
- supported;
- opposed; and
- decided.

A Forum may use:

- deliberation;
- voting;
- delegated voting;
- consensus;
- decision markets;
- councils;
- appointed authority; or
- other mechanisms.

A decision market may operate inside a Forum, but a Forum is broader than a futarchy market.

## 17.2 Proposal

A **Proposal** is a proposed:

- Decision;
- Action;
- allocation;
- appointment;
- agreement;
- policy change; or
- other exercise of collective authority.

## 17.3 Decision

A **Decision** is the formally determined outcome of a Proposal or other authorized governance process.

## 17.4 Policy

A **Policy** is a persistent rule or instruction created through valid authority.

A passed Proposal may:

- create a Policy;
- authorize a one-time Action;
- allocate resources;
- appoint or remove authority;
- modify Permissions;
- modify Roles;
- authorize a Treasury transaction; or
- trigger execution.

Not every passed Proposal becomes a standing Policy.

Governance belongs to Realms.

---

# 18. Offerings

An **Offering** is something a Realm or Presence makes available to another Presence or Realm under stated terms.

An Offering may be represented as a Realm.

## 18.1 Offering Forms

An Offering may provide:

- a digital good;
- a physical good;
- a service;
- access;
- membership;
- a license;
- a subscription;
- sponsorship;
- Compute capacity;
- participation rights; or
- another defined benefit.

## 18.2 Payment and Eligibility Models

An Offering may use:

- one-time payment;
- recurring subscription;
- usage-based payment;
- a holding requirement;
- membership entitlement;
- earned access;
- negotiated exchange; or
- a combination of these.

A requirement to hold a specified amount of Compute is an eligibility condition, not a separate type of Offering.

---

# 19. Treasuries

A **Treasury** is the financial resource system of a Realm.

Any Realm may have a Treasury.

A Treasury may include:

- one or more wallets;
- one or more bank accounts;
- custodial accounts;
- payment accounts;
- token holdings;
- Compute reserves;
- receivables;
- financial commitments; and
- other governed stores of value.

A Treasury is not limited to crypto assets.

It may consist of:

- a wallet;
- a bank account;
- multiple wallets;
- multiple bank accounts; or
- any authorized combination of these.

A Treasury belongs to a Realm and is controlled according to that Realm’s:

- Roles;
- Permissions;
- Policies;
- governance;
- signing rules;
- spending limits;
- accounting rules; and
- applicable law.

## 19.1 Treasury Accounts

A Realm may connect multiple financial accounts to one Treasury.

Each account should declare:

- the Realm that owns or controls it;
- the account type;
- the institution or network;
- the assets it may hold;
- who may view it;
- who may propose transactions;
- who may approve transactions;
- who may execute transactions;
- applicable spending limits;
- required signatures;
- governance requirements; and
- reconciliation status.

A Treasury may aggregate information across its accounts while preserving the separate authority and operational rules of each account.

## 19.2 Bank Accounts

A Treasury may include one or more bank accounts.

Bank accounts may be used to:

- receive fiat payments;
- hold operating funds;
- pay expenses;
- compensate contributors;
- receive off-ramp proceeds;
- fund on-ramp purchases;
- maintain reserves; and
- interact with the traditional financial system.

Access to a bank account must remain subject to the Realm’s Permissions and governance.

A Connection to a bank account does not by itself grant authority to move funds.

## 19.3 Wallets

A Treasury may include one or more cryptographic wallets.

Wallets may hold:

- Compute;
- stablecoins;
- governance assets;
- market positions;
- credentials;
- tokenized assets;
- Treasury reserves; and
- other supported digital property.

Kiduna recognizes three primary wallet types.

### Multisignature Wallet

A **Multisignature Wallet** requires approval from a defined number of authorized signers before a transaction may be executed.

Kiduna uses **Squads** as the standard multisignature wallet infrastructure for shared Realm Treasuries.

A Squads wallet may define:

- authorized signers;
- signing thresholds;
- spending limits;
- Proposal requirements;
- transaction queues;
- execution delays;
- emergency procedures; and
- governance Connections.

### FROST Wallet

A **FROST Wallet** uses threshold cryptography to distribute control of a wallet across key shares.

The standard Kiduna Member wallet uses three key shares.

No single key share is sufficient to control the wallet.

The shares may be distributed across approved:

- devices;
- services;
- recovery systems; or
- custodial arrangements

according to the Member’s configuration and Kiduna security policy.

FROST wallets are the standard wallets for Members.

A Member’s FROST wallet may be used for:

- holding Compute;
- payments;
- receiving distributions;
- governance participation;
- signing Kinship Codes;
- authorizing Agents;
- connecting to Alliance governance; and
- other Member-authorized Actions.

### External Wallet

An **External Wallet** is a wallet created or controlled outside Kiduna and attached to a Realm through a Connection.

Any Realm may attach an External Wallet.

An External Wallet may include:

- a browser wallet;
- a hardware wallet;
- an institutional wallet;
- a custodial wallet;
- a smart-contract wallet; or
- another compatible wallet.

Attaching an External Wallet does not make it native to Kiduna and does not alter its underlying signing or custody model.

Kiduna should clearly distinguish between:

- observing the wallet;
- verifying ownership or control;
- requesting a signature;
- proposing a transaction; and
- possessing authority to execute a transaction.

## 19.4 Realm Treasury Defaults

Different Realm types have different standard Treasury configurations.

### Organization Treasuries

Every Organization has a Squads multisignature wallet as part of its Treasury.

An Organization Treasury is governed through its Forums.

Forum governance may determine:

- Treasury Policies;
- budgets;
- allocations;
- signers;
- signing thresholds;
- spending limits;
- investments;
- distributions;
- transfers;
- liquidity;
- compensation;
- protocol payments; and
- other material financial Actions.

A Forum Decision may:

- authorize a specific Treasury Action;
- create a standing Treasury Policy;
- delegate limited spending authority to a Role;
- change signer or threshold rules;
- allocate a budget; or
- trigger an executable transaction.

The Organization’s Squads wallet provides the execution and signing layer.

The Forum provides the collective authority layer.

### Alliance Treasuries

An Alliance may have a Treasury and uses a Squads multisignature wallet as its standard shared wallet.

Alliance Treasuries may use simpler governance than Organizations.

Alliance governance may include:

- direct Member approval;
- signer approval;
- Role-based approval;
- threshold voting;
- budget limits;
- time-limited delegations; or
- other lightweight decision processes.

An Alliance does not require the full Forum governance system used by an Organization unless the Alliance adopts it.

Alliance Squads wallets may connect to the FROST wallets of participating Members.

These Connections allow Member wallets to participate in Alliance governance through mechanisms such as:

- signing;
- approvals;
- voting;
- delegation;
- membership verification;
- contribution tracking; and
- distribution.

The Alliance wallet remains distinct from the participating Member wallets.

A Connection does not merge custody, ownership, or balances.

### Member Treasuries

A Member’s personal Treasury uses a FROST wallet as its standard native wallet.

The Member is the Source of authority for the wallet.

Ki may assist the Member with:

- understanding balances;
- preparing transactions;
- managing permissions;
- reviewing risks;
- participating in governance;
- connecting external accounts; and
- maintaining records.

Ki may not execute a transaction beyond the authority explicitly granted by the Member.

### Other Realm Treasuries

Any other Realm may establish a Treasury when it needs to:

- receive funds;
- hold assets;
- pay contributors;
- make purchases;
- operate a budget;
- issue distributions;
- collect revenue; or
- participate in markets.

The Realm must define:

- who owns or controls the Treasury;
- which governance process applies;
- which wallet or account types are permitted;
- who may propose transactions;
- who may approve them;
- who may execute them; and
- how the Treasury is reconciled and audited.

## 19.5 Treasury Governance

Treasury governance determines how financial authority is exercised.

Treasury Actions may be:

### Autonomous

An authorized Agent or Role may execute the Action within a defined Policy and limit.

Example: paying a recurring infrastructure bill below an approved threshold.

### Confirmed

A designated Presence must approve the Action.

Example: approving a routine contributor payment.

### Deliberate

The Action requires elevated confirmation because of its amount, risk, permanence, or sensitivity.

Example: transferring a substantial portion of a Realm’s reserves.

### Multisignature

The Action requires approval from the required number of wallet signers.

### Governed

The Action requires a valid Forum Decision, vote, Policy, or other Realm governance process.

These requirements may be combined.

For example, an Organization Treasury Action may require:

1. a passed Forum Decision;
2. creation of a transaction in Squads;
3. signatures from the required signers; and
4. deterministic execution by an authorized Actor.

## 19.6 Treasury Roles and Permissions

Treasury authority may be assigned through Roles.

Possible Treasury capabilities include:

- view balances;
- view transactions;
- create budgets;
- propose payments;
- approve payments;
- sign transactions;
- execute transactions;
- connect accounts;
- reconcile records;
- manage liquidity;
- distribute Compute;
- allocate compensation;
- manage signers; and
- modify Treasury Policies.

No Role should receive unrestricted Treasury authority by default.

Treasury Permissions should specify:

- the Realm;
- the account or wallet;
- the asset;
- the Action;
- the maximum amount;
- the time period;
- the recipient or recipient class;
- the required approvals;
- the applicable Policy; and
- whether the authority may be delegated.

## 19.7 Treasury Connections

Treasuries may connect to:

- Member FROST wallets;
- Realm Squads wallets;
- External Wallets;
- bank accounts;
- payment processors;
- exchanges;
- on-ramps;
- off-ramps;
- accounting systems;
- tax systems;
- governance systems; and
- liquidity venues.

Connections allow systems to exchange information or initiate authorized Actions.

A Connection does not override:

- custody;
- ownership;
- privacy;
- signing requirements;
- governance; or
- Permissions.

## 19.8 Treasury Records

Every Treasury Action should produce an auditable record.

Treasury records should include:

- the Realm;
- the account or wallet;
- the proposing Presence or Agent;
- the Source of authority;
- the applicable Role;
- the governing Policy or Decision;
- required approvals;
- signatures;
- asset;
- amount;
- recipient;
- purpose;
- timestamp;
- execution status;
- transaction identifier; and
- reconciliation state.

Records may be private, but their existence and use remain subject to the Realm’s governance and applicable reporting requirements.

## 19.9 Treasury Invariants

The following principles apply across Kiduna:

1. Any Realm may have a Treasury.
2. A Treasury may contain wallets, bank accounts, or both.
3. Organizations use Squads wallets and govern their Treasuries through Forums.
4. Alliances use Squads wallets with simpler Realm-defined governance.
5. Members use FROST wallets with three key shares.
6. Any Realm may attach an External Wallet.
7. Alliance Squads wallets may connect to Member FROST wallets for governance.
8. Connections do not merge ownership or custody.
9. Administrative Roles do not override Treasury Permissions.
10. No Wizard, Mage, Agent, or system operator has universal access to Treasury assets.
11. Every Treasury Action must have a valid Source of authority.
12. Every executed Treasury Action must be deterministic and auditable.

---

# 20. Compute

**Compute** is the digital capacity used to purchase intelligence, Agent operations, and related services within a Realm.

An Organization or other authorized Realm may issue or designate its own Compute.

Compute may be held, received, distributed, or managed through a Realm’s Treasury.

## 20.1 Realm-Defined Compute Rules

A Realm may establish:

- membership purchase requirements;
- holding requirements;
- activation thresholds;
- minimum and maximum issuance conditions;
- pricing;
- Agency Premium;
- Role-specific rates;
- lineage distributions;
- Treasury distributions;
- contributor allocations;
- transferability;
- redemption;
- conversion; and
- market access.

## 20.2 Raw Compute Cost

**Raw Compute Cost** is the underlying cost of:

- models;
- infrastructure;
- tools;
- storage;
- networking; and
- execution

required to perform work.

## 20.3 Agency Premium

The **Agency Premium** is the amount charged above Raw Compute Cost for access to a Realm’s:

- agency;
- coordination;
- intellectual property;
- infrastructure;
- community;
- context;
- relationships; and
- services.

The Agency Premium may be expressed as:

- a multiple;
- a fixed addition;
- a percentage; or
- a Role- or service-specific schedule.

## 20.4 Protocol Licensing

A Realm may pay Kiduna Club:

- a defined portion of the Agency Premium for use of the Kiduna stack; and
- a defined portion of Compute purchases for protocol and infrastructure licensing.

These are separate economic rules.

## 20.5 Compute Purchase Distribution

When Compute is purchased, the received payment may be distributed through the applicable Treasury among:

- lineage recipients;
- Kiduna Club licensing;
- the Realm Treasury;
- liquidity;
- contributors;
- sponsors; and
- other Policy-defined recipients.

A protocol default may be provided, but a Realm may change it where permitted by its governing rules.

## 20.6 Lineage

**Lineage** records the invitation or relationship path through which a Presence joined a particular Realm.

Lineage distributions may reward multiple generations of that path.

A default distribution may be:

- Generation 1: 20%;
- Generation 2: 5%;
- Generation 3: 3%; and
- Generation 4: 2%.

Lineage applies to the relevant Realm and does not automatically create a universal relationship across the Kidunaverse.

## 20.7 Treasury Allocations

A Realm may establish recurring or discretionary Treasury allocations for contributors such as:

- Catalysts;
- Luminaries;
- Builders;
- Creators;
- Operators; and
- other recognized Roles.

Roles may carry:

- fixed compensation;
- recurring compensation;
- bounties;
- revenue shares;
- Compute distributions;
- market-based payments; or
- other Realm-defined rewards.

---

# 21. Structural Summary

The canonical taxonomy answers these foundational questions.

## Where does participation happen?

In the **Field**, accessed through **Surfaces**.

## What can be entered and explored?

**Realms**.

## Who appears and participates?

**Presences**.

## Who provides personal agency?

**Ki**, the Ally.

## What other software entities act?

**Actors**.

## What do Agents know and possess?

**Wisdom, Stance, Abilities, Automations, and Connections**.

## What appears visually?

**Elements**, organized within the Field, Realms, and Panels.

## What creates a bounded, independently designed experience?

**Scenes**, entered through **Portals**.

## What persists?

**Artifacts**.

## What happens?

**Actions**.

## How does a Presence participate in a Realm?

Through **Roles**.

## Why may an Action occur?

Because of valid **Authority, Permissions, Role, goal, context, visibility, and Policy**.

## How is information protected?

Through **Privacy and Visibility**.

## How is reliability assessed?

Through contextual **Trust**.

## How are collective decisions made?

Through **Governance**.

## How are goods, services, access, and participation made available?

Through **Offerings**.

## Where is financial value held and governed?

In **Treasuries**, which may contain wallets, bank accounts, or both.

## How are intelligence, agency, contribution, and value paid for?

Through **Compute, Treasuries, Roles, and Realm-defined economic policies**.

---

# Version 1.3.3 Canonical Boundary

## Canonical clarifications added in this version

1. The Field is the complete living environment, including ongoing activity, agency, Wisdom, memory, relationships, work, and play.
2. The Field remains present as context even when a Surface does not display it continuously or spatially.
3. Realms and their authorized Agents may remain active, contribute, coordinate, respond, and request attention while a Presence is focused elsewhere.
4. Ongoing or background activity never creates authority; the same Source-of-authority, permission, policy, audit, and Record requirements apply.
5. Ki may reflect collective Wisdom only within its governing permissions and may not expose private contributions, invent consensus, erase disagreement, or become a surveillance channel.
6. A Panel may dominate attention without replacing the Field or Realm and without changing semantic containment or authority.
7. A Scene is a bounded environment used when spatial, simulated, performative, game-like, or independently visual interaction materially improves participation or understanding. It is not the Field or merely a larger Panel.
8. Portals preserve or explicitly transform relevant context and provide a defined route back.

## Working design terms not made canonical

The following terms are used by the Studio design-system program but remain proposals rather than canonical taxonomy in Version 1.3.3:

- **Atlas** — working name for a possible broad-orientation presentation within the Field. It is not the Field and no visual form is prescribed.
- **Focus** — working name for the current intention or body of work organizing a Surface.
- **Pulse** — working name for a quiet expression of Realm activity, readiness, or constraint.
- **Lens** — working name for an inspection treatment that reveals deeper context, provenance, state, or authority.
- **Stage** — working name for a treatment in which an Element temporarily becomes the dominant work object.
- **one-center shell** — an accepted Studio design constraint, not a canonical Kidunaverse object.

These terms may be validated, renamed, rejected, or incorporated into a later canonical version. Their use in design documents must not imply canonical status.

## Unresolved semantic questions

- Whether a broad-orientation presentation requires a canonical term distinct from the Field.
- Whether Lens and Stage are durable interaction primitives or merely presentation variants of Panels and Elements.
- How a Surface should communicate activity elsewhere in the Field without creating a dashboard or prescribing permanent navigation.
- Whether “Record” should become a distinct canonical object or remain an event-bearing Artifact or Action result.
- Whether “Program” should become a first-class Realm type rather than remain under Other Realm Types.

## Change provenance

| Change | Classification | Source |
|---|---|---|
| Field is always present but need not be continuously visible | Owner-approved canonical clarification | Gate 2 activation commentary, inspected July 19, 2026 |
| Field includes ongoing activity and collective agency | Owner-approved canonical clarification | Gate 2 activation commentary, inspected July 19, 2026 |
| Realms may remain active and request attention | Necessary canonical implication of collective agency | Gate 2 activation commentary plus existing Sections 3, 5, 6, and 11 |
| Ki collective-Wisdom safeguards | Necessary canonical clarification of existing privacy and permission rules | Owner direction plus existing Sections 5, 13, and 14 |
| Focused Panels remain within Field context | Canonical semantic clarification; visual form remains open | Owner direction plus existing Section 8 |
| Scene use and distinction from Field/Panel | Canonical semantic clarification | Owner gallbladder Scene example plus existing Section 9 |
| Atlas, Focus, Pulse, Lens, Stage, one-center shell remain non-canonical | Explicit boundary protecting taxonomy from interface hypotheses | Gate 0/1 decisions and Gate 2 activation instruction |

## Taxonomy impact rule

Every subsequent design turn must state one of:

1. **Taxonomy updated** — with version, exact change, classification, provenance, and affected documents; or
2. **No taxonomy change** — with a short explanation of why the turn produced only evidence, proposals, or interface findings.

Prior versions remain retained as historical evidence and must not be overwritten.


---

*2026-08-01: **v1.3.8 amendment installed — the final canon taxonomy**: the eight Scenes (Atlas · Studio · Commons · Workbench · Forum · Exchange · Garden · Vault, each one verb); Surfaces ruled to be form factors (Desktop web · Mobile · Chrome Sidebar · CTV; Vault web-only); the Seven Elements (Offers admitted); the Six Capacities settled (Inform with Wisdom · Instruct for Presence · Empower with Connections · Enable with Automations · Impart Abilities · Align for Coherence); the economic rails (real FROST and Squads wallets from day one, orchestration in place of external token-platform smart contracts, all liquidity unified in $KIDUNA at launch, duna tokens when ready, the Agency Premium); equal-weight voting; Themes — the intention layer (26 themes, 6 clusters, ≤3 per Realm, aggregation up the nesting, theme-affinity matching); AI-native and done-means-done as canon; and the evening close-out rulings — the canonical Realm types final at ten (Ecosystem · Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell; Offering and Member Realm retired as types), the privacy hierarchy (more privacy than context allowed, never less), no offline mode, the adoption rule (Realms adopt freely; Ecosystem adoption through governance makes a thing universal), the platform floors (desktop 1280/1024, iOS 16+/Android 10+, CTV Android TV 1080p, WCAG 2.2 AA), the design repository for all iconography, and the brief's Studio/Live two-distances framing read as historical; and the name ruled — **"Kidunaverse" retired everywhere; it is Kiduna**, with historical documents read through the substitution and addresses keeping their spellings. Companion pages: [taxonomy summary](taxonomy-summary.html) · [initial-release functional spec](initial-release-functional-spec.html). 2026-07-26: **v1.3.7 amendment installed** — from the Studio + Live Working Design Brief v0.1: the Ally is the Field-visible Element (Sources stand behind their Allies in the data and governance model); canonical Ally states Open · Engaged · Focused · Dreaming, never inferred; Concept admitted as a Realm type (the product-level set: Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell); Ki always speaks in the third person, never "I"; the fourth persona is Danny. 2026-07-22 (second): **v1.3.6 amendment installed** — the Handshake generalized: single-use, out-of-band person-to-person verification, used at onboarding AND whenever two Sources connect to form a Relationship. 2026-07-22: **v1.3.5 amendment installed** (Presence renames Stance; Host; the secret handshake; non-unique Code Names over GUIDs; Kinship Duna = Ecosystem + Organization, Kiduna the short form; in-Kiduna rule; the Creator/Builder 12% default; the Resources page canon). 2026-07-21: **v1.3.4 amendment installed** (the Six Elements — Realms, Actions, Resources, Media, Sources, Actors; Source replaces Presence; all agents are Actors; Media absorbs Elements and Artifacts; Scenes without Portals; Cell; Program defined; the person-vouched invitation). 2026-07-19 (third pass): v1.3.3 installed verbatim (supersedes v1.3.2 — Field always-present/not-always-visible, collective Realm agency, focused Panels and Scenes, the non-canonical design-terms boundary, the taxonomy impact rule). Source: [canonical-taxonomy-v1.3.3.md](downloads/canonical-taxonomy-v1.3.3.md). Full history: [versions](versions/index.html).*
