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; the one-page reading is The Final Taxonomy, Summarized.

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.

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 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:

Inform with Wisdom — the vector database: knowledge, context, what the agent knows.
Instruct for Presence — the system prompt: how the agent carries itself.
Empower with Connections — integrations: third-party systems and software the agent can reach.
Enable with Automations — deep agents, triggers, standing processes that continue without being asked twice.
Impart Abilities — skills: markdown-defined know-how the agent can be handed.
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 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. 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.

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:

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.)
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.

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.)
Host — the Source who invited you; your Gen-1 upline. UI shows the Host by name or Code Name, not the word.
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.
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.
Guest (additional sense): an invited person exists in the system as a Guest until they register and become a Member.
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.
Language rule: always “in Kiduna,” never “on Kiduna.”
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.
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.”
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:

the Field;
Surfaces;
Realms;
Presences;
Agents;
Agent Capabilities;
Elements;
Panels;
Scenes and Portals;
Artifacts;
Actions;
Roles;
Authority and Permissions;
Privacy and Visibility;
Trust;
Lifecycle Status;
Governance;
Offerings;
Treasuries; and
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.

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:

a passed Forum Decision;
creation of a transaction in Squads;
signatures from the required signers; and
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:

Any Realm may have a Treasury.
A Treasury may contain wallets, bank accounts, or both.
Organizations use Squads wallets and govern their Treasuries through Forums.
Alliances use Squads wallets with simpler Realm-defined governance.
Members use FROST wallets with three key shares.
Any Realm may attach an External Wallet.
Alliance Squads wallets may connect to Member FROST wallets for governance.
Connections do not merge ownership or custody.
Administrative Roles do not override Treasury Permissions.
No Wizard, Mage, Agent, or system operator has universal access to Treasury assets.
Every Treasury Action must have a valid Source of authority.
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

The Field is the complete living environment, including ongoing activity, agency, Wisdom, memory, relationships, work, and play.
The Field remains present as context even when a Surface does not display it continuously or spatially.
Realms and their authorized Agents may remain active, contribute, coordinate, respond, and request attention while a Presence is focused elsewhere.
Ongoing or background activity never creates authority; the same Source-of-authority, permission, policy, audit, and Record requirements apply.
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.
A Panel may dominate attention without replacing the Field or Realm and without changing semantic containment or authority.
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.
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:

Taxonomy updated — with version, exact change, classification, provenance, and affected documents; or
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 · initial-release functional spec. 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. Full history: versions.