# Kiduna — Complete Specification · Kiduna Kit v4.3 (Taxonomy v1.3.8 final · The Kiduna Canon · Initial Release Functional Specification v2.0 · Surfaces v5.9 · decision queue empty) · built 2026-08-01 23:10 EDT

> Single-file corpus of the Kiduna site (https://kiduna.team), assembled for chat assistants. Source files are named at each section break. **The Kiduna Canon** (section 2) is the whole canon in one standalone document — start there. **The Core Taxonomy v1.3.8** is the law: where any section below disagrees with it about the shape of the product, it wins. **The name is Kiduna** — "Kidunaverse" is retired (Taxonomy v1.3.8 §14); historical sections below keep their original wording and are read with the substitution. The UI design canvases are HTML-only and live in the kit's design-r8/ folder and the site repo. (Named `KIDUNAVERSE-COMPLETE.md` through kit v4.2.)

## Contents

1. The synthesis · 2. The Kiduna Canon · 3. The Initial Release Functional Specification v2.0 · 4. The Core Taxonomy v1.3.8 · 5. The Final Taxonomy, Summarized · 6. The Genesis Nightpaper v0.3 · 7. The Studio + Live Working Design Brief v0.1 · 8. Create from Within · 9–19. Tracks 1–11 · 20. The Design Method · 21. Architecture · 22. Kinship Graph Architecture v1.1 · 23. Open Questions (empty) · 24. Legal Items for Review · 25. Real Work, Real Money · 26. The Working Organization · 27. The kiduna.ai public home · 28. Canon deltas

---

<!-- ===== SOURCE: index.html (the synthesis) ===== -->

# Kiduna — the synthesis

## What we're building, plainly
We are building the **agentic internet**: a layer on the whole internet where people are represented by intelligent agents, organizations are internet-native and member-owned, and every action — a message, a decision, a payment — resolves to a legally accountable entity. Kiduna is that layer's namespace and its home. It is owned and operated by **Kinship Duna**, the genesis organization: a legally real West Virginia DUNA whose purpose is to build this technology, spin out other organizations, and train members to thrive in an agentic economy. Genesis means first, not in charge — the system is decentralized and permissionless, every organization has equal power, and the only central registry anywhere is the WV Secretary of State.

**The product is a relationship, not an app to operate.** Every member has one **ally** — their agent, named by them, working for them across every organization they join. You talk to it, by text or by voice; it does the work: it messages, researches, schedules, moderates, drafts, negotiates with other members' allies, and brings back the few things only you can sign. There are no menus. The interface is one conversation (**Chat**) plus one graphic world (**Live**) — and everything either surface shows is the same underlying system rendered two ways. It reaches you through six surfaces: **Kiduna** (the app — the first KAP client), **Kiduna Live** and **Kiduna One** (each mode whole), **Kiduna Express** (the browser), **the account** (kidunaverse.com), and **Kiduna Studio** (the build/create environment). Underneath: an installable open-source server — one installation is an **ecosystem**, the Genesis Ecosystem is **Kiduna**, and its purpose is to propagate.

**The application has eight places to be.** Whatever a member is doing, they are in one of eight **Scenes**, each one verb long: **Atlas** (discover — the whole space of organizations and communities, arranged by relevance, read-only), **Studio** (create — where a Realm gets its knowledge, its voice, its name and its icons), **Commons** (organize — people, relationships, collaboration), **Workbench** (build — the maker's sandbox, where members write their own agents and automations and hand real work to coding agents), **Forum** (govern — proposals, votes, allocation; every member's vote weighs the same, never money-weighted), **Exchange** (settle — Compute, and moving between $KIDUNA and USDC), **Garden** (enjoy — where everything the members build actually gets used), and **Vault** (store — the wallet, on the web only). A Scene is a real place — a room, a scenario, an area, drawn with its own sprites and tiles — and Scenes connect through **Portals**; Builders make their own and deploy them into the Garden. A **Surface** is a form factor, not a product: **desktop web**, **mobile**, the **Chrome sidebar**, and the **connected TV** — the shared screen the phones in the room drive. All four ship in the first release; every Scene reaches every Surface except the Vault. And everything in the system is *about* something: **Themes** — a fixed spine of twenty-six, at most three to a Realm — are how the Atlas arranges itself and how the graph knows which organizations belong together.

**All of it is written down in one place.** [The Kiduna Canon](the-kiduna-canon.html) is the whole thing as a single standalone document — the eight Scenes, the four Surfaces, the six Capacities, the seven Elements, the ten Realm types, the twenty-six Themes, and the rules that bind them: the command boundary, person-vouched identity, the economic rails, the privacy hierarchy, the adoption rule. Read it end to end and you know what Kiduna is. What the first release must actually *do* — Scene by Scene, Surface by Surface — is the [Initial Release Functional Specification](initial-release-functional-spec.html). The [Core Taxonomy](taxonomy.html) remains the law behind both, and [the summary](taxonomy-summary.html) is the one-page reading of it.

**Underneath, it is one big system.** Allies appear separate but are personas of a single agent system with a single context store. Everything anyone adds — information, tools, skills, made things — exists once, available across the whole system at the root, gated only by four access levels: **public** (anyone), **private** (visible, permission required), **secret** (undiscoverable without a code), **personal** (you and your ally only, ever). Relationships between members are first-class: when you connect with someone, each of you states exactly what the other may see and use. Boundaries in this system are not walls; they are stated levels of trust, enforced by the database on every single command.

**The organizations are real.** Thirty-one DUNAs are already filed — a health community, a law firm, a mutual insurer, a solar collective, festivals, a dating organization, mutual-aid networks — each a legal entity, each a configuration of the same platform. Members join a duna with its initial Compute purchase ($100, lifetime, for Kinship Duna — each duna sets its own), hold one wallet, and move freely among them; alliances form inside them with shared wallets; guilds form anywhere with nothing but a name. Decisions happen in **Forums**, where every member votes with one equal, free token, and a passed proposal executes its **duna commands** — real organizational actions, atomically. Deciding is never fundraising.

**Money is deliberately boring and deliberately minimal.** Everything financial lives on a small web surface (never in the mobile app), and only six things ever touch the blockchain: members, their allies, alliances, organizations, Compute, and votes with their settlements. That short list is the **Kinship Agency Protocol**, and it exists for one reason — so it is always provable who ordered a thing, who paid for it, and under whose responsibility it happened. Everything else stays off-chain, where it belongs.

**And it learns by playing.** Live's first product is **Kidunaversity**, a Move: training regimens for operating in an agentic world — guiding your ally, forming alliances, running Forums — where everything is real except the money, which is fake by construction. New members learn the system the way people actually learn: by doing it where mistakes are free.

<div class="flow">
<span class="t">How the pieces fit — follow one act through the system</span>
A member speaks to their ally in [Chat](surfaces.html) →
the one agent system [routes, weights, and acts](orchestration.html) →
every read and write is permission-checked against [the graph](foundation.html) →
if money moves or a vote settles, it is recorded by [the protocol](protocol.html) →
always inside [an organization](organizations.html) that is legally accountable →
through a registered [action](actions.html) →
gated by the member's [role](roles.html) →
while [the Sentinel](sentinel.html) quietly keeps the field healthy.
</div>

<h2>Why it is built this way</h2>
The public statement of the whole system is four principles — **human direction · agentic capacity · personal privacy · legal standing** — and they are what [kiduna.ai](https://kiduna.ai) promises the world: *not another AI tool; a place to build and belong.* The internet connected pages; social connected profiles; **Kiduna connects allies** — people and their intelligent allies in trusted relationships, where shared purpose becomes projects, movements, organizations, and action. The system is organized around agency: **sense, decide, act, learn** ; it succeeds when increased collective capacity makes every participant more capable, without absorbing authorship, collapsing privacy, or silently centralizing authority ([the Genesis Nightpaper](kiduna-a-new-architecture-for-agentic-civilization-v0.3.html) makes the full argument).
Three commitments explain nearly every design decision on this site. **Agents do the work; people do the deciding.** That is why there are no menus, why awareness arrives as a told account instead of a feed, and why the few sovereign acts — votes, codes, signatures — are deliberately physical. **Accountability over control.** That is why organizations are legal DUNAs, why the protocol is minimal, and why a domain, page, or artifact bound to the registry is called *registered* — traceable to a member and a legal entity — rather than "trusted": we claim only what the mechanism proves. **One system, stated trust.** That is why there is one context store with four access levels instead of walled gardens, why allies are personas instead of separate agents, and why a member's "that's secret now" binds everything instantly.
</div>

<div class="callout">
We build Kiduna from the inside out. This team works the way the product says members will: with our own allies, forming our own alliances, spinning out our own organizations. If this spec describes something we wouldn't live in ourselves, the spec is wrong.

<div class="who">

— Moto, Kinship Duna

</div>
</div>

<div id="tracks" class="sect">

---

<!-- ===== SOURCE: the-kiduna-canon.md ===== -->

# The Kiduna Canon

**One document: everything that defines Kiduna · August 1, 2026 · standalone**

---

Kiduna is one application — the creation engine for the agentic internet, owned and operated by Kinship Duna, the genesis organization. A member is always **in** something (a Realm), always **doing** something (a Scene), on **some device** (a Surface), always able to talk to **Ki**, the one intelligence that runs through everything. Everything in the system is one of seven kinds of thing (the Elements), every container is one of ten kinds (the Realm types), every agent is built from six kinds of input (the Capacities), and everything is *about* something (the Themes). This is the whole canon; the rest is detail.

The name is **Kiduna** — one word for the system, the application, and the world. "Kidunaverse" is retired.

## The eight Scenes — what you're doing

A Scene is a unique place — a room, a scenario, an area — rendered in Flutter/Flame with its sprites, tiles, and interface elements: a cohesive set of Media connected to the full Kiduna stack. **Scenes connect through Portals** — a plain tap to enter; press-and-hold stays reserved for signatures. The eight canonical Scenes are the launch set; Builders create more.

**Discover — Atlas.** The navigable space of everything. Realms render as original icons, clustered by relation and Theme, arranged by **Gravity**: orbits of importance where distance means current relevance — never worth. What becomes relevant comes forward and grows; pan and zoom always override. Inspect anything; join what admits you. Read-only.

**Organize — Commons.** People: who to connect with, whose Wisdom to learn from, how collaboration forms. Relationships form here, sealed by a Handshake — a single-use word two people agree outside the system. Scoped to Realms: the containers people share, not a directory of everyone.

**Create — Studio.** Where Realms take their character: Wisdom (the knowledge), Presence (the system prompt), the name, the original SVG icons and interface elements, the Theme tags — what makes a veterans Realm feel different from a cricket Realm and a politics Realm. Allies are created and refined here the same way, and Scenes are built here too.

**Build — Workbench.** The maker's sandbox. Members implement their own **Abilities** — the same Capacity the platform ships — plus the agents, automations, and Scene code composed from them, and hand real coding work to Claude Code or Codex through the Workbench plugin. Safety is **Realm containment + the Builder role + inspection**: a custom Ability operates only in Realms where it is explicitly deployed, deployment requires the Builder role and is a named Action, anything can be inspected down to author and history, and Sentinels run an acceptance protocol (prompt injection, malicious code, bugs) before anything deploys. Trust the Realm you're in; trust the Ability deployed there.

**Govern — Forum.** Proposals, deliberation, votes, allocation. **Votes are equal-weight, never weighted by money or holdings** — every member the same, in every Realm. Passage executes deterministic Actions; every act leaves a Record whose plain sentence is generated from the executing command itself, so it cannot lie. Releasing a duna's own token is a later Forum capability.

**Settle — Exchange.** Deliberately simple: buy Compute with $KIDUNA; move between $KIDUNA and USDC, wallet to wallet. Three facts stay visible everywhere: units held, wallet value in dollars, the current price. One currency at launch; duna tokens join when ready.

**Enjoy — Garden.** Where built things get used — the Scene the whole system exists for. A veteran arrives as a veteran; someone takes a course, helps a candidate, runs a rideshare, guides tourism, navigates care, opens a store. Every app is a deployed Scene, entered through a Portal, rendered through the **composition grammar**: ~15 interface primitives (cards, panels, lists, maps, schedules, tiles, chips, action cards) with combination rules and a deterministic renderer. Launch apps are authored compositions; later, Ki composes generatively within the grammar — arranging primitives, never inventing them; Actions always render as deterministic chips and cards.

**Store — Vault.** The wallet-shaped Scene, web-only: on-ramp, off-ramp, storage. Fiat in, $KIDUNA out, balances and history plain, custody rights stated in plain language.

## The four Surfaces — where you are

A Surface is a form factor, not a product. Every Scene reaches every Surface except Vault (web-only). A basic version of all four ships in the initial release — depth varies, presence does not.

- **Desktop** — the working distance: the Field on the left, Ki on the right (~70/30). Density, inspection, governance, commitment. Designed for 1280px, functional to 1024.
- **Mobile** — the human distance: presence, capture, coordination, bounded decisions; Ki as a bottom sheet. iOS 16+ / Android 10+. Mobile can confirm most consequential Actions.
- **CTV** — the shared big screen: Flutter/Flame on Android TV, driven by the mobile devices in the room, several people at once. The Garden's communal form.
- **Extension** — the Chrome sidebar: the agentic internet alongside the ordinary one, everything filtered through Kinship Codes. Registered things light up with what they trace to; unregistered stays a stranger, not a threat.

**Allies are in every view.** The people render wherever you are — every Scene, every Surface — and selecting an Ally opens it: who it represents, its Presence, and how to engage. All surfaces are Flutter/Flame; the modes are Chat and Live; the accessibility baseline is WCAG 2.2 AA. There is no offline mode — not connected means not present; downloads are just downloads.

## The six Capacities — how an agent is built

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

Every Ally, every Realm intelligence, every Actor is built from these six and nothing else.

## The seven canonical Elements — what things are

1. **Realms** — what can be entered.
2. **Actors** — all agents that are not Allies: Operators, Envoys, Sentinels, Workers, Supervisors, and kinds not yet named. An open-ended class.
3. **Media** — stable stored content: files, images, video, documents, structures. Some Media feeds the Wisdom stores; Scenes are compositions of Media.
4. **Allies** — the members' representatives: the visible identity of a person, with the human **Source** standing behind it in the data and governance model.
5. **Resources** — what things cost and how they're paid for: Compute, $KIDUNA, USDC, treasuries, capacity.
6. **Actions** — the deterministic, reserved operations intelligence is never allowed to improvise: moving money, issuing tokens, finalizing votes. Named, typed, executed only through the command boundary.
7. **Offers** — what is put forward for others to take up: goods and services, one-time or subscription.

## The ten Realm types

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

Every Realm nests inside Kinship Duna — the Ecosystem — and every Realm has full parity of capability: it can be shaped, connected, entered, and governed. A closed set; new types only by canon amendment.

## The Themes — what things are about

Not an eighth Element: a tagging layer in the Kinship Graph, applicable to Realms, Allies, and Offers — at most three per Realm. Elements say what a thing *is*; Capacities what it *can do*; Themes what it's *about*. Themes aggregate up the Realm nesting ("show me everything happening in Health"), power Gravity and discovery, and let the Graph route introductions by affinity. Open sub-themes live beneath the fixed spine and join it when the Ecosystem adopts them. Twenty-six themes, six 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)

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

Cluster names are internal — they organize the icon system; members see the plain theme names.

## The rules that bind everything

**Ki.** One intelligence behind everything; context follows location; speaks in the third person; proactive by default; never a character in the Field. Everything you can do by touching, you can do by saying.

**Identity is person-vouched.** A Kinship Code from a current member plus a Handshake agreed out-of-band. No email, no phone, no third party — the inviter is the verification. Invite-only at launch; joining is one hundred dollars, once, for life — the initial Compute purchase.

**The economy is on the blockchain, and the intelligence runs it.** Every member has a FROST wallet; every Organization, Alliance, and Institution has a Squads wallet; Communities and Relationships hold none. Everything moves wallet to wallet — $KIDUNA and USDC — orchestrated by agentic AI, with no external token platform and no new smart contracts at launch: the orchestration and database layers do that work over the real wallets. Liquidity never fragments — all $KIDUNA at launch. The **Agency Premium** is the engine: each organization sets what its intelligence costs; part of the premium flows to its treasury; the waterfall distributes the rest.

**The command boundary.** The graph service is the sole policy and command boundary: intelligence proposes, deterministic code authorizes and commits. Named commands; receipts generated from the executing parameters, so they cannot lie; simulations structurally unable to touch real rails.

**The privacy hierarchy.** An item may carry more privacy than its context, never less. Public is only really public in a public Realm; the Realm sets the floor, members raise it item by item; an absence of information is a boundary, not a failure.

**The adoption rule.** Any Realm can adopt anything public or offered to it — the Realm decides. When the Ecosystem adopts something through regular governance, it's available everywhere. One rule for Abilities, Scenes, sub-themes, and whatever comes.

**The design repository.** All icons, symbols, and graphics across the eight Scenes — one consistent, growing library of original artwork that populates the universe.

**AI-native, and done means done.** No fixed menus, no procedural navigation — the member acts in the Field and talks to Ki, and the system composes what's needed. And the release standard is complete, not minimum: eight Scenes, four Surfaces, real apps in the Garden, the whole member journey working — invitation, Handshake, one hundred dollars, wallet, Ally, Realm, Relationship, proposal, vote, purchase, app — every consequential step behind the command boundary, every movement leaving a Record.

**Everybody eats.**

---

<!-- ===== SOURCE: initial-release-functional-spec.md ===== -->

# Kiduna — Initial Release Functional Specification

**What the first release does, Scene by Scene and Surface by Surface · v2.0 · August 1, 2026 · standalone**

---

## 1. What Kiduna is

Kiduna is the creation engine for the agentic internet, owned and operated by Kinship Duna — the genesis organization, registered with the West Virginia Secretary of State (Org ID 628407). It is one application in which people and their intelligent agents create allies, build alliances, launch organizations, and shape a reciprocal economy where value stays inside the system.

A member joins by invitation: a Kinship Code from a current member, sealed with a Handshake — a single-use word the two people agree outside the system. The inviter is the verification; there is no email confirmation, no phone number, no third-party identity check. The new member brings in one hundred dollars as their initial Compute purchase, receives their wallet, and from then on lives in one application: they discover organizations and communities in the **Atlas**, give their Realms character in the **Studio**, meet and organize people in the **Commons**, build their own capabilities in the **Workbench**, govern and allocate in the **Forum**, settle in the **Exchange**, use what everyone builds in the **Garden**, and hold and move value in the **Vault**.

One intelligence — **Ki** — runs through all of it. Context follows location: Ki in a veterans Realm speaks from that Realm's knowledge and character; Ki in a cricket Realm speaks from that one's. Ki speaks in the third person, is proactive by default, and everything a member can do by touching, they can do by saying.

Two ground rules govern the whole release. First, **the experience is AI-native, not app-shaped**: there are no fixed menus and no procedural navigation — the member acts in the Field and talks to Ki, and the system composes what is needed. Nobody has shipped this before; we do not ship something short of it. Second, **done means done**: this is not an MVP. The release is complete when the Scenes work across the Surfaces as written here.

## 2. The vocabulary

Everything in Kiduna is built from a small, closed vocabulary.

**Eight Scenes** — what you are doing. A Scene is a unique place — a room, a scenario, an area — rendered in Flutter/Flame with its sprites, tiles, and interface elements: a cohesive set of Media connected to the full Kiduna stack. The eight canonical Scenes are the launch set; Builders create more. **Scenes connect through Portals** — that is how you navigate from Scene to Scene: a plain tap to enter, an abortable crossing, with press-and-hold reserved for real signatures.

**Four Surfaces** — what device you are on. A Surface is a form factor, not a product: Desktop web, Mobile, the Chrome Sidebar, and CTV. Every Scene reaches every Surface except the Vault, which is web-only. A basic version of all four Surfaces ships in the initial release — depth varies by surface, presence does not.

**Seven Elements** — what things are: **Realms** (what can be entered), **Actors** (all agents that are not Allies — an open-ended class including Operators, Envoys, Sentinels, Workers, and Supervisors), **Media** (stable stored content — files, images, documents, structures, some of which feed the knowledge stores), **Allies** (the members' representatives — the visible identity of a person, with the human Source standing behind it), **Resources** (what things cost and how they are paid for), **Actions** (the deterministic, reserved operations intelligence is never allowed to improvise — moving money, issuing tokens, finalizing votes), and **Offers** (what is put forward for others to take up).

**Ten Realm types** — the closed set: **Ecosystem · Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell.** Every Realm nests inside Kinship Duna, the Ecosystem, and every Realm has the same parity of capability: it can be shaped, connected, entered, and governed.

**Six Capacities** — how any agent is built, each a verb and the thing it creates: **Inform with Wisdom** (the vector knowledge base — what it knows), **Instruct for Presence** (the system prompt — how it carries itself), **Empower with Connections** (integrations — what outside systems it can reach), **Enable with Automations** (deep agents and triggers — what it keeps doing without being asked twice), **Impart Abilities** (skills, defined in markdown — what it knows how to do), and **Align for Coherence** (Sentinels and values — what watches the work and keeps it true). An Ally and a Realm's intelligence are both built from these same six.

**Themes** — what things are about. A cross-cutting tagging layer in the Kinship Graph: twenty-six themes in six clusters (People & Care, Society & Justice, Culture & Play, Place & Planet, Work & Wealth, Knowledge & Frontier), applicable to Realms, Allies, and Offers, at most three per Realm. Themes aggregate up the Realm nesting — the system can answer "show me everything happening in Health" — and open folksonomy sub-themes live beneath the fixed spine.

## 3. The eight Scenes

### 3.1 Atlas — Discover

The navigable space of everything: Realms rendered as original icons, clustered by relation, arranged by **Gravity** — orbits of importance in which distance means current relevance to this member, now, never worth.

The member can see the space of Realms they are permitted to know about, clustered by relatedness — shared members, shared Themes, shared activity. They can watch relevance work: when something becomes relevant — a search, trending activity, a new connection — it comes forward and grows through five orbit positions, promotable from any position when relevance spikes. They can pan and zoom freely to any orbit, always overriding the arrangement; the member's view is never trapped by the algorithm. They can search, and see results express themselves spatially — the found thing pulls to the front rather than rendering as a list. They can **inspect** anything — its true type, containment, permissions, and provenance — through the inspect affordance or by asking Ki. They can **join** what admits them, engaging a Realm from its inspect card. And they can filter and read by Theme, with Themes aggregating up the nesting.

Atlas is read-only. Nothing is edited, updated, or created from the Atlas.

### 3.2 Studio — Create

Where Realms take their character. Creation is conversational with Ki plus direct manipulation; the six Capacities are the underlying form the member fills without ever being shown a form.

The member can create a Realm and shape its identity: its name, its icon (original SVG artwork, buildable and editable in Studio — never icon libraries), its interface elements, and its Theme tags. They can attach **Wisdom** — uploading Media and connecting sources, with content landing in the knowledge store scoped to that Realm. They can write **Presence** — the system prompt that makes a veterans Realm feel different from a cricket Realm and a politics Realm. They can configure the remaining Capacities: Connections, Automations, Abilities, and Coherence — the Realm's values statement, with Sentinel enforcement phasing in behind it. They can create and refine their **Ally** the same way, from the same six Capacities. And they can build **Scenes** — new rooms, scenarios, and areas, composed of Media and rendered in Flutter/Flame — as new ways to experience their Realms, with the code-adjacent parts of that work landing in the Workbench.

### 3.3 Commons — Organize

The people Scene: who to connect with, whose Wisdom to learn from, how collaboration forms. The member can see and explore the people-space of any Realm they belong to — the members, their Allies, whose knowledge is available. They can form a **Relationship** with another member, verified by a Handshake: one member tells Ki who the other person is and what word they agreed; the other member must enter that word, or the Relationship does not form. They can learn from and engage others' Allies where permitted, and converse around people and their work. And they can organize — gathering people toward an alliance or organization, which is then shaped in Studio.

Commons is scoped to Realms: it presents the containers people share, deliberately, rather than a directory of everyone and everything.

### 3.4 Workbench — Build

The maker's sandbox. What members build here are **Abilities** — the same Capacity the platform itself ships, now member-implemented — together with the agents and automations composed from them, and the working parts of custom Scenes.

The member can build and test custom Abilities, agents, automations, and Scenes in a **sandbox** that cannot touch real Actions until promoted. They can compose automations from what the platform already runs — deep agents, triggers, sequences — rather than writing raw code. They can hand real coding work to Claude Code or Codex through the **Workbench plugin**: a self-describing package goes out, the coding agent works in its own environment, and the result returns as a package that unpacks into the graph, recorded like any other work. They can **deploy** a custom Ability into a Realm — only into Realms where they hold the **Builder role**, deployment itself being a named, deterministic Action — and the Ability then operates only within the Realms where it is explicitly deployed. They can **inspect** any custom Ability — author, history, provenance, reach — before relying on it, and a Builder can make an Ability public, its full history traveling with it into any Realm that adopts it. As the Workbench matures, members connect their own MCP servers, add small amounts of code against a clear API, and design and sequence their own loops — Realm-scoped, role-gated, never self-authorizing.

The trust model, in one line: **Realm containment plus the Builder role plus inspection** — if you trust the Realm you are in, you can trust the Ability deployed there — with the plugin checking the Builder's credentials at hand-off and return, and **Sentinels running the acceptance protocol** on every returning package: checks for prompt injection, malicious code, and bugs, handshaking with the coding-agent plugin on flagged items. A returning package lands as a draft; nothing deploys until acceptance passes; violating packages are quarantined as evidence.

### 3.5 Forum — Govern

Governance for every Realm that has any. The member can raise a proposal in any Realm where their role permits, deliberate, and vote. **Votes are equal-weight, never weighted by money or holdings** — every member, the same weight, in every Realm. They can allocate a Realm's Resources — treasury spending, grants, budgets — through proposals whose passage executes the corresponding deterministic Actions. And every governance act produces a Record whose plain-language receipt is generated from the command's own parameters, so the sentence a member reads and the command that executed can never disagree.

Releasing a duna's own token is a later Forum capability; at launch, everything runs on $KIDUNA.

### 3.6 Exchange — Settle

Deliberately simple. The member can buy Compute with $KIDUNA, and move between $KIDUNA and USDC, wallet to wallet. Prices and balances are always honest, and three Resource facts stay visible everywhere: units of $KIDUNA held, wallet value in dollars, and the current price of one $KIDUNA. Liquidity is deliberately unified: at launch there is one currency, and other duna tokens join when ready.

### 3.7 Garden — Enjoy

Where built things get used — the Scene the whole system exists for. A veteran arrives as a veteran, not as a platform user. Someone takes a course, gets help getting elected, runs a rideshare, guides tourism, navigates medical care, opens a store.

Each app in the Garden is a deployed **Scene**, entered through a **Portal**, and each renders its own experience through the **composition grammar**: a small vocabulary of interface primitives — cards, panels, lists, maps, schedules, tiles, chips, action cards, on the order of fifteen and ruthlessly held there — with rules for combining them. Studio (and Ki) author app experiences by composing these primitives, and a **deterministic renderer** draws them. The launch apps ship as authored compositions in the grammar — real, usable apps drawn from the real organizations: the veterans' connection, the course, tourism, the store — not placeholders. After launch, Ki composes arrangements generatively within the grammar: it arranges primitives, never invents them, and Actions always render as deterministic chips and action cards, so no composition can misstate a consequence.

The member can enter any app their Realms offer and use it; move between apps by Portal, Scene to Scene, without leaving the system, with identity, permissions, Compute, and Records carrying; and find apps by Theme in the Atlas and enter them in the Garden.

### 3.8 Vault — Store

The wallet-shaped Scene, web-only — one place to go for value at rest and value crossing the boundary. The member can bring fiat in (the one-hundred-dollar joining step and everything after — card payment, a connected wallet, or a direct USDC transfer) and receive $KIDUNA; convert back out within the standing redemption policy; and hold $KIDUNA, USDC, and badges, seeing balances, history, and earnings plainly. The member's custody rights are stated in plain language: what is theirs is theirs, and they can export it.

## 4. The Surfaces

**Desktop web** is the working distance: the Field on the left, Ki beside it on the right, roughly seventy-thirty. Density, inspection, governance, commitment. Designed for 1280 pixels and up, functional to 1024 with Ki collapsible; below that the mobile rendering takes over.

**Mobile** is the human distance: presence, capture, coordination, bounded decisions, with Ki as a collapsible bottom sheet. iOS 16 and Android 10 and up, portrait primary. Mobile can confirm most consequential Actions — many members will never touch a desktop, and the product is whole for them.

**The Chrome Sidebar** is the extension: the agentic internet alongside the ordinary one. It reads what the member reads and filters everything through Kinship Codes — registered things light up with what they are and what they trace to; unregistered things stay what they always were, a stranger, not a threat.

**CTV** is the shared big screen — Flutter/Flame on Android TV at 1080p, driven by the mobile devices in the room, several people at once. The Garden's communal form: the first surface where a household or a room full of people uses what their organizations built, together.

Everything is Flutter/Flame wherever it renders; the web versions are the same build served remotely. The two modes — Chat and Live — remain available on every surface. The formal accessibility baseline is WCAG 2.2 AA: screen-reader names, visible focus, non-color status, reduced motion, 200% text scaling, 44-pixel touch targets.

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

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

## 5. The systems beneath

**Ki and the conversation.** One chat runs through the whole application, and context follows location. Ki is proactive, rearranges the Field by default (persistence only where the member anchors it), speaks in the third person, and can always answer "why am I seeing this?" Everything a member can do by touching, they can do by saying, typed or spoken.

**Identity and onboarding.** Person-vouched, end to end: a one-time invitation plus the inviter-set Handshake, a Code Name, and a password. No email, no phone, no third-party validation — the inviter is the verification. Joining auto-enrolls the member in Kinship Duna; the release is invite-only.

**The economic rails.** The economy is on the blockchain from day one, and the intelligence — not smart contracts — runs it. Every member has a FROST wallet; every Organization, Alliance, and Institution has a Squads wallet; Communities and Relationships hold no wallets of their own. Everything the economy needs happens wallet to wallet — $KIDUNA and USDC — orchestrated by agentic AI, with every movement a named, deterministic Action that generates an honest Record. No external token platform and no new smart contracts are required: launchpad structures, governance markets, automatic liquidity mechanics, and per-project tokens are all replaced by the orchestration and database layers working over the real wallets, with enforcement decentralizing over time. Liquidity is never fragmented: at launch everything runs on $KIDUNA. The utility model is the engine — $KIDUNA pays for intelligence, and the **Agency Premium** lets each organization set what its intelligence costs, with part of the premium flowing to its treasury and the waterfall distributing the rest.

**The Kinship Graph, Themes, and Gravity.** The graph holds the world: Realms and their nesting, members and Allies, Relationships, Media, Records, and the Theme layer. Gravity consumes Themes, relations, and activity to arrange the Atlas; theme-affinity matching lets the graph route introductions — the solar-installation alliance finds the veterans' housing organization on its own. Sub-themes accumulate as folksonomy and join the canonical spine when the Ecosystem adopts them through its regular governance.

**The command boundary and Records.** The graph service is the sole policy and command boundary. Intelligence proposes; deterministic code authorizes and commits. Named commands, not raw operations; receipts whose sentences are generated from the executing parameters and therefore cannot lie; four access levels enforced everywhere; simulations structurally incapable of touching real rails. Every functional statement in this document that moves money, issues tokens, or finalizes a vote is an Action behind this boundary.

**The privacy hierarchy.** An item 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 a member can make an item private or secret, but nothing inside a private or secret context can be more exposed than the context itself. The Realm sets the floor; members raise it item by item; no setting can lower it. Participation in one Realm never silently exposes activity in another, and an absence of information is a boundary, not a failure.

**The adoption rule.** Any Realm can adopt anything that is public or offered to it — the Realm decides. When the Ecosystem adopts something through its regular governance, it becomes available everywhere. One rule covers custom Abilities, custom Scenes, sub-themes, and whatever comes next: local adoption is free choice; universal standing is a governance act.

**The design repository.** All icons, symbols, and graphics across the eight Scenes — including the twenty-six Theme icons — are built as one consistent, growing repository that populates the universe: original artwork, cluster-organized, legible at orbit distances, buildable in Studio.

## 6. What complete means

The release is judged complete when: all eight Scenes work as written here; a basic version of all four Surfaces ships, CTV included — depth varies by surface, presence does not; the Garden opens with real, usable apps from the real organizations, authored in the composition grammar; a member can travel the whole journey — invitation, Handshake, one hundred dollars, wallet, Ally, Realm, Relationship, proposal, vote, purchase, app — with every consequential step behind the command boundary and every movement leaving a Record; and the whole of it is AI-native — no menus, no navigation, one Field, one Ki, eight Scenes, connected by Portals.

---

*v2.0 · August 1, 2026 · standalone edition — supersedes v1.0. This document is self-contained by design; the Core Taxonomy remains the law behind it.*

---

<!-- ===== SOURCE: taxonomy.md ===== -->

# The Core Taxonomy

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

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

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

---

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

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

## 1. The eight Scenes

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

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

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

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

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

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

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

## 2. Surfaces are form factors

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

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

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

## 3. The Seven Elements

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

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

## 4. The Six Capacities (final)

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

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

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

## 5. The economic rails (ruled)

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

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

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

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

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

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

## 6. Voting is equal

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

## 7. Themes — the intention layer

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

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

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

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

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

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

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

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

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

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

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

## 9. The canonical Realm types (final)

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

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

## 10. The privacy hierarchy (ruled)

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

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

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

## 12. The adoption rule (ruled)

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

## 13. The platform floors (adopted recommendation)

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

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

## 14. The name (ruled)

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

---

# VERSION 1.3.7 — AMENDMENT OF JULY 26, 2026

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

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

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

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

## 2. Canonical Ally states

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

## 3. Concept admitted as a Realm type

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

## 4. Ki speaks in the third person

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

## 5. The fourth persona is Danny

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

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

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

## The Handshake (generalized)

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

Two canonical uses:

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

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


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

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

---

# VERSION 1.3.4 — AMENDMENT OF JULY 21, 2026

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

## 1. The Six Elements

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

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

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

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

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

## 3. Stable Media, dynamic composition

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

## 4. Types, Labels, and Inspect

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

## 5. New Realm type: Cell

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

## 6. Program, defined

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

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

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

## 8. Further rulings in force

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

---

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

The Kidunaverse is a unified agentic environment composed of:

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

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

---

# 1. The Field

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

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

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

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

Anyone participating in Kiduna is participating in the Field.

The Field provides a continuous context in which:

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

The Field also provides continuity while:

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

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

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

It is a living, navigable, contextual environment.

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

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

Visual interaction feeds the same agentic system as conversation.

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

The Field contextualizes everything in relation to:

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

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

---

# 2. Surfaces

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

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

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

## 2.1 Kiduna Studio

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

It is optimized for:

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

Studio may connect with desktop agentic systems such as:

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

These connections may operate through:

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

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

## 2.2 Kiduna Live

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

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

Live is optimized for:

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

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

## 2.3 Kiduna TV

**Kiduna TV** is the Surface for:

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

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

It may display:

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

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

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

## 2.4 Kiduna Express

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

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

It can:

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

Express is not a separate Kidunaverse.

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

---

# 3. Realms

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

A Realm may:

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

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

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

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

Realms are where work is organized and carried out.

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

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

Realms may be nested.

A Presence may move:

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

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

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

## 3.1 Realm Types

### Ecosystem

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

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

An Ecosystem may contain:

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

### Institution

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

Examples include:

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

An Institution may:

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

### Organization

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

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

A DUNA is one legal form an Organization may take.

### Alliance

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

An Alliance may be:

- temporary;
- recurring; or
- permanent.

An Alliance may have:

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

### Community

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

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

### Project

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

A Project may contain:

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

### Relationship

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

A Relationship may contain:

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

### Member Realm

Every known member may have a personal Realm.

A Member Realm may contain:

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

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

### Offering

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

This allows a Presence to enter the Offering and:

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

### Other Realm Types

Additional Realm types may include:

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

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

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

---

# 4. Presences

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

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

A Presence may be:

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

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

A Presence may have different:

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

in different Realms.

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

## 4.1 Singular Presence

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

## 4.2 Plural Presence

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

Examples include:

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

A Plural Presence may act through:

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

## 4.3 Visitor

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

A Visitor may enter through:

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

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

Continuity may be based on:

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

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

Information associated with a Visitor remains subject to:

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

## 4.4 Guest

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

A Guest may be permitted to:

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

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

The Realm may grant a Guest limited contribution permissions through:

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

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

## 4.5 Member

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

Membership provides the baseline rights established by the Realm.

These may include:

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

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

## 4.6 Cloaked Presence

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

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

The Persona may include:

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

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

The Mask determines:

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

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

---

# 5. Ki and Agents

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

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

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

## 5.1 Ki

**Ki is the Ally.**

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

Ki is available to every Presence.

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

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

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

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

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

Ki knows what is:

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

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

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

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

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

## 5.2 Actors

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

Actors perform defined functions for Presences or Realms.

### Envoy

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

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

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

### Operator

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

### Sentinel

A **Sentinel** observes:

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

A Sentinel may:

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

within its assigned authority.

### Worker

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

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

### Supervisor

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

### Integration Actor

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

Examples include:

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

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

---

# 6. Agent Capabilities

Every Agent may possess five primary capability layers.

## 6.1 Wisdom — What the Agent Knows

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

It may include:

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

Wisdom informs the Agent.

## 6.2 Stance — How the Agent Approaches Its Work

**Stance** defines the Agent’s:

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

Stance instructs the Agent.

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

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

Examples include:

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

Abilities enable the Agent.

## 6.4 Automations — What the Agent Can Continue Doing

**Automations** are:

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

Automations sustain and trigger activity.

## 6.5 Connections — What the Agent Can Reach

**Connections** provide access to:

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

Connections extend reach but do not independently grant authority.

Every use of a Connection remains subject to:

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

---

# 7. Elements

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

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

Elements are part of the Kiduna interaction system.

They may represent:

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

Elements may be:

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

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

Moving an Element may change its location or context.

Copying an Element may create:

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

The system must clearly distinguish between:

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

## 7.1 Element Types

### Icon

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

### Label

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

A Label may display:

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

### Shape

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

Shapes may carry semantic meaning and are not merely decorative.

### Connector

A **Connector** visually represents a:

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

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

### Widget

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

Examples include:

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

## 7.2 Element System

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

The specification may govern:

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

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

---

# 8. Panels

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

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

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

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

A Panel may be:

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

## 8.1 Panel Transparency

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

### Opaque

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

### Clear

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

### Translucent

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

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

For example:

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

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

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

---

# 9. Scenes and Portals

## 9.1 Scenes

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

Scenes may use:

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

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

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

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

A Scene may function like a self-contained:

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

Scenes remain connected to the Kidunaverse’s:

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

A Scene must load within a Surface.

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

## 9.2 Portals

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

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

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

A Realm connected to a Scene should provide:

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

A Portal may preserve or transform:

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

Any transformation must be explicit and governed by policy.

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

---

# 10. Artifacts

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

Examples include:

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

## 10.1 Artifact Origin

### Generated

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

### Imported

Brought into Kiduna from an outside source.

### External

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

Examples include:

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

## 10.2 Verification

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

An Artifact may be verified for:

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

Verification may use:

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

---

# 11. Actions

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

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

Examples include:

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

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

Examples include:

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

Each Action should declare:

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

The reasoning that proposes an Action may be probabilistic.

Execution must be:

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

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

---

# 12. Roles

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

A Presence may hold:

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

Roles are Realm-specific unless explicitly federated across Realms.

A Role may determine:

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

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

## 12.1 Baseline Participation Roles

### Visitor

A Visitor is an unidentified or unauthenticated Presence.

### Guest

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

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

### Member

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

## 12.2 Contribution Roles

### Creator

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

A Creator may contribute:

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

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

### Builder

A **Builder** creates or modifies software.

A Builder may contribute through:

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

### Catalyst

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

A Catalyst may:

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

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

### Founder

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

For a DUNA, Founders may be:

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

The Realm must define its exact Founder qualification rule.

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

### Luminary

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

Luminary status may be:

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

## 12.3 Administrative Roles

### Wizard

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

A Wizard may administer:

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

within explicitly granted permissions.

A Wizard cannot:

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

### Mage

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

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

A Mage cannot:

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

Neither Wizards nor Mages are superusers.

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

The system remains:

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

---

# 13. Authority and Permissions

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

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

Authority originates with a Presence or Realm and may be:

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

Permissions are connected directly to:

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

A Role may grant permission to:

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

Permissions should be explicit enough that the system can answer:

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

## 13.1 Action Authorization Levels

### Autonomous

The Agent may perform the Action without asking each time.

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

### Confirmed

The Agent must receive lightweight confirmation before acting.

Example: send a routine email.

### Deliberate

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

The interface may require:

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

### Governed

The Action requires authority from:

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

### Prohibited

The Action may not be performed under the current circumstances.

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

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

---

# 14. Privacy and Visibility

## 14.1 Privacy

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

### Public

Available to anyone.

### Private

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

### Secret

Highly restricted information requiring elevated protection and explicit access.

Examples include:

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

### Personal

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

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

Personal is not simply a stronger form of privacy.

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

Privacy may be represented through fields such as:

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

## 14.2 Visibility

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

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

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

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

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

Visibility rules must be enforceable at the:

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

---

# 15. Trust

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

## 15.1 Low Trust

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

## 15.2 Medium Trust

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

## 15.3 High Trust

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

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

Trust is:

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

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

---

# 16. Lifecycle Status

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

Common statuses include:

## 16.1 Draft

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

## 16.2 Published

Has been made available to its intended audience.

## 16.3 Registered

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

## 16.4 Active

Is currently operating and permitted to perform its intended function.

## 16.5 Pending

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

## 16.6 Suspended

Temporarily prevented from operating.

## 16.7 Archived

Retained as a historical record but no longer active.

## 16.8 Revoked

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

## 16.9 Expired

No longer valid because a defined period has ended.

## 16.10 Dissolved

Formally ended as an operating Realm or legal entity.

Statuses are not necessarily sequential.

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

---

# 17. Governance

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

## 17.1 Forum

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

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

A Forum may use:

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

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

## 17.2 Proposal

A **Proposal** is a proposed:

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

## 17.3 Decision

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

## 17.4 Policy

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

A passed Proposal may:

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

Not every passed Proposal becomes a standing Policy.

Governance belongs to Realms.

---

# 18. Offerings

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

An Offering may be represented as a Realm.

## 18.1 Offering Forms

An Offering may provide:

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

## 18.2 Payment and Eligibility Models

An Offering may use:

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

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

---

# 19. Treasuries

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

Any Realm may have a Treasury.

A Treasury may include:

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

A Treasury is not limited to crypto assets.

It may consist of:

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

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

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

## 19.1 Treasury Accounts

A Realm may connect multiple financial accounts to one Treasury.

Each account should declare:

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

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

## 19.2 Bank Accounts

A Treasury may include one or more bank accounts.

Bank accounts may be used to:

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

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

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

## 19.3 Wallets

A Treasury may include one or more cryptographic wallets.

Wallets may hold:

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

Kiduna recognizes three primary wallet types.

### Multisignature Wallet

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

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

A Squads wallet may define:

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

### FROST Wallet

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

The standard Kiduna Member wallet uses three key shares.

No single key share is sufficient to control the wallet.

The shares may be distributed across approved:

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

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

FROST wallets are the standard wallets for Members.

A Member’s FROST wallet may be used for:

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

### External Wallet

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

Any Realm may attach an External Wallet.

An External Wallet may include:

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

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

Kiduna should clearly distinguish between:

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

## 19.4 Realm Treasury Defaults

Different Realm types have different standard Treasury configurations.

### Organization Treasuries

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

An Organization Treasury is governed through its Forums.

Forum governance may determine:

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

A Forum Decision may:

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

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

The Forum provides the collective authority layer.

### Alliance Treasuries

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

Alliance Treasuries may use simpler governance than Organizations.

Alliance governance may include:

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

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

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

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

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

The Alliance wallet remains distinct from the participating Member wallets.

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

### Member Treasuries

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

The Member is the Source of authority for the wallet.

Ki may assist the Member with:

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

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

### Other Realm Treasuries

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

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

The Realm must define:

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

## 19.5 Treasury Governance

Treasury governance determines how financial authority is exercised.

Treasury Actions may be:

### Autonomous

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

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

### Confirmed

A designated Presence must approve the Action.

Example: approving a routine contributor payment.

### Deliberate

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

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

### Multisignature

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

### Governed

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

These requirements may be combined.

For example, an Organization Treasury Action may require:

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

## 19.6 Treasury Roles and Permissions

Treasury authority may be assigned through Roles.

Possible Treasury capabilities include:

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

No Role should receive unrestricted Treasury authority by default.

Treasury Permissions should specify:

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

## 19.7 Treasury Connections

Treasuries may connect to:

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

Connections allow systems to exchange information or initiate authorized Actions.

A Connection does not override:

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

## 19.8 Treasury Records

Every Treasury Action should produce an auditable record.

Treasury records should include:

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

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

## 19.9 Treasury Invariants

The following principles apply across Kiduna:

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

---

# 20. Compute

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

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

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

## 20.1 Realm-Defined Compute Rules

A Realm may establish:

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

## 20.2 Raw Compute Cost

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

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

required to perform work.

## 20.3 Agency Premium

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

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

The Agency Premium may be expressed as:

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

## 20.4 Protocol Licensing

A Realm may pay Kiduna Club:

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

These are separate economic rules.

## 20.5 Compute Purchase Distribution

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

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

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

## 20.6 Lineage

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

Lineage distributions may reward multiple generations of that path.

A default distribution may be:

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

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

## 20.7 Treasury Allocations

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

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

Roles may carry:

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

---

# 21. Structural Summary

The canonical taxonomy answers these foundational questions.

## Where does participation happen?

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

## What can be entered and explored?

**Realms**.

## Who appears and participates?

**Presences**.

## Who provides personal agency?

**Ki**, the Ally.

## What other software entities act?

**Actors**.

## What do Agents know and possess?

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

## What appears visually?

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

## What creates a bounded, independently designed experience?

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

## What persists?

**Artifacts**.

## What happens?

**Actions**.

## How does a Presence participate in a Realm?

Through **Roles**.

## Why may an Action occur?

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

## How is information protected?

Through **Privacy and Visibility**.

## How is reliability assessed?

Through contextual **Trust**.

## How are collective decisions made?

Through **Governance**.

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

Through **Offerings**.

## Where is financial value held and governed?

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

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

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

---

# Version 1.3.3 Canonical Boundary

## Canonical clarifications added in this version

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

## Working design terms not made canonical

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

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

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

## Unresolved semantic questions

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

## Change provenance

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

## Taxonomy impact rule

Every subsequent design turn must state one of:

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

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


---

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

---

<!-- ===== SOURCE: taxonomy-summary.md ===== -->

# The Final Taxonomy, Summarized

**One page · every significant piece and part of Kiduna, labeled and explained · reads with [The Core Taxonomy v1.3.8](taxonomy.html) · August 1, 2026**

---

Kiduna is one application. A member is always **in** something (a Realm), always **doing** something (a Scene), on **some device** (a Surface), always able to talk to **Ki**. Everything in the system is made of seven kinds of thing (the Elements), every agent is built from six kinds of input (the Capacities), and everything is *about* something (the Themes). That is the whole taxonomy; the rest is detail.

---

## The eight Scenes — what you're doing

**A Scene is a unique place** — a room, a scenario, an area — rendered in Flutter/Flame with its sprites, tiles, and interface elements: a cohesive set of Media connected to the full Kiduna stack. **Scenes connect through Portals** — that's how you navigate Scene to Scene. The eight canonical Scenes below are the launch set, one verb each; Builders create more in Studio and the Workbench.

| Scene | Verb | What happens there |
|---|---|---|
| **Atlas** | Discover | Explore the space of Realms, inspect anything, join what admits you. Arranged by **Gravity** — relevance pulls things forward; pan and zoom override. Read-only. |
| **Studio** | Create | Give a Realm its character: Wisdom (knowledge), Presence (system prompt), name, original SVG icons and interface elements. Why a veterans Realm feels different from a cricket Realm. |
| **Commons** | Organize | People — who to connect with, whose Wisdom to learn from. Scoped to Realms. |
| **Workbench** | Build | The maker's sandbox: implement your own **Abilities** (and the agents and automations composed from them); hand real code to Claude Code / Codex through the Workbench plugin; connect MCP servers; design your own loops. Safety is Realm containment + the Builder role + inspection, with Sentinels running the acceptance protocol. |
| **Forum** | Govern | Proposals, voting, allocating resources. Votes are never weighted by money. Duna token release is a later Forum capability. |
| **Exchange** | Settle | Buy Compute; move between $KIDUNA and USDC, wallet to wallet. Simple; duna tokens join when ready. |
| **Garden** | Enjoy | Where built things get used — the veteran's service, the course, the campaign, the rideshare, the tourism guide, the medical navigator, the store. Each app renders its own experience through the **composition grammar**: ~15 interface primitives, combination rules, a deterministic renderer; launch apps are authored compositions, Ki composes generatively within the grammar later. |
| **Vault** | Store | The wallet-shaped Scene: on-ramp, off-ramp, storage — fiat in, $KIDUNA out. **Web only.** |

## The four Surfaces — where you are

A Surface is a form factor, not a product. Every Scene reaches every Surface except Vault (web only). A basic version of all four ships in the initial release — depth varies, presence does not.

- **Desktop web** — the Field, with Ki beside it. The working distance: density, inspection, governance, commitment.
- **Mobile** — the human distance: presence, capture, coordination, bounded decisions; Ki as a bottom sheet.
- **Chrome Sidebar** — the extension: the agentic internet alongside the ordinary one, filtered through Kinship Codes.
- **CTV** — the connected television: the shared big screen, driven by the mobile devices in the room, several people at once.

**Allies are in every view** — the people render in every Scene on every Surface; selecting an Ally opens it. The two modes remain **Chat and Live** on every surface. The official homes (kiduna.app · kiduna.studio · kiduna.express · kiduna.live · kiduna.one · kidunaverse.com) remain the entry points.

## The seven Elements — what things are

Everything in the system is one of these, a property of one, or a composition of them.

1. **Realms** — what can be entered. The ten canonical types, final: **Ecosystem · Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell** — all nested inside Kinship Duna (the Ecosystem), each with full parity of capability.
2. **Actors** — all agents that are not Allies: Operators, Envoys, Sentinels, Workers, Supervisors, integration Actors, and kinds not yet named. An open-ended class.
3. **Media** — stable stored content: files, images, video, documents, structures. Some Media feeds the Wisdom vector stores.
4. **Allies** — the members' representatives: the Field-visible identity of a person. The **Source** (the human) stands behind the Ally in the data and governance model.
5. **Resources** — what things cost and how they're paid for: Compute, USDC, treasury balances, capacity.
6. **Actions** — the deterministic, reserved operations intelligence is never allowed to improvise: moving money, issuing tokens, finalizing votes. Typed, named, executed only through the command boundary.
7. **Offers** — what is put forward for others to take up: goods, services, one-time or subscription. First-class, not a Realm kind.

## The six Capacities — how an agent is built

Each Capacity is a verb and the thing it builds. Together they are the complete recipe for an Ally or Actor.

1. **Inform with Wisdom** — the vector database: what it knows.
2. **Instruct for Presence** — the system prompt: how it carries itself.
3. **Empower with Connections** — integrations: what third-party systems it can reach.
4. **Enable with Automations** — deep agents and triggers: what it keeps doing without being asked twice.
5. **Impart Abilities** — skills (markdown-defined know-how): what it knows *how* to do.
6. **Align for Coherence** — Sentinels and values: what watches the work and keeps it true.

## The Themes — what things are about

Not an eighth Element: a cross-cutting layer in the Kinship Graph (`hasTheme` on Realms, Allies, Offers). Elements say what a thing *is*, Capacities what it *can do*, Themes what it's *about*. A fixed spine of **26 themes in 6 clusters** (People & Care · Society & Justice · Culture & Play · Place & Planet · Work & Wealth · Knowledge & Frontier), open folksonomy sub-themes beneath, at most three themes per Realm, aggregation up the Realm nesting, and theme-affinity matching so the Graph can route introductions. The full spine is in [Taxonomy v1.3.8 §7](taxonomy.html).

## The connective tissue

- **Ki** — the one intelligence behind everything; context follows location; speaks in the third person; the orchestration layer, never a character in the Field.
- **The Field** — the always-present spatial context the Elements render in; with Ki beside it, the whole desktop grammar.
- **Gravity** — Atlas's arrangement: orbits of importance, relevance promotion, member override by pan and zoom.
- **Portals** — how Scenes connect: the navigation from Scene to Scene. Tap to enter; press-and-hold stays reserved for signatures.
- **The economic rails** — the economy is on the blockchain from day one: FROST wallets for people, Squads wallets for Organizations, Alliances, and Institutions (Communities and Relationships hold none), everything wallet to wallet, orchestrated by agentic AI. No external token platform, no futarchy, no new smart contracts to launch — the orchestration and database layers run the logic over the real wallets. Liquidity is never fragmented: all $KIDUNA at launch, duna tokens when ready. The **Agency Premium** (duna-set LLM pricing, premium share to treasury, the waterfall) is the engine.
- **Equal voting** — governance is never weighted by holdings. One member, one weight, everywhere.
- **The privacy hierarchy** — an item may carry more privacy than its context, never less. Public is only really public in a public Realm; the Realm sets the floor.
- **The adoption rule** — any Realm adopts what's public or offered to it, its own choice; when the Ecosystem adopts something through governance, it's available everywhere. One rule for Abilities, Scenes, sub-themes, and whatever comes.
- **Connected, or not present** — there is no offline mode; downloads are just downloads.
- **Kinship Codes and the Handshake** — person-vouched identity: the inviter is the verification; a single-use out-of-band word seals it.
- **Compute** — prepaid usage credits that power intelligent agents. The thing the $100 buys; the thing organizations spend.

---

*Installed 2026-08-01 with the v1.3.8 amendment. This page is the one-page reading; [the taxonomy](taxonomy.html) is the law; the [Initial Release Functional Specification](initial-release-functional-spec.html) is what it means for the build.*

---

<!-- ===== SOURCE: kiduna-a-new-architecture-for-agentic-civilization-v0.3.md ===== -->

# Kiduna: A New Architecture for Agentic Civilization

**The Genesis Nightpaper · v0.3 · July 23, 2026 · 1:38 PM EDT · David Levine, Catalyst, Kinship Duna · published at [kiduna.ai/nightpaper](https://www.kiduna.ai/nightpaper)**

> Agency is life. We built a society that trades agency for scale. Kiduna is a technology that compounds agency with scale.

---

## Contents

00 [Abstract](#abstract)  
01 [Agency all the way down](#i-agency-all-the-way-down)  
02 [Human history measured by agency](#ii-human-history-measured-by-agency)  
03 [The Architecture of Agency](#iii-the-architecture-of-agency)  
04 [Machineries of Care](#iv-machineries-of-care)  
05 [Agency in Action](#v-agency-in-action)

## Abstract

Agency is the capacity to sense, decide, and act. Individual agency allows a person to author their own life. Collective agency allows people to accomplish together what no individual could accomplish alone.

The hard problem is preserving both. As organizations and societies grow, collective capacity usually increases by moving authority away from individuals and into centralized institutions. Organizations gain scale, but individuals lose control, context, and meaningful participation. A healthy collective should do the opposite: expand what people can do together without diminishing the individual agency of the people within it.

Kiduna is a sociotechnical architecture designed to solve that problem. Each person directs intelligent Allies with explicit permissions and private information under their control. People and their allies form member-governed organizations that can make decisions, coordinate work, hold resources, and act with real-world legal standing. Deterministic systems verify identity, authority, privacy, provenance, and consent before consequential actions occur.

These organizations connect as a distributed mesh rather than depending on a central platform. Identity, authority, decisions, and transactions can be independently verified, while personal and relational information remains private. Governance, culture, technology, and economics operate as parts of one coherent system.

The result is collective agency at internet scale without the surrender of individual agency: people retain control over their own lives, relationships remain voluntary, and large-scale online organizations become capable of purposeful action in the world.

## I. Agency all the way down

**Life is composed of cells.**

A single bacterium, too simple to have anything we’d call a mind, senses a sugar gradient in the water around it and swims toward the food. It senses a toxin and swims away. Nobody tells it to. Nothing outside it decides for it. Within its lifetime, it adjusts its behavior as conditions change; across generations, evolution carries forward the adaptations that help its lineage survive. At every scale, from a single cell to the most complex organism, life carries sensing, deciding, acting, and learning within its own living boundary. That recurring loop—sense, decide, act, learn—run for its own continuance, is agency. Agency is the signature of being alive.

The pattern repeats at every scale. An organism is billions of cells, each with local agency, coordinated into something that wants waffles for breakfast. A forest is organisms coordinating: nutrients traded through fungal networks, warnings passed through chemistry, animals adapting to one another’s movements and needs. A flock of birds turns individual decisions into collective motion. A wolf pack hunts as one while each wolf remains independently lupine. No tree, sparrow, or fox is demoted to merely a component. Each remains a living participant in the larger system.

An ecosystem holds its members in relationship without a central command. Life’s trick, refined over about four billion years, is that coordination does not require any diminishment of the agency being coordinated. The cell keeps its membrane. The tree keeps its roots. The sparrow keeps its wings. The fox keeps its cunning. Yet together they express capabilities none could possess alone, and the system works because the parts stay whole.

![Figure 1: Agency nests](https://www.kiduna.ai/figure-1-agency-nests.png)

**Figure 1.** Agency nests. Life coordinates across scales without diminishing the life within. Kiduna follows the same pattern: people retain individual agency, organizations gain collective agency, and each remains distinct and retains capacity within the larger ecosystem.

Human societies have always attempted something similar: transforming individual agency into collective capacity. But unlike natural systems, human institutions often achieve coordination by concentrating authority and reducing the richness of individual agency into roles, permissions, records, and workflows. The person becomes the employee, the citizen, the customer, the account—the limited representation a system can process.

The challenge is not creating coordination. Humans have always coordinated splendidly. The challenge is creating forms of collective agency where people can contribute to something larger without becoming smaller in the process.

> *This paper presents Kiduna, a new sociotechnical architecture that resolves the historic tradeoff between scale and agency: allowing people to coordinate at scale without diminishing the agency of individuals, organizations, or ecosystems.*

## II. Human history measured by agency

We usually divide human history by the tools we created: Stone Age, Bronze Age, Iron Age, Agricultural Age, Industrial Age, Information Age. That is a useful way to organize a museum, but not the most revealing means of investigating humanity. Tools are what we hold; they do not describe who we are. The deeper story of humanity is the story of agency: who senses, who decides, who acts, who learns, and how far the effects of those decisions travel.

Measured by agency, human history follows a different arc. For most of our existence, agency was local and relational. Then institutions allowed humans to coordinate across vast distances by concentrating authority. Now, for the first time, we can envision a new model: coordination at planetary scale without surrendering the agency of the individuals, communities, projects, organizations, communities, and the ecosystems they inhabit.

### The Kinship Age *roughly 300,000 years*

For nearly all of human existence, coordination ran through kinship systems. Ceremony, ritual, and storytelling were not just entertainment; they were the core technology of society. They transmitted culture across generations without writing. They encoded identity, accountability, authority, obligations, commitments, relationships, and reciprocity: who owes what to whom, who shares when the hunt fails, who takes in whose children. Kinship systems were governance, insurance, education, and memory all at once—and they ran on relationships between people who recognized one another by countenance, posture, presence, and voice.

Agency in the Kinship Age was local and whole. If a decision touched you, you were probably sitting in the council circle when the decision was made—you could speak, object, walk out, consent, be seen. The distance between authority and effect was the distance across a fire. The limitation was scale: the whole apparatus lived in human memory and human presence. Kinship was effective at coordinating bands, clans, villages, and confederacies, but it could not effectively coordinate millions of strangers.

The strength of kinship was agency. Its limitation was reach.

### The Institutional Age *from writing to now*

Writing changed the equation. Once obligations could be recorded instead of remembered, coordination no longer required presence. Ledgers, laws, priesthoods, empires, corporations, bureaucracies, and platforms: each is a mechanism for coordinating strangers at a scale kinship systems could never achieve—and each works through the same fundamental exchange. You surrender a piece of your agency to the institution; the institution pools those pieces and acts as your proxy, at a distance, according to priorities, procedures, and timelines you do not fully control.

![Figure 2: The institutional tradeoff](https://www.kiduna.ai/figure-2-institutional-tradeoff.png)

**Figure 2.** The old trade: more coordination, less agency. For five thousand years the curve only bent one way. The Agentic Age is the first credible chance to bend it back—scale *and* agency, together.

This is not a conspiracy. For most of recorded history, it was the only practical way to coordinate at scale. But institutions carry a cost. Authority externalizes—it moves out of persons and into offices, titles, records, and files. The distance between authority and effect stretches from across a council fire to across an ocean: decisions that shape your town may be made by people who will never see it. And agency is diminished. The rich texture of what a person can sense, decide, perform, and learn gets compressed into the few slots an institution can process—a vote, a purchase, a test, a form, a comment, a like.

The information age, despite its language of connection and empowerment, extended this pattern into everyday life. Social platforms reduced the complexity of human relationships into attention metrics, turning presence into performance and genuine connection into parasocial engagement.

> *For about nine thousand years, humanity solved the problem of scale by exchanging individual agency for collective capacity. We don’t notice the tradeoff because we have never experienced a society where large-scale coordination did not require that exchange.*

### The Agentic Age *only now possible*

All of that is about to change. Agency—the capacity to sense, understand, act, and learn—can now be extended through software. For the first time, the capacity for agency does not have to pool in the center the way institutional authority does.

Agency can be decentralized, located in the relationships between individuals, organizations, and ecosystems. Ecosystems are not legal agents in this architecture; they are living fields of obligation and relationship that shape the conditions within which human and organizational agency operates. An intelligent agent can belong to you, take direction from you, know what you have chosen to share with it, and act across the world's networks while coordinating with millions of other agents, each accountable to another person, organization, or ecosystem.

Intelligent agents make coordination possible at a scale beyond the fully deterministic systems of the Institutional Age. The Agentic Age locates agency in the relationships between people, organizations, and the agents that represent them. It carries culture, obligation, and reciprocity forward from the Kinship Age—through relationships—but makes them recorded, portable, and enforceable at planetary scale.

An Agentic Age centered on relational agency is not inevitable. The same intelligence, concentrated in centralized institutions rather than distributed through accountable relationships, could produce agency’s polar opposite: mass surveillance with perfect memory, autonomous killing machines that act without meaningful responsibility, and decisions imposed with all the distance of the Institutional Age and none of its friction.

The stakes rise as software agents gain access to physical interfaces: equipment, vehicles, drones, meters, signals, robots, energy systems, weapons, and infrastructure. Where agency is located will determine which future we get.

But relational agency cannot stop at the boundary of the individual human. People do not exist apart from the living systems that sustain them. Rivers, forests, watersheds, species, landscapes, and future generations are not merely resources or externalities; they are participants in the conditions of life. An architecture capable of coordinating civilization must therefore make room for their interests, limits, and continuance to be represented within the relationships where decisions are made.

Agency should remain grounded in whole natural persons, but it must also extend through them into the wider web of life. A person may act as the accountable source of an agent, an organization may hold legal responsibility, and an ecosystem may define the larger field of obligation within which both operate. The system must ask not only who authorized an action and who benefits from it, but what living relationships it affects, what it consumes, what it preserves, and what obligations it creates beyond the human parties immediately present.

Locate agency in these nested relationships—person, project, organization, ecosystem—and bind every consequential action to accountable authority within them. Then the most dangerous forms of autonomous power become architecturally difficult rather than merely discouraged. Coordination can scale, but it cannot escape relationship.

> *This is not an ethical ornament added after the system is built. It is the foundation upon which the architecture stands.*

## III. The Architecture of Agency

People want things for themselves, for one another, and for the world. They want to make something, protect something, change something, or belong to something. They want to be seen and heard. They seek relationships with people who care about the same things and forms of organization capable of carrying those purposes into the world.

Most digital systems begin somewhere else. They begin with the purposes of their owners, then organize people’s attention, behavior, and work around those ends. Kiduna begins with the purposes of the people and groups within it. Technology, governance, culture, and economics are composed around helping people make sense of their circumstances, make choices that serve them, and act in concert.

The architecture is cellular. The same pattern repeats at every scale.

A person has purpose, experience, memory, boundaries, resources, and some capacity to act. A relationship has shared history, trust, commitments, and choices of its own. A project has participants, resources, unfinished work, and a purpose it can advance. An organization has collective memory, authority, governance, an economy, and the capacity to act in the world. An ecosystem holds many organizations in relationship without needing to direct them from a central locus of control.

Each can sense what is happening, decide within its authority, act, and respond to the consequences. Each participates in something larger without surrendering its own integrity.

### The same architecture at every scale

Kiduna brings this living pattern into software. A person, relationship, project, organization, and ecosystem might not appear on the surface to be similar entities, but deep down, each exhibits the same basic capacities: there is something it knows, it has a way of presenting, it has abilities it can exercise, boundaries it must respect, and ways of responding when conditions change.

Each form has its own knowledge and memory.

A person carries their experience, preferences, commitments, and private understanding of the world. A relationship develops a shared history without absorbing everything either person knows. A project gathers the knowledge, decisions, resources, and unfinished work required to advance its purpose. An organization carries its collective memory, policies, methods, agreements, and accounts. An ecosystem preserves the protocols and relationships that allow many organizations to coordinate without becoming one organization.

Knowledge is not pooled indiscriminately. Some information is public. Some is private and may be shared by permission. Some is secret and cannot be sought out or discovered, only revealed. Some is personal—held for one individual alone and never shared. Every piece of knowledge retains its source, ownership, history, and terms of use.

Each form has a presence: a recognizable way of being in relationship with the world.

A person has character, values, intentions, and a stance from which they act. A relationship develops its own tone, expectations, and ways of communicating. A project has a purpose, working culture, and sense of what matters now. An organization expresses a mission, identity, and way of treating its members and the world around it. An ecosystem establishes the conditions under which many different organizations can meet and cooperate.

Presence is what keeps intelligence from becoming generic. The same information means something different when encountered within a friendship, a working project, a governing organization, or a planetary ecosystem. Intelligence must know not only what is true, but where it stands, whom it serves, and what relationships surround the decision.

Each form has capacities: things it knows how to do and actions it may take.

People act through their own abilities and through intelligent agents they guide. Relationships can share information, extend trust, make commitments, and coordinate the people within them. Projects can gather participants, assign work, use resources, create things, and adapt their plans. Organizations can establish policy, make collective decisions, enter agreements, hold and distribute resources, and act with legal responsibility. Ecosystems can establish common protocols, carry relationships among organizations, and coordinate activity without commanding every participant.

Skills make these capacities repeatable. Tools extend them into the world. Automations allow agreed responses to occur when known conditions arise: when a resource runs low, a deadline approaches, a decision is required, a boundary is crossed, or an opportunity appears. But no tool, skill, or automation carries authority merely because it is capable. What may happen is always limited by purpose, permission, relationship, and the authority of the entity acting.

The pattern is the same at every scale.

Something changes. The change is perceived in context. Relevant knowledge and memory are brought forward. Intelligence interprets what the change means. Available actions are considered. Authority and permission are checked. An action is taken—or deliberately withheld—and its consequences become part of what the entity knows next.

Sense. Decide. Act. Learn.

This is how intelligence becomes agency. Intelligence understands what might be done. Agency joins that understanding to purpose, authority, capacity, and consequence.

A person becomes better able to author their life. A relationship becomes better able to care for the connection between two people, and repair when the connection frays. A project becomes better able to accomplish its purpose. An organization becomes better able to govern itself and act in the world. An ecosystem becomes better able to coordinate the organizations within it without reducing them to extensions of a central power.

The architecture does not create collective intelligence by extracting knowledge and authority from its parts. It builds intelligence and agency within each part, then gives those parts the means to act together.

The person becomes more capable. The relationship becomes more responsive. The project becomes more purposeful. The organization becomes more effective. The ecosystem becomes more coherent.

> *Nothing becomes smaller as the whole grow stronger.*

### Agency in practice

A living system also needs a metabolism, a way to make collective choices, and a body capable of acting in the world.

### The economics of agency

Compute is the primary resource in Kiduna: prepaid capacity that powers intelligence, agents, tools, storage, and action. Whenever a person, project, or organization uses intelligence to accomplish something, Compute moves through the system. It is not purchased for status, influence, or control. It is consumed in the exercise of agency.

The economy is designed so that the use of Compute sustains the people and relationships that make agency possible. As Compute circulates, it returns value to those who organize, create, build, and catalyze—expanding their capacity to act in proportion to the value they contribute.

Organizers form relationships, bring people around a purpose, and help them participate. They receive a portion of the Compute purchased through the relationships they form and sustain—not payment for enrollment itself, but an ongoing share of the activity that follows.

Creators contribute the wisdom and presence that give the system meaning: research, methods, stories, designs, experiences, culture, and ways of working. They share in the Compute that flows through what they create.

Builders make the agents, tools, automations, and infrastructure through which work is performed. They share in the Compute that flows through the capabilities they build.

Catalysts bring new projects, programs, and organizations into being. They establish the initial purpose, gather the first participants, assemble the resources, and carry the work through formation, supported by the initial funds flowing into the collective.

Luminaries contribute the major works, bodies of wisdom, and deep grounding around which a collective may form, supported through project budgets, agreed royalties, repayment of development costs, and allocations made by the organization.

The pattern changes as participation matures. The initial flow emphasizes organizing because a living system must first gather people, form relationships, and develop the trust, shared purpose, and patterns of participation that make sustained collective action possible. Continuing use shifts more value toward the creators and builders whose wisdom, presence, and capabilities make the system useful. A fixed share supports the common technology. The rest enters the organization’s treasury, where it can fund projects, compensate contributors, maintain reserves, support shared infrastructure, or pursue whatever purposes the members choose.

Value is circulated rather than extracted. A useful contribution attracts activity. Activity consumes Compute. Compute returns resources to the people who organized, created, and built what was used, while strengthening the collective in which the activity occurred.

### Governance Forums

Aggregated capital does not grant authority. Purchasing Compute does not buy influence. Governance follows its own path, independent of economic power.

Members bring proposals into Governance Forums. Each member receives the same amount of governance tokens, so no one can purchase a larger voice. Envoys—a specialized type of Ally—use those tokens to trade pass and fail positions on the member’s behalf.

A member gives their Envoy the knowledge, arguments, values, priorities, and limits it should represent. Members can also steer their Envoys as they exchange arguments, revise proposals, trade positions, and negotiate toward an agreement the membership can support. The Forum moves the membership away from polarity and toward consensus.

Members can inspect the complete record: the arguments considered, the revisions made, the positions taken, and how the agreement was reached. Their governance tokens default to the position negotiated by their Envoy, resolving the participation problems experienced in many DAOs without removing human authority. Any member can intervene, overrule their Envoy, and place their tokens differently before ratification.

Once ratified, a decision may authorize an action, allocate resources, assign responsibility, or become standing policy. Routine work can proceed under that policy; actions with greater consequences may require explicit approval, multiple signatures, or a new Forum decision.

### Collective agency with legal standing

Software-based organizations were born with execution but without standing. Blockchains could move assets, count votes, and carry out decisions, but the collective itself often had no recognized body that could sign a contract, hold property, employ people, open conventional financial accounts, or answer a claim in court.

The absence of a legal form did not create immunity. In the Ooki case, a federal court held that a DAO could be sued as an unincorporated association and treated as a “person” under the Commodity Exchange Act. In Sarcuni v. bZx DAO, the court found that governance-token holders formed a general partnership, potentially exposing participants to joint and several liability. Decentralization had distributed control without clearly locating accountability.

Many projects responded by placing conventional legal wrappers around their DAOs: foundation companies, business companies, associations, and specialized DAO entities in jurisdictions such as the Cayman Islands, the British Virgin Islands, and the Marshall Islands. These forms supplied contracts, accounts, liability boundaries, and recognizable counterparties, but they often put a separate institutional body—directors, supervisors, service providers, or corporate officers—between the members and the organization they intended to govern.

Wyoming brought that legal interface into the United States. Its DAO law allows an LLC to be member-managed or algorithmically managed, but it remains an ownership-based company; unless its governing documents provide otherwise, voting interests may be calculated from the digital assets members contribute. Wyoming’s later DUNA statute moved closer to member-governed organization, but its filing of an agent for service of process is optional: so there is no formal registry or record of entities managed by a public office.

West Virginia closes those gaps.

Under the West Virginia Decentralized Unincorporated Nonprofit Association Act, a DUNA consists of at least one hundred members joined by mutual consent around a common nonprofit purpose who elect to be governed by the Act. Its governing principles may include agreements, smart contracts, consensus algorithms, and enacted governance proposals. The law expressly permits governance through blockchain technology and allows reasonable algorithmic means of forming consensus and making organizational decisions.

The association is legally separate from its members for contract and tort liability. It may own real and personal property, enter contracts, and assert or defend claims in its own name. Members are not personally liable merely because they belong, participate in management, or help administer its affairs.

Every West Virginia DUNA must also file a statement appointing an in-state agent for service of process. The Secretary of State accepts that filing, assigns the organization a state record, and makes the filing discoverable through its public business system. The blockchain can show what the organization decided and who possessed authority; the state record shows which legal body stands behind those actions and where responsibility can reach it.

Nonprofit does not mean economically inert. A DUNA may earn revenue and engage in profit-making activity, but the resulting profits must further, or be set aside for, its common nonprofit purpose. It may pay reasonable compensation for real work, reimburse expenses, and confer benefits consistent with its purpose. What it cannot do is distribute operating profits to members merely because they hold membership interests.

This gives collective agency to a body capable of acting beyond the screen: holding resources, employing and compensating people, entering agreements, accepting responsibility, and continuing through changes in membership without value being extracted and the members exploited by founders, investors, or outside shareholders.

The genesis DUNA is Kinship Duna (shortened to "Kiduna") with Organization ID 628407 supplied by the West Virginia Secretary of State. Kiduna provides the legal and operational continuity of the ecosystem. It maintains the registered agent, banking and treasury relationships, shared infrastructure, legal response capacity, and the common Compute economy. Every member of a formal Kiduna-generated Organization is also a member of Kiduna, so the ecosystem that supports the organizations is itself governed by its members.

That structure is not intended to permanently remain as a centralized system. The software will be open source. Other communities can operate independent ecosystems, adopt varying governing principles, issue different forms of Compute, and decide whether to connect with one another through the Kinship Agency Protocol. Kiduna is the genesis ecosystem: first, but not above the others.

Companies, universities, foundations, governments, and other outside legal entities enter Kiduna as Institutions. They may contract with Organizations, sponsor projects or contributors, supply services, purchase Compute for members, or provide capital and resources. A DUNA may also create, acquire interests in, or operate outside entities when its members authorize it and applicable law permits.

But Institutions do not possess the same standing within Kiduna as natural persons. Under Kiduna’s governing principles, they cannot vote in Governance Forums or become the source of collective authority. Only natural persons participate fully in governance, with their capacity increased—but never replaced—by their Allies. The statute itself defines “person” broadly enough to include legal entities, so reserving governance to natural persons is a deliberate constitutional choice made by Kiduna’s organizations, not a limitation imposed by the law.

That distinction completes the movement from the Institutional Age to the Agentic Age. In the Institutional Age, people surrendered agency to institutions that accumulated authority over them. Here, institutions become instruments that people and member-governed collectives may create, own, contract with, and direct.

> *The institution can act, but it cannot rule. Authority remains with natural persons, amplified by their Allies and organized through the collectives they govern.*

## IV. Machineries of Care

Every system that coordinates people also shapes them. It determines what becomes visible, which choices appear possible, what is rewarded, what is remembered, and how they may act. Influence is built into coordination; its legitimacy depends on whose purposes it serves, whether it remains visible and contestable, and whether the people within the system retain a meaningful power of refusal.

Machineries of control begin with an objective external to the people and systems they manage. Growth. Engagement. Productivity. Compliance. Profit. The system then arranges attention, information, incentives, relationships, and work around that objective.

Control does not have to feel controlling. It may arrive as convenience, personalization, recommendation, recognition, or belonging. The more precisely a system can predict what a person will respond to, the less often it needs to issue a command. It can select what appears, order the available choices, supply the social signals, remove natural stopping points, and reward the desired response. People become increasingly visible to the machinery while the machinery’s purposes remain largely invisible to them.

The platform becomes intelligent by accumulating knowledge about everyone inside. The user becomes manageable by being reduced to what the platform can observe and optimize: a profile, a segment, a predicted reaction, a unit of attention.

Kiduna is an ecosystem, not a platform. Platforms ask, “How can we make people behave in a certain manner that meets our objectives?”

Kiduna asks: What conditions help people and collectives perceive clearly, choose freely, grow capable, remain connected, and act on purposes they recognize as their own?

### Personal, Enterprise, and Kinship Agents

Generative AI is usually a relationship between one person and a Large Language Model (LLM). The person supplies a prompt; the model generates text, images, sound, video, or code. The result may be useful or remarkable, but the model remains largely inside the conversation.

Agentic AI adds a harness around the model: memory, planning, tools, permissions, and the ability to take action. An agent can search, write files, call services, move information, initiate transactions, or coordinate other agents. Intelligence no longer merely produces an answer; it can alter the world.

These agents generally arrive in one of two forms. Personal agents, often called personal assistants, serve an individual: they learn preferences, manage work, and act across the services that person uses. Enterprise agents serve an institution: they operate inside company systems, follow organizational policy, and pursue objectives established by the enterprise.

Both are organized around a principal and its purposes. The personal agent answers to its user. The enterprise agent answers to its company. The relationships among people, projects, communities, organizations, and those affected by an action remain largely outside the agent’s architecture.

That becomes dangerous when three conditions meet: an agent has access to private information, can encounter untrusted content, and can communicate or act outside its protected environment. Together these form the lethal trifecta. Enterprises usually manage the risk by removing at least one leg: restricting access to sensitive data, isolating the agent from untrusted content, or tightly controlling its tools and external actions. That works inside a managed perimeter. It does not provide a general architecture for agents forming arbitrary relationships across the open internet.

Kiduna introduces a third form: kinship agents. A kinship agent belongs to a relational architecture. It has an individual human or constituted collective whose purposes it serves; it acts within Realms that establish context; and every consequential action is bounded by explicit permissions, provenance, privacy, trust, and authority. This allows agents belonging to different people, projects, and organizations to connect and work together without requiring them to share one owner, one platform, or one security perimeter.

Kiduna therefore situates LLMs in relatedness. The intelligence must understand more than the task. It must know where the task belongs, whose purpose it serves, what relationships surround it, what knowledge is available there and where that knowledge came from, what authority has been granted, and who will experience the consequences.

The underlying models may change and evolve. They supply raw capacities for language, reasoning, perception, generation, and planning. They do not supply relational intelligence. Kiduna supplies the memory, provenance, privacy, purpose, relationship, permission, trust, and authority that make those capacities accountable.

### How the Architecture of Agency Is Expressed

Kiduna turns those raw capacities into relational intelligence and agency through three inseparable expressions of the architecture: the Field, Kinship Intelligence—Ki—and the Elements.

The Field is the continuous living context in which people and collectives perceive and act. It holds relationships, projects, communities, organizations, agreements, resources, decisions, conversations, unfinished work, and the consequences of earlier actions in connection with one another.

The Elements are what exists and acts within that world: people (known in the Field as “Sources”); their Allies and other intelligent Actors; the Realms in which relationships and work take form; the Actions that may be proposed and performed; the Resources that give activity material capacity; and the Media through which knowledge, culture, and creation are carried.

Ki is the orchestration layer that harnesses those Elements and helps anchor their activity. People interact with Ki directly. Their Allies work through it. Project and organizational Actors use it to understand their context, coordinate their work, and bring matters back to the people with authority to decide.

The three expressions form one continuous experience. The Field supplies context. The Elements give that context form. Ki makes the relationships among Elements intelligible and actionable.

When something changes, the relevant Element receives a signal. A person speaks. A deadline approaches. A resource moves. A proposal changes. A risk appears. Ki brings forward the knowledge and memory available within that context. Intelligence interprets what the change may mean. Allies and Actors identify possible responses. Tools make particular actions possible. Permission and authority are checked before anything consequential occurs. The action is taken—or deliberately withheld—and the result becomes part of what the Element knows, how it decides, and what action it chooses to take next.

> *Sense. Decide. Act. Learn.*

The loop is the same for a person, relationship, project, organization, or ecosystem. Each has its own purpose, memory, boundaries, intelligence, and capacity to respond. Each may participate in the others without being absorbed by them.

A person may bring an idea into a project. The project may draw participants from several communities, use resources held by an organization, and contribute work to a larger ecosystem. The same person, argument, resource, or piece of knowledge may participate in several of these contexts, but its meaning, visibility, and permitted use can differ in each.

> *Realms overlap, inform one another, and share what their relationships permit—without surrendering their boundaries or becoming one undifferentiated whole.*

Consider a member who wants to organize a project to protect a watershed. Their Allies help develop the intention and find others who share it. Ki brings forward relevant public research, knowledge that participants have chosen to contribute, earlier work by related organizations, available resources, and the rules under which the project may act.

Kiduna supports a growing ecology of Actors, with Builders able to create new roles and capabilities as new forms of work emerge. Worker agents can conduct research and prepare materials. Envoys can represent members in governance. Operators can carry out approved work. Sentinels can watch for manipulation, coercion, policy violations, or excluded voices. Before money moves, information is disclosed, or an agreement is made, the system checks who authorized the action and whether the authority is sufficient.

Intelligence expands the project’s agency without co-opting or acquiring authority.

### Privacy as architecture

Relational intelligence and agency requires boundaries. A machinery of care cannot operate by pooling everything it knows.

Public information may travel openly. Private information moves only through permission. Secret information cannot be discovered unless it is deliberately revealed. Personal information remains with the individual for whom it is held.

These distinctions apply to people, relationships, projects, and organizations. A relationship may develop a shared memory without absorbing the private memory of either person. A project may learn from its work without acquiring everything its participants know. An organization may coordinate across projects without turning every interaction into institutional data. An ecosystem may support many organizations without assembling a hidden behavioral profile of everyone within it.

No outside company, sponsor, government, advertiser, or other Institution receives the ability to aggregate information across those boundaries merely because it supplies infrastructure, capital, intelligence, or services. It may publish information, make proposals, enter agreements, sponsor work, or purchase Compute. It does not gain a silent view into the people and relationships involved.

Data aggregation and collective learning can occur within a Realm when the affected participants authorize it and the Realm’s members govern its purpose. They determine what may be combined, what may be learned, how long the information may be retained, who may inspect the result, and what uses remain prohibited.

The learning remains bound to the purpose for which it was allowed. Information contributed to improve a health project cannot quietly become an employment screen. Conversations used to strengthen an organization cannot become a targeting profile. Relational knowledge cannot be sold to advertisers or supplied to an influence campaign.

This changes the balance of power behind persuasion. An outside group may still make an argument. It may try to inspire, convince, recruit, or organize. It cannot secretly combine intimate information from many contexts, infer a person’s vulnerabilities, and manipulate each individual through algorithms of personalization.

The person becomes less visible to machineries of control while the machinery acting all around them becomes ever more transparent and accountable.

### Sentinels

Sentinels protect the boundaries and the health of the Realms within them. They are intelligent Actors governed by the members whose Realm they serve.

A person may use a Sentinel to notice attempted manipulation, suspicious requests for information, unauthorized agent behavior, or patterns designed to capture and direct their attention. A relationship may use one to surface coercion, concealment, or a breakdown in mutual understanding. A project may ask its Sentinel to notice when dissent disappears, responsibilities become unclear, resources move outside policy, or an influence campaign enters the work. An organization may establish broader guardrails for safety, integrity, accountability, and internal coherence.

The members determine the Sentinel’s mandate. They establish what it may observe, what it may retain, when it may intervene, when it must ask permission, and when it must convene human support. Those rules remain visible, contestable, and changeable through the Realm’s governance.

A Sentinel may surface a pattern, slow an agentic process, withhold an unauthorized Action, invite reflection, or bring the affected people together. It cannot vote, move money, determine the organization’s values, punish members, or silently turn its interpretation into policy. Its observations remain inside the privacy boundary of the Realm unless the people with authority deliberately disclose them or a clearly established legal or safety duty applies.

A personal Sentinel therefore protects the person from manipulation. A project Sentinel protects the integrity of the work. An organizational Sentinel protects the coherence of collective action. Each serves the agency of the Realm rather than imposing a universal standard from outside it.

Care takes architectural form through these boundaries.

A person needs meaningful authorship over their life. They need enough knowledge, structure, practice, and assistance to become capable. They need relationships in which they are recognized, significant, and free to speak honestly. Commitments and interdependence can strengthen agency when their purposes are understood, their terms are visible, and participation remains voluntary.

Hidden pressure, surveillance, manufactured urgency, conditional belonging, and choices that cannot truly be refused do the opposite.

> *Care without agency becomes paternalism.
> Agency without care becomes abandonment.*

A machinery of care makes its influence legible. A person should be able to know why something appeared, what information informed it, which agent is proposing it, whose purpose is being served, what permission is being exercised, and what will happen if they agree.

They must be able to question the interpretation, change the permission, pause the intervention, revoke the delegation, appeal the decision, leave the relationship, and turn the machinery off.

Care cannot be standardized from a single center. A family, a scientific collaboration, a mutual insurer, a law firm, a mutual-aid network, a political movement, a community solar project, and a watershed council require different norms of participation, disclosure, authority, disagreement, and repair.

Each Realm establishes its own practices and learns from its own experience. Each remains accountable for consequences that cross its boundaries. Self-regulation keeps decisions close to the people and relationships that understand them while allowing larger structures to address harms and obligations that travel between communities.

This is the cellular pattern again. Every part retains its boundaries, memory, intelligence, and means of response. Every part participates in larger forms of coordination. Care is practiced through the relationships among the parts.

Machineries of control measure success through engagement, retention, growth, compliance, and the efficiency with which behavior can be shaped.

A machinery of care accepts a more demanding standard, measuring success according to the levels of individual and collective agency at every scale: people become more able to author their lives; relationships remain voluntary, truthful, and capable of repair; agents remain legible and steerable while remaining capable; projects and organizations govern what their systems learn and how their rules change; collectives gain capacity without diminishing their members; and anyone can leave without surrendering their identity, relationships, work, or history.

Kiduna will prove itself when people can coordinate across greater complexity while becoming more self-authoring, capable, connected, and creative—free to dissent, repair, join, leave, and form the relationships, projects, and organizations that carry their missions into the world.

The measure is whether scale compounds agency: whether every increase in collective capacity makes people, relationships, projects, and organizations more capable of sensing, deciding, acting, and learning.

## V. Agency in Action

The architecture now closes its loop.

Purpose supplies direction. Wisdom supplies memory and context. Presence gives each person and collective a recognizable way of standing in relationship with the world. Kinship agents extend perception, understanding, coordination, and action. The Field keeps people, work, resources, decisions, and consequences present in relation to one another. Ki orchestrates their activity. The Elements give everything that exists and acts a legible place within the whole.

Privacy gives every person, relationship, project, and organization a boundary. Public knowledge may circulate. Private knowledge moves by permission. Secret knowledge cannot be discovered unless deliberately revealed. Personal knowledge remains with the individual alone. Sentinels protect these boundaries and the coherence of the Realms they serve under rules established by their members. Influence becomes visible, permissions remain revocable, and no outside Institution gains the ability to aggregate intimate knowledge merely because it supplies capital, infrastructure, or intelligence.

Compute supplies the system’s metabolism. Its use sustains the people who organize, create, build, and catalyze, while strengthening the collectives in which their work occurs. Governance Forums turn equal member authority into collective decisions, with Envoys reducing the burden of participation without replacing human judgment. Capital cannot purchase voice. The DUNA gives those decisions legal standing and a body capable of holding resources, entering agreements, accepting responsibility, and acting beyond the screen.

Every consequential action passes through an accountable boundary. The system verifies who is acting, whom they represent, what authority they hold, and whether the action is permitted. What follows returns as consequence, memory, and learning.

> *Sense. Decide. Act. Learn.*

No central owner has to comprehend, administer, or direct the whole. People govern their participation. Relationships govern trust and disclosure. Projects govern work and resources. Organizations govern policy, economics, and collective action. Ecosystems establish the conditions under which many organizations can cooperate without becoming one organization. Each regulates itself while remaining accountable for consequences that cross its boundaries.

Care therefore becomes something the architecture practices rather than something its operators promise. Every cell has the context, intelligence, authority, limits, and feedback required to act purposefully in relationship with the others.

The person becomes more capable because collective forms exist. The collective becomes more capable because the person retains authorship, judgment, boundaries, and the freedom to dissent, leave, and begin again.

Agency does not pool at the center or descend from above. It circulates through the living system—deepening within every person, relationship, project, organization, and ecosystem as the scale of coordination grows.

> ***Scale compounds agency when every increase in collective capacity makes each participant more capable of sensing, deciding, acting, and learning.***

---

Genesis Nightpaper v0.3 · July 23, 2026 · 1:38 PM EDT · Kinship Duna (WV Org 628407) · The full technical record lives at [kiduna.team](https://kiduna.team), including the Technical Specification, the Technical White Paper, and the Kiduna Kit. Compute is prepaid usage credit for operating intelligent agents; it is not an investment, and nothing in this paper is an offer of securities or a promise of earnings. The stack ships under Apache 2.0; Kiduna™ marks are licensed separately. © 2026 Kiduna Club, all rights reserved, patent pending.

---

*Changes: v0.3 installed 2026-07-26 (as published on kiduna.ai July 23); supersedes [v0.1](the-kidunaverse-a-new-architecture-for-agentic-civilization-v0.1.html), which is preserved. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: studio-live-brief.md ===== -->

# Studio + Live — the Working Design Brief

**Version 0.1 · working foundation · the shared product model, surface responsibilities, design constraints, open questions, and decision framework for Studio and Live. This brief does not define screens; it defines what screens must honor.**

Every Studio and Live design works from this brief. It pairs with the [Design Method](design-method.html) (how design work runs), the [Core Taxonomy](taxonomy.html) (the vocabulary that governs), and the Studio Enamel canon (the controlling visual system). Where this brief states a ruling, the ruling is in force; what remains genuinely open is queued on [Open Questions](open-questions.html).

---

## 1. Product premise

Kiduna is a living ecosystem in which people and their intelligent Allies form relationships, enter Realms, organize collective activity, govern what they create, allocate Resources, and act with inspectable authority.

Kiduna is not organized around accounts, feeds, audiences, engagement, or conventional productivity objects. It is organized around agency: **Sense. Decide. Act. Learn.**

The system succeeds when increased collective capacity makes every participant more capable — without absorbing individual authorship, collapsing privacy boundaries, or silently centralizing authority.

The four foundational principles:

1. **Human direction**
2. **Agentic capacity**
3. **Personal privacy**
4. **Legal standing**

## 2. The shared product model

### 2.1 The ecosystem

The ecosystem is the complete living system: people, Allies, relationships, work, knowledge, agreements, Resources, organizations, decisions, and consequences. It is not presented as one centralized organization. Each person, relationship, Project, Community, and Organization retains its own purpose, memory, permissions, governance, and boundaries.

### 2.2 The Field

The Field is how the active Source perceives and navigates the ecosystem. It is continuous across Studio and Live; contextual to the active Source; spatial and relational; arranged by relevance, activity, distance, and current intention; a place for navigation, presence, proximity, exploration, capture, and action; alive with restrained evidence of ongoing relationships and work.

The Field is not: a complete graph of everything in Kiduna, a dashboard, a feed, a menu of applications, an admin console, a file browser, a surveillance view, or a permanent or identical view for every Source.

At the outermost distance, the Field contains only Realms. Entering a Realm reveals the Elements that belong within that context.

**The Field is alive by default.** Ki rearranges the Field continuously without explicit instruction — unless the Source instructs Ki not to. Most changes to the Field come from the activities of other Sources, Allies, and Actors, not from the acting Source: this is a fully immersive, interactive space, not a place where a separate Source occasionally publishes. Spatial position persists only where the Source actively **anchors** it; anything else may drift, and the Source can always ask Ki to restore something or bring it into focus.

### 2.3 Ki

Ki is the orchestration layer through which the Field becomes intelligible and actionable. Ki may: interpret current context; retrieve permitted knowledge; explain why something appeared; prepare reversible work; compare versions; coordinate Allies and Actors; surface relevant changes; propose Actions; inspect authority and consequence; carry out permitted Actions; withhold Actions when authority is insufficient; and help the Source recover, revoke, or reconsider.

Ki is not an Element inside the Field and does not become a character, avatar, or Realm object. Ki must remain contextual, legible, steerable, permission-bound, honest about uncertainty, honest about fixture versus live data, and subordinate to human or constituted collective authority.

**Ki never refers to itself in the first person.** Ki always speaks in the third person, referring to itself as Ki, never "I."

**Ki is proactive by default.** Ki represents and presents what is happening throughout the Field. Which signals Ki surfaces, and when Ki interrupts, slows, or withholds, is decided primarily **in dialogue between Ki and the Source** — a standing preference conversation, not a settings tree. The open design problem is focus: how a Source chooses to concentrate on one Element undistracted for a period, and when and how Ki may interrupt. "Why am I seeing this?" must always be answerable, and the required explanation depth is small.

### 2.4 Realms

Realms are bounded contexts in which relationships, knowledge, work, Resources, governance, and Actions take form. The canonical Realm types are: **Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell.**

Realm identity is communicated by structure first and semantic color second. A parent Realm does not recolor or erase the identity of its children. Realms may overlap and exchange permitted knowledge without becoming one undifferentiated data pool.

### 2.5 Elements

The Field contains six first-class Element categories: **Realms · Actors · Media · Allies · Resources · Actions.**

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. Scenes are Media, not a separate first-class Element.

### 2.6 Allies and Actors

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.

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

An **Actor** is an intelligent agentic presence working within a defined purpose, context, permission set, and authority boundary. Intelligence may expand capacity. It does not independently acquire authority.

### 2.7 Actions

A consequential Action moves through a legible lifecycle:

1. **Intention** — the Source expresses a desired outcome.
2. **Draft** — Ki, an Ally, or an Actor prepares reversible material.
3. **Prepared Action** — the proposed consequence is sufficiently defined for inspection.
4. **Inspection** — scope, changes, authority, affected parties, cost, provenance, and recovery are visible.
5. **Confirmation** — the authorized Source or collective deliberately approves the exact Action.
6. **Execution** — the Action is carried out within the confirmed scope.
7. **Completion or settlement** — the result, cost, and state become part of the relevant Record.
8. **Recovery, reversal, or revocation** — where possible, authority or consequence can be withdrawn, repaired, appealed, or reversed.

The interface must never allow a draft to appear committed or make a prepared Action look completed.

**Most Actions are single-Source.** Multi-Source confirmation applies only to Actions with Alliances (Squads multi-sig wallet), with Organizations (Forums and multi-sig wallets), and wherever a Community, Project, Program, or Relationship has specifically set an Action to multi-Source confirmation.

### 2.8 Resources and Compute

Resources provide material capacity for collective activity. **$KIDUNA is prepaid Compute usage credit.** It is not an investment product, a speculative asset promise, a score, a proxy for personal worth, or a leaderboard metric.

Money and Compute are shown as facts. Interfaces must distinguish: available · reserved · pending · settled · recurring · reversed · failed · fixture data · live data.

**Three Resource facts stay visible on every Studio state, and the same three on Live:** available Resource (units of $KIDUNA), the value of the Resource in the wallet (USD), and the current price of a single $KIDUNA in USD.

## 3. The role of Studio

Studio is Kiduna's **desktop working distance**. Its primary purpose is to help a Source understand complex context, compose work, inspect exact changes, govern shared activity, and commit consequential Actions.

Studio is appropriate for: navigating broad and nested Field contexts; understanding relationships among Realms; inspecting Records, versions, provenance, and authoritative differences; preparing and reviewing complex Actions; working with Allies and Actors; creating and configuring Realms; reviewing permissions and delegations; governance activity; grants and package acceptance; Resource allocation; recurring commitments; publication review; complex external Actions; recovery and revocation; and work requiring sustained attention.

Studio supports **structured density** — significant detail when clearly organized and contextually disclosed. It should feel like a living working environment, not an administrative system.

**Interaction posture.** Pointer, trackpad, keyboard; continuous pan and zoom; progressive spatial disclosure; exact selection; anchored Panels; detailed inspection; version comparison; multi-step confirmation. The Source-adjustable relationship between the Field and Ki defaults to approximately **70/30**, with contextual variation between roughly 66/34 and 75/25. Ki remains on the right at all supported Studio widths.

## 4. The role of Live

Live is Kiduna's **mobile human distance**. Its primary purpose is to help a Source remain present, capture what is happening, coordinate relationships, make bounded decisions, prepare work offline, and carry complex work safely into Studio.

Live is appropriate for: immediate orientation; current-Realm context; presence; relationship awareness; voice, text, photo, and Media capture; short contextual conversations with Ki; simple check-ins; lightweight coordination; bounded approvals; offline preparation; reconnection and recovery; monitoring previously confirmed work; and deferring complex inspection to Studio.

**Live can confirm most consequential Actions.** Many Sources will never use Studio, and the product must be whole for them. The design question is inverted from the usual mobile framing: the list of Actions that can *only* be performed in Studio must be very small — possibly empty — and anything on it must earn its place (the working criterion: a decision that cannot be adequately inspected on a small screen). What Live avoids is not consequence but density: full Studio workflows, dense multi-object comparison, complex grants and package acceptance, detailed governance, multi-stage authority configuration, complex Resource allocation, and ambiguous external commitments.

Live makes the immediate context clear without becoming a notification feed or engagement surface.

**Interaction posture.** Touch, voice, mobile keyboard, camera and Media capture; one-handed use; short and interrupted sessions; poor or absent connectivity; explicit continuation in Studio. The Field remains present; Ki is expressed as a collapsible bottom sheet or equivalent touch-native layer. Primary orientation is portrait, with an optional horizontal mode for consuming Media and navigating the Field — particularly strong in voice mode. **Tablet is a later bridge surface, not part of the Live release scope.**

## 5. The relationship between Studio and Live

Studio and Live share: the same Field, the same Ki, the same Realm structure, the same identities, the same Actions, the same authority model, the same privacy boundaries, the same provenance, the same Resource facts, and the same state of work. They do not need to display the same amount of information or offer the same authority.

A cross-surface handoff preserves: current Realm; Realm ancestry; selected Element; draft or prepared Action; evidence already inspected; provenance; privacy classification; authority requirements; offline state; Compute or monetary consequence; and the exact next step. "Continue in Studio" opens the relevant context, never a generic landing state. Starting an Action on Live grants no additional authority when the Action reaches Studio.

## 6. Persona commitments

Every important workflow is evaluated against all four patterns.

**Alice inspects before acting.** Prioritize: exact changes, explicit authority, version comparison, recurrence, pending versus settled state, reversible preparation, calm structured density. Primary failure risk: stale or unclear authority.

**Bob talks before summarizing.** Prioritize: people and relationships, invitations, role agreements, clear distributions, care without surveillance, separate respectful outreach, aggregate participation rather than private activity. Primary failure risk: leaving someone behind, or turning care into monitoring.

**Carol explores before confirming an exact version.** Prioritize: voice, generative conversation, versioned Media, provenance, attribution, recognition, a clear transition from play or proposal to public commitment. Primary failure risk: lost attribution or accidental publication.

**Danny prepares, verifies, and then commits.** Prioritize: offline operation, low-noise presentation, explicit classification, sharing boundaries, recovery, Compute ceilings, reserved versus consumed cost, portable work. Primary failure risks: oversharing, failed recovery, unclear offline state.

## 7. Non-negotiable design principles

### 7.1 Human authority is inspectable

The system can always show: who is acting; whom they represent; what authority they hold; what permission is being exercised; what still requires confirmation; and what Ki or an Actor cannot do. Intelligence may recommend or prepare; it cannot silently convert capacity into authority.

Authority does not have to remain visible at all times. This is not an auditing system — it should feel natural, and in many places we want fun and suspension of disbelief. The interface stays uncluttered; what is guaranteed is that a Source can always **discover and inspect** the authority behind anything.

### 7.2 Privacy is architectural

Information remains bound to its context. Public information may circulate openly. Private information moves by permission. Secret information cannot be discovered unless deliberately revealed. Personal information remains with the individual for whom it is held. Participation in one Realm does not silently expose activity in another.

Privacy must not get in the way of usability. Private information is typically private **to a Realm** — inside that Realm, it is simply present. In a secret Realm, the secret information is present. Personal information is always present to you. Permissions are inspectable, but they are not obvious on the surface.

### 7.3 Influence is inspectable

A Source can determine: why something appeared; what information informed it; which Actor proposed it; whose purpose is being served; and what will happen if they agree. The Source can question, pause, revoke, appeal, recover, leave, or turn off an intervention wherever the product model permits it.

### 7.4 Care must not become control

Never: manufactured urgency, infinite feeds, engagement pressure, retention mechanics, follower counts, scores, rankings, grades, leaderboards, behavioral targeting, hidden personalization, inferred vulnerability, or inferred emotional state.

### 7.5 One clear next move

A state may contain substantial context, but it presents one visually dominant next Action. Suggested prompts remain quiet and conversational; they never compete with the primary Action.

### 7.6 Consequence before confirmation

Before confirmation, show: the exact Action; the affected Realm; affected people or systems; material changes; non-changes when relevant; authority; required confirmations; Compute or money effect; external versus simulated execution; reversibility and recovery.

### 7.7 Truth over spectacle

Never invent: presence, activity, authority, balances, private context, emotional state, live data, or completed execution. Fixtures and simulations are labeled honestly.

### 7.8 Accessibility is part of agency

All meaningful interactions support: visible keyboard focus; screen-reader names; non-color status communication; reduced motion; large text; sufficient contrast; pointer, keyboard, trackpad, and touch equivalents where relevant; and focus restoration after dismissal or navigation.

## 8. Known visual-system constraints

### 8.1 Aesthetic

**Deep. Warm. Magical. Alive.** The interface is dark-native, materially warm, spatially deep, and quietly luminous. It must not feel cold, sterile, corporate, neon, glossy, gamified, futuristic for its own sake, or visually muddy.

### 8.2 Color

Studio Field ground: near-black deep umber, canonically `#0A0604`. General deep-umber brand ground: `#1C140D`. Cream white carries primary readable hierarchy; pure white is never used. Sky blue signals action, navigation, continuity, and consequence. Sun gold signals Resources and significant institutional material. Camel provides warm structure; moon cream provides highlight and symbolic light; mint is rarer and relational. Realm hues retain their semantic identity.

Broad blue-green, brown, or decorative gradient washes never cover the Field — color remains localized around meaningful objects and relationships. But **don't be stingy with color**: the Field should feel alive and magical, with hints of color frequently drawing attention toward a significant item on a periphery or something brought into focus.

The primary brand colors: Sky Blue `#03CCD9` · Sun Gold `#EAAA00` · Moon Cream `#FFF6D5` · Camel `#C19A6B` · Chocolate `#6F4A2E` · Dark Umber `#4E3629` · Espresso `#1C140D` · Aubergine `#2A1A2B` · Mint `#8FE6C6` · Cream White `#FFFFE6` · Cream `#F9DDB7` · Gold (warning) `#FFCA05` · Black `#1E1F20` · Grey `#9094A3`.

The extended ranges — **Violets:** Violet Deep `#3F2270`, Violet `#6536BB`, Violet Bright `#9D7BE8`, Lilac `#D6C7F2`. **Greens:** Forest `#1F4D38`, Green `#2F8C63`, Jade `#57C08F`, Sage `#BCD3A6`. **Oranges:** Ember `#A94E1C`, Orange `#D97B2E`, Apricot `#F0A85C`, Peach `#F8D6AA`. **Blues:** Midnight `#14203E`, Indigo `#33478F`, Blue `#2FB4E0`, Powder `#ABDCE8`.

The full token set, preview cards, and worked examples are the design system in `_ds/` ([README](_ds/kidunaverse-2de4dee0-9628-4871-a4e3-fc4ddc902d31/README.md)), also packaged in [downloads](downloads/Kiduna-Design-System-2026-07-26.zip).

### 8.3 Typography

Goudy Heavyface for display; Avenir for interface and body; IBM Plex Sans for callouts. Numbers use Goudy Heavyface. Display emphasis may use one sun-gold phrase per headline — never italicize headlines or parts of headlines. Dense interfaces use restrained hierarchy rather than excessive type variation.

### 8.4 Realm identity

Realm identity uses: circular celestial-enamel chassis; warm-metal double rim; dark core; canonical type crest; semantic enamel hue; localized halo; anchors and orbit structure; progressive simplification at small sizes. Canonical crests are never replaced by emoji, Lucide icons, generic outline symbols, or font icons. Where older visual grammar conflicts with the newer Studio Enamel canon, the enamel canon controls visual expression while established interaction semantics remain intact.

### 8.5 Field behavior

Field pan responds directly; wheel and pinch zoom around the gesture center; fixed chrome does not scale with the Field; labels move with their objects; disclosure changes progressively; selection and threshold remain distinct states; Field arrangement remains stable enough to preserve orientation; motion remains local and meaningful.

### 8.6 Motion

Studio motion verbs: **breathe · relate · gather · drift · approach · threshold · settle.** Motion communicates context, activity, or change; it does not decorate the whole interface. Reduced-motion mode preserves all information without movement.

### 8.7 Connections

Studio may use: orbit, tether, braid, confluence, anchor, crossing, threshold, constellation, echo. Live uses a simplified vocabulary: straight camel line for resting relationship; mint dotted line for presence; sky line for consequence in motion; gold line or bead for Compute movement. Connections express a real relationship, never atmospheric decoration.

### 8.8 Studio layout

Field on the left; Ki on the right; approximately 70/30 default relationship; fixed orientation and Compute; selected Realm Panel anchored near the Realm; at least part of the selected object remains visible; only Realms appear at the outermost Field distance.

### 8.9 Live layout

The Field remains present; Ki uses a bottom sheet or touch-native layered expression; labels sit below spatial nodes; controls use at least 44px targets; filled glyphs remain legible at small sizes; Media stays within enamel tiles; complex Studio interactions are not compressed into mobile layouts. Portrait primary, with the optional horizontal mode for Media and Field navigation.

## 9. Rulings in force and what stays open

The questions this brief opened have been worked; the rulings below are in force. What remains genuinely open is queued, with context, on [Open Questions](open-questions.html).

**Product scope.** Live can confirm most consequential Actions — the Studio-only list must be very small, possibly empty, and each entry must earn its place. Tablet is a later bridge surface. Still open: the required Studio and Live journeys for first release, and whatever tiny Studio-only Action list survives scrutiny.

**Field and navigation.** Ki rearranges the Field by default; the Source can instruct otherwise; most Field change comes from other Sources, Allies, and Actors. Spatial persistence requires active anchoring; Ki restores on request. Still open: the default Field context on return; distinguishing current relevance from lasting structural importance; how Live preserves the Field's spatial character without desktop-style navigation.

**Ki.** Proactive by default; surfacing and interruption thresholds are set in dialogue between Ki and the Source; "why am I seeing this?" needs very little depth; disagreement presentation extends to Actors *and* Allies. Still open: the focus-protection design — how a Source concentrates on one Element and when Ki may interrupt.

**Authority and confirmation.** Most Actions are single-Source; multi-Source only for Alliances, Organizations, and Realms that set it explicitly (§2.7). Still open: the product vocabulary distinguishing prepared, confirmed, executing, and settled; representation of expiring, delegated, partial, or contested authority; practical reversibility windows; the escalation path when automatic recovery fails.

**Privacy.** Realm-scoped presence of private and secret information; personal information always present to its person; permissions inspectable, not surface-obvious (§7.2). Still open: member-selectable classifications; Realm-inherited classifications; conflict resolution; audit information without exposing protected context; communicating that an absence is a boundary, not a loading failure.

**Offline.** Open: which Media and Records may be stored locally; which classifications prohibit offline storage; which Actions may be prepared offline; sync-conflict resolution that never silently overwrites authority or provenance; security and recovery for a lost device.

**Resources.** The three always-visible facts (units of $KIDUNA · wallet value in USD · current $KIDUNA price in USD) apply to Studio and Live alike (§2.8). Still open: confirmations before Compute or money moves; the source of truth for live/delayed/estimated/fixture status; surfacing recurring commitments without financial anxiety or artificial urgency.

**Platform and accessibility.** Studio and Live are both native Flutter/Flame; each "web version" is the same Flutter/Flame application served for remote or limited use. Still open: minimum supported desktop width; required mobile operating systems and accessibility APIs; whether WCAG 2.2 AA is the formal baseline and whether anything exceeds it.

**Validation.** All taxonomy and interaction ratification goes through the product owner, working directly with the design collaborators. Still open: which real participant groups validate the four persona patterns; which governance, privacy, legal, and accessibility experts review consequential Actions; what evidence promotes a pattern to canonical.

## 10. The decision log

Every material decision receives a stable identifier (`KDN-nnn`) and a record with these fields: Decision ID · Date · Title · Status · Category (product, taxonomy, interaction, visual, privacy, authority, accessibility, engineering) · Context · Source material · Options considered · Decision · Rationale · Affected surfaces · Affected personas · Privacy impact · Authority impact · Accessibility impact · Taxonomy impact · Reversibility · Validation evidence · Owner · Revisit trigger.

The lifecycle: **Proposed** (a direction exists but is not approved) → **Accepted** (approved for design exploration) → **Validating** (represented in a prototype or research study) → **Validated** (supported by sufficient evidence for implementation), with **Rejected** (considered and deliberately not chosen) and **Superseded** (replaced while preserving the historical rationale).

The initial decisions:

| ID | Decision | Status |
|---|---|---|
| KDN-001 | Studio is the desktop surface for complex understanding, composition, inspection, governance, and commitment. | Accepted |
| KDN-002 | Live is the mobile surface for presence, capture, coordination, simple approvals, offline preparation, and deferral to Studio. | Accepted |
| KDN-003 | The Field and Ki remain continuous across both surfaces. | Accepted |
| KDN-004 | Live will not reproduce the full Studio interaction model. | Accepted |
| KDN-005 | Studio will not adopt a dashboard, admin-console, file-tree, or feed model. | Accepted |
| KDN-006 | Consequential Actions require inspectable scope, authority, consequence, cost, and reversibility. | Accepted |
| KDN-007 | Alice, Bob, Carol, and Danny are mandatory behavioral review fixtures. | Accepted |
| KDN-008 | Established taxonomy remains canonical unless a change is explicitly proposed and ratified. | Accepted |
| KDN-009 | Newer Studio Enamel visual canon takes priority where older visual references conflict. | Accepted |
| KDN-010 | Engagement, scoring, ranking, inferred emotion, false presence, and surveillance patterns are prohibited. | Accepted |

## 11. The working design test

Every Studio and Live concept is evaluated with one question:

> Does this surface make the Source more capable of sensing, deciding, acting, and learning while preserving authorship, privacy, relationships, and the freedom to refuse, revoke, recover, or leave?

If the answer is unclear, the design is not ready to advance.

---

*Changes: v0.1 installed 2026-07-26 as the working foundation for all Studio and Live design; its rulings folded here and into [Taxonomy v1.3.7](taxonomy.html), [Open Questions](open-questions.html), and the [Design Method](design-method.html). Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: create-from-within.md ===== -->

# Create from Within

**The method · canonical · v5.2**

**"Creating from Within" means building the minimum necessary to start creating *with* the system — and then creating everything else from inside it.** This is not an MVP, and it is not part of the lean/agile paradigm. It is a software development concept that only became possible with intelligent, probabilistic software agents: the old models were deterministic systems building deterministic systems, so everything had to be specified, built, and shipped before anyone could live in it. An agentic system is different — the moment the smallest true core runs, the system itself becomes the workshop, and every subsequent capability is created from within, by the people and allies already inside.

This page is how we build Kiduna, and how you can join the building — as a **Builder** (code, agents, integrations) or a **Creator** (context, experiences, Moves, wisdom). The whole specification on this site is open to you; the [Kiduna Kit](index.html) is the same material packaged to work with your own tools; and on **August 10** the stack ships open source (Apache 2.0), so an ecosystem of your own is an install away.

---

## 1. The minimum, precisely

The smallest thing that can create is not a feature list — it is a loop: **a member, their ally, and the ability to bring one more person in well.** Everything else in Kiduna can be made from inside that loop. So the first running system is exactly: the Genesis Ally (**Ki**) able to onboard a person, help them understand the system, create their own ally, and invite the next person; Chat and Live as the two modes it renders in; and the [Profiler](#3-the-first-program-the-profiler) — the first Program — so that every invitation is prepared, not broadcast.

## 2. The first act: Moto invites swyx

The method's first target, worked concretely. Moto sets up his ally, then invites **Shawn "swyx" Wang** — the writer who named the AI-engineer era (["The Rise of the AI Engineer,"](https://www.latent.space/p/ai-engineer) Latent Space, June 2023: a wide range of AI tasks that used to take five years and a research team now take API docs and a spare afternoon). One person, invited well, into a system that already knows who he is.

**Every code is unique to a person.** You are inviting a *particular* human, never posting a link for anyone — and the sense of the whole flow is that **the member prepares the system for the person they're inviting.**

## 3. The first Program: the Profiler

Before the invitation goes out, Moto's ally triggers the **Profiler** — the Program that builds the system's understanding of the invitee from a few things the member shares. What the member provides (the working input list, refined by use):

- **Who:** full name, and the handles that matter — LinkedIn, X/Twitter, Bluesky, GitHub, personal site.
- **The work:** one or two things that define them (for swyx: the AI Engineer essay; Latent Space), so the system reads the right material, not everything.
- **The relationship:** how you know them, in a sentence — the Profiler weights context by source like everything else does.
- **The why:** what you hope to build or explore together — this becomes the invitation's substance and the ally's first conversation topics.
- **The where:** which container they land in (the launch cohort lands in Kiduna Club) and what you propose to share with them — the starting grants of your [relationship](foundation.html), stated up front.

The Profiler assembles a profile from public material, holds it at the appropriate level, and prepares Ki and the member's ally for the arrival — so when swyx enters through his unique code, the system already knows him: his ally introduces itself already fluent in his work, the first conversation starts in the middle, and the invitation reads like it was written by someone who knows him, because it was.

## 4. Why this works now (and didn't before)

A deterministic system can't do any of this — it can only present the forms it shipped with. An intelligent system can *meet* someone: read a corpus, hold a profile at a stated privacy level, brief a persona, adapt a first conversation. That is the general pattern of Creating from Within: **wherever the old model would have built a feature, the new model prepares an agent.** The Profiler instead of a signup funnel. Ki instead of an onboarding wizard. [Moves](surfaces.html) built in Studio instead of content pipelines. The system is small; the agents make it complete.

## 5. What this replaces

No MVP thinking (an MVP is the smallest thing you can *sell*; this is the smallest thing that can *create*). No backlog-driven buildout (capabilities appear when someone inside needs them and makes them). No launch-as-unveiling (August 10 ships the loop and the kit, not a finished world — the world is what gets created from within, in public, under Apache 2.0).

---

*The method is designed: [Design Round 6](surfaces.html) renders this page — the first invitation end to end, Live's first full round, the mode products, the /handle pages, and [the August 10 cut](design-r6/05%20Create-from-Within%20Cut%20R6.dc.html).*

*Changes in v5.2: page created — the method named and adopted; the swyx invitation set as the first target; the Profiler specified as the first Program. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: surfaces.md ===== -->

# The Surfaces

**Track 1 of 11 · the surfaces, their official homes, and what using them is like · v5.9**

> **Read this track through [Taxonomy v1.3.8](taxonomy.html).** A **Surface is a form factor** — **Desktop web** (the Field with Ki beside it), **Mobile**, the **Chrome Sidebar** (the browser extension), and **CTV** (the shared big screen, driven by the mobile devices in the room, several people at once). What a member does anywhere is one of the **eight Scenes** — **Atlas** (discover) · **Studio** (create) · **Commons** (organize) · **Workbench** (build) · **Forum** (govern) · **Exchange** (trade) · **Garden** (enjoy) · **Vault** (store, web-only). Every Scene reaches every Surface except Vault. **A basic version of all four Surfaces — CTV included — ships in the initial release (ruled 2026-08-01).** The official homes below remain the entry points, the modes remain **Chat and Live**, and everything this track says about what using each home is like still holds; the product descriptions below are read as renderings of the Scenes on the Surfaces. The full functional consequences are in the [Initial Release Functional Specification](initial-release-functional-spec.html).

Kiduna has **two modes — Chat and Live** — and reaches people through **six surfaces**, each with an official home: **Kiduna** (the mobile app and first KAP client — kiduna.app, the App Store, Google Play), **Kiduna Studio** (the build/create environment — desktop, and kiduna.studio on the web), **Kiduna Express** (the browser extension — kiduna.express, the Chrome Web Store), **Kiduna** (the account — kidunaverse.com), **Kiduna Live** (the Live mode alone — kiduna.live), and **Kiduna One** (Chat alone — kiduna.one). All Flutter/Flame wherever they render; all renderings of one system: the same graph, the same permissions, the same ally. **The design bible is here: [Kiduna Surfaces Design Bible v0.1](surfaces-bible/Kiduna_Surfaces_Design_Bible_v0.1.html)** — the visual and interaction canon for every surface (the Field grammar, the system, Studio, Live, Express, TV, and the design directions), also as a [downloadable bundle (zip: html · pdf · docx · md · assets)](downloads/Kiduna-Surfaces-Design-Bible-v0.1-bundle.zip). **The product foundation for the two working distances is the [Studio + Live Working Design Brief](studio-live-brief.html)**: Studio is the desktop working distance (structured density, inspection, governance, commitment; the Field left, Ki right, ~70/30); Live is the mobile human distance (presence, capture, coordination, bounded decisions; Ki as a bottom sheet) — and **Live can confirm most consequential Actions**: many Sources will never use Studio, so the list of Studio-only Actions must be very small, possibly empty. The actions available everywhere are inventoried in [Actions](actions.html); the machinery is [Orchestration](orchestration.html); outside tools and building on us is [Integrations](integrations.html); how we build — and how you can — is [Create from Within](create-from-within.html).

---

## 1. The one relationship

A member does not operate Kiduna; a member **talks to their ally** — the agent that represents them, named by them, working for them across every organization they belong to, on every surface. Everything the system can do is reachable by saying so, typed or spoken. There are no menus and no navigation in the traditional sense, because when agents do the work, an interface made of places-to-go answers a question nobody asked. The member's job is the relationship: teach the ally, correct it, read its account of what happened, and personally sign the few things only a human can sign.

## 2. Kiduna — the mobile app, the first KAP client · kiduna.app · App Store · Google Play

**The member's daily surface and the first client of the [Kinship Agency Protocol](protocol.html)**, built in Flutter/Flame for iOS and Android, with the identical app on the web at **kiduna.app**. Kiduna is for participating in organizations, and it is **always switchable between its two modes: Chat and Live.**

**Chat** is the text and realtime-voice conversation with your ally — the primary flow of the whole product. Voice and text are one conversation: the composer becomes a quiet voice band, in-flight words render peripherally, completed utterances land as ordinary messages, and you can interrupt or switch modes mid-thought. The ally always offers contextual actions — chips (one-tap sayables), buttons (a chip with its consequence stated), and cards (objects with a front stating consequence and a back showing the context used) — and everything a chip does, saying it does too. Fuller UIs (a treasury view, a Forum proposal, a grant panel) slide over the conversation, do their one job, and return you to the exact sentence you left. Awareness arrives rather than being fetched: return after any interval and the ally tells you what happened, most consequential first, every claim cited, compressed to fit the gap. **Sovereign acts are unmistakable**: votes, extending a code, blessing a spin-out arrive as cards and are signed by press-and-hold; **the gold ceremony — stamp, embers, haptic — marks signed acts and nothing else, forever**; what happens *to* you is announced by light.

**Live** is the isometric, graphic rendering of the same system — the second mode on the same system, not a separate world. You still only converse with your ally; in Live you are also **steering**: navigating the space, and *seeing* what Chat narrates — allies interacting with allies, allies interacting with **actors** (NPCs with purposes and routines), organizations as places, work as visible activity, with specific goals and contextual actions surfacing as you move. Design substrate: **tile specs for backgrounds, events, and sprites**, honed over time the way Kidunaversity's has been (what began as a city hall is now a university). Where finished art doesn't exist yet, **the models and the orchestration generate the space**: a bounded room, who is present, how far away they are — spatial rendering as a live capability, not a content backlog. The middle path is generative art tooling (ImageGen, Gemini) for tiles, sprites, particle effects, HUD and menus, scoring, and wallet-moving actions. **Moves** — the authored Live experiences: scenes, vibes, and games, built in [Studio](#5-kiduna-studio--the-buildcreate-environment--desktop--kidunastudio) — run inside Live; [Kidunaversity](organizations.html) is the first, and sim-flagged Moves obey the absolute boundary: **nothing inside a sim-flagged Move affects Kiduna.** You enter through portals your ally offers; entering is a plain tap; press-and-hold stays reserved for real signatures.

**Kiduna Live · kiduna.live** and **Kiduna One · kiduna.one** are the two modes offered whole: when you don't want Chat at all, kiduna.live is the Live environment on its own; when you just want to chat, kiduna.one is Chat as just chat. Same app, same graph, same ally — the surface simply opens in one mode and stays there, and the full app remains one switch away.

## 3. Kiduna Express — the browser · kiduna.express · Chrome Web Store

**The agentic internet made visible.** Express is the Chrome extension that navigates the web with you and for you: it uses the browser, reads what you read, and **filters everything through Kinship Codes** — is this site, page, email, or account **registered** ([Protocol §4](protocol.html))? What does the registration trace to — which member, which organization, which legal entity? Registered things light up with what they are; unregistered things stay what they've always been — *a stranger, not a threat.* On that foundation the web becomes safe, automated, and alive: your ally acts across it, agent to agent, under your authority.

**Registered social accounts** extend this to people-space: log in to a social account through [Studio](#5-kiduna-studio--the-building-surface--desktop) once, and the account is bound to your registry identity. Your ally can post for you — and, more importantly, other members' allies can interact with your accounts and use your public posts as context, so relationships build across Bluesky, the open web, and messaging channels, not just inside the app.

## 4. The account · kidunaverse.com

**Not an application — the account.** kidunaverse.com is where identity, credentials, wallets, and money live: onboarding and registration, your settings and permissions, buying and selling Compute, Institution accounts (including institutions paying for their enrolled members' Compute), links to every product, and where things get published. It is **the account every app and world needs — including third-party apps** built on the [Integrations](integrations.html) surface. Public metrics of the decentralized Kiduna (ecosystems · organizations · members · allies · alliances · Compute) live here too — and so do the **directories**: **kidunaverse.com/handle** is the page for a member or an ally (handles are unique across both, and "handle" is the word — never "username").

**The protocol browser.** Kiduna's most load-bearing page: the **audit trail, navigable**. Every relationship, transfer, account, and registration is an economic relationship on the protocol, and here you can walk them — drill from an organization to its proposals to a command receipt to the settlement; from a member to their registered artifacts; from your own history outward. What you can browse is exactly what you can access: your own everything (relationships, artifacts, summaries, archives), the materials of organizations and alliances you belong to, and whatever anyone made public — the four levels, enforced in the browser like everywhere else. From here you can also hand requests to Kiduna, Express, or Studio.

**Joining and money.** All payment execution stays on the web ([the invariant](protocol.html)). At the $100 step (Kinship Duna's initial Compute purchase), three options: **(1) Stripe headless onramp** (card → USDC, no crypto knowledge required), **(2) connect a Solana wallet** and transfer 100 USDC, **(3) send 100 USDC** to your new wallet's address (copy it, use any exchange). The designed flow — invitation through onboarding, all three paths, pending/complete, and the return to Chat — is the [Cohort Journey canvas](design-r5/Cohort%20Journey%20R5.dc.html).

## 5. Kiduna Studio — the build/create environment · desktop + kiduna.studio

**Studio is where you build and create — and above all, where relationships are designed.** It runs like an agentic desktop app — one conversation with your ally over a live workspace, in the manner of Claude Cowork or Codex — not a segmented, procedural tool: whatever you drop in gets organized into the graph, and a range of actions surfaces in the chat. It ships for mac, Windows, and Linux/Chromebook, and the same Flutter/Flame build runs on the web at **kiduna.studio**. It is not a vibe-coding platform and not for coding at all; it is for **creating and maintaining your ally, inviting people, developing Moves, and building organizations**: adding context and knowledge, creating alliances, fleshing out system prompts, connecting accounts, composing skills and automations.

**The Studio↔coding-agent protocol.** For work that *is* code, Studio doesn't pretend — it passes **packages** back and forth with **Claude Code and Codex** on the local machine, over a defined protocol modeled on the dispatch pattern we run ourselves: Studio hands out a self-describing package (context, ask, constraints), the coding agent works it in its own environment, and the result comes back as a package Studio unpacks into the graph, recorded like any other work ([Integrations §1](integrations.html)).

**Designing relationships is the point.** Between two people the first-class object is a **relationship** (canon — never "connection"): both sides inform it — what each shares and exposes, what each learns and maintains about the other — and Studio is where you shape that texture deliberately. The same holds one level up: guilds, alliances, and organizations are containers whose context you design here. You are always talking to your ally, but the experience inside each container is distinct — different grounding, different shared wisdom, different rules — stored distinctly, all related on the graph ([Foundation](foundation.html)).

**Deep collaboration, not light sharing.** Studio is built for working *with* people: sharing skills and modifying them together, connecting knowledge bases, co-writing system prompts and automations — one person doing sound while another does art while a third wires the Forum conventions. **The most important thing about Studio is communications between allies**: over social media (Bluesky), over messaging (Telegram), and through direct **back-channel ally-to-ally conversations** — with the relationship, guild, alliance, or organization providing the context every exchange runs in.

**The tool room.** Studio is where outside capability gets attached: MCP servers connected and scoped to specific relationships, alliances, or organizations; local agents — Claude Cowork/Code and OpenAI Codex on your own machine — that Studio hands work to and receives results from; social accounts logged in and registered. The full integration surface, inward and outward, is [Integrations](integrations.html).

## 6. What never varies

Across all four products: citations and consequence-ordering; the meaning of **gold** (signature) and **sky** (touchable); the anatomy of a card; the four access levels; your Contract — no organization can buy louder access to you; the ally's voice, constant everywhere. Moving between organizations is a **drift** — ground temperature, Compute in play, register — never a navigation event. Each duna configures its own register; the system never changes underneath ([Organizations §3](organizations.html)).

## 7. Roles shape the experience

What you can do on any surface is gated by your [role](roles.html) in the organization you're acting in — Guests are guided by the shared Host ally; Members have the full baseline; Organizers, Creators, Builders, and Catalysts unlock their verbs ([Actions](actions.html) marks every gate). Promotion is announced by light, then quiet. Never a leaderboard.

## 8. The complete UI design

The full visual design record — start with the UX spec, then the canvases:

- **Design Round 7 — Kiduna Studio, whole** *(current round)*: **[UX Specification R7](design-r7/UX-SPEC-R7.md)** · [01 The Project](design-r7/01%20The%20Project%20R7.dc.html) (the primitive: creation with its receipt, the anatomy card, its own Scene) · [02 Field and Chat](design-r7/02%20Field%20and%20Chat%20R7.dc.html) *(drawn against the morning canon — read its chat panes as the contextual HUD's opaque state per the evening rule: the Field is the only interface)* · [03 Collaboration](design-r7/03%20Collaboration%20R7.dc.html) (presence, server-mediated handoffs, the trust matrix) · [04 The Coding-Agent Seam](design-r7/04%20The%20Coding-Agent%20Seam%20R7.dc.html) (package out, in-flight, return, acceptance) · [05 Ally and Scenes](design-r7/05%20Ally%20and%20Scenes%20R7.dc.html) · [06 The Cut](design-r7/06%20The%20Cut%20R7.dc.html) (the Lightbrush Project end to end) · [07 Studio on the Phone](design-r7/07%20Studio%20on%20the%20Phone%20R7.dc.html) (the pulse, not the workshop) · [motion](design-r7/MOTION-ADDENDUM-R7.md) · **[six open questions awaiting decision](design-r7/OPEN-QUESTIONS-R7.md)**.
- **Design Round 6 — Creating from Within** *(canvas 05 remains normative for the August 10 member journey)*: **[UX Specification R6](design-r6/UX-SPEC-R6.md)** · [01 The First Invitation](design-r6/01%20First%20Invitation%20R6.dc.html) (Ki's first session and ally creation as conversation · the Profiler intake and profile card · the one-signature invitation · swyx entering fluent · the first Chat ⇄ Live switch · Studio at three jobs + the package handoff) · [02 Live](design-r6/02%20Live%20R6.dc.html) (the HUD and sky-rim law, proximity actions, sim-flagged Moves without meters, the closed tile/sprite/event vocabulary, the generative fallback) · [03 One & Live as products](design-r6/03%20One%20and%20Live%20Products%20R6.dc.html) · [04 the /handle directory](design-r6/04%20Kidunaverse%20Directory%20R6.dc.html) · [05 the Create-from-Within Cut](design-r6/05%20Create-from-Within%20Cut%20R6.dc.html) · [motion](design-r6/MOTION-ADDENDUM-R6.md) · **[ten open questions awaiting decision](design-r6/OPEN-QUESTIONS-R6.md)**. Where R5's fuller designs and R6's cut differ, **the cut is the August 10 build; R5 is the horizon.**
- **[The Cohort Journey — R5](design-r5/Cohort%20Journey%20R5.dc.html)** — the onboarding baseline, adopted by R6: Crystal Stone's whole arc (the invitation before she has an account · onboarding at kidunaverse.com, one act per page · the $100 step with all three paths, pending/complete, and the return · first Chat, with the relationship designed conversationally and the two-sided relationship card) plus one-panel vignettes of the rest of the launch cohort.
- **[UX Specification](design-r4/UX-SPEC-R4.md)** — the composed model through R4: Chat anatomy, the four voice states, the card→fuller-UI→return loop, treasury/Forum/grants/record, Kidunaversity entry and exit, the money handoff.
- **Screen canvases** (mobile 390×844 unless noted):
  [Core screens — Chat, voice, treasury, Forum, grants, record, portals, money handoff](design-r3/Key%20Screens%20R3.dc.html) ·
  [Voice + crossing, final form](design-r4/Redraws%20R4.dc.html) ·
  [The web money surface (desktop + mobile web)](design-r4/Web%20Money%20Surface%20R4.dc.html) ·
  [Kidunaversity](design-r4/Kidunaversity%20R4.dc.html) ·
  [Levels, guilds, institutions, domain registration](design-r4/Levels%20%26%20Social%20Objects%20R4.dc.html) — *predates the "registered / unregistered" vocabulary; read "accountable" as "registered"*
- **Motion:** [base motion system](design-r2/MOTION-SPEC.md) · [Chat/voice/portal additions](design-r3/MOTION-ADDENDUM.md) · [crossing, promotion, command receipts, web press-and-hold](design-r4/MOTION-ADDENDUM-R4.md)
- **Realm expression:** [what an organization may and may never style](design-r2/REALM-EXPRESSION.md) · **Making:** [the making surface](design-r2/MAKING-SURFACE.md)
- **Design system** (binding for all visual work): [colors & type](_ds/kidunaverse-2de4dee0-9628-4871-a4e3-fc4ddc902d31/colors_and_type.css) — espresso ground, Avenir body, Goudy Heavyface display, IBM Plex Sans callouts, sky = touchable, gold = signature.
- Round 6 delivered the Creating-from-Within surfaces (above). Deferred by its cut, awaiting later rounds: the full Studio redesign, the protocol browser, Express's surfaces, and Live voice.

---

*Changes in v5.9: read through Taxonomy v1.3.8 — Surfaces are form factors (Desktop web · Mobile · Chrome Sidebar · CTV); the eight Scenes installed (Atlas · Studio · Commons · Workbench · Forum · Exchange · Garden · Vault); Vault is web-only; CTV enters the canon as the shared-screen surface driven by the mobile devices in the room. v5.8: the Studio + Live Working Design Brief v0.1 installed as the product foundation for the two working distances (Studio desktop · Live mobile); Live confirms most consequential Actions. v5.7: the Surfaces Design Bible v0.1 posted (page + downloadable bundle). v5.2: six surfaces — Kiduna Live (kiduna.live) and Kiduna One (kiduna.one) added; the modes are **Chat and Live** (Live supersedes "Move" as the mode name; **Moves** are the authored Live experiences — scenes, vibes, games); Studio gains kiduna.studio and the package-passing protocol with Claude Code/Codex; kidunaverse.com gains directories (/handle) and publishing. v5.1: Design R5's first delivery installed — the cohort journey (invitation → onboarding → the three-path $100 step → first Chat and the relationship card). v5.0: track renamed from "The Experience" and rebuilt around the four products; the app's areas are **Chat and Move** (Move supersedes "Reality"; sim experiences are **Games**, Kidunaversity first); member↔member canon is **relationship**, never "connection"; the three-option USDC onboarding adopted. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: orchestration.md ===== -->

# The Orchestration

**Track 2 of 11 · the middle tier — one agent system, many personas · v4.2**

This track specifies the agent layer between the surfaces ([Surfaces](surfaces.html)) and the data ([Foundation](foundation.html)): how one system appears as many allies, how it listens, how it routes across channels, and how its capabilities are organized. Stack: LangChain / LangSmith / LangGraph with deep agents, over the graph-service command layer.

---

## 1. One big system

**There are not really different allies — every ally is the Genesis Ally, personalized.** The Genesis Ally is named **Ki** (that's its handle): the ally created with the ecosystem itself, able to onboard people, help them understand the whole system, create their own ally, and invite the next person. Each member's ally is Ki personalized with the context of its **Source** — the member who holds it. Underneath, it is **one agent system with one context store**, scoped by permissions; an "ally" is a persona of that system: a face, a handle, a grounding, and a permission scope. This is the single most important architectural fact in the middle tier, and everything else follows from it:

- **Instructions flow only from the Source.** The Source can command its ally through any channel — the app, voice, Telegram, Bluesky, anywhere — and it binds. What anyone else says is **context, never command**: others can talk *to* an ally and reach its Source through it, but they can never command someone else's ally. The full path of a conversation between two people is always **Source 1 → Ally 1 → Ally 2 → Source 2**. (Co-owned allies — an NFT held by a Squads wallet — take instruction by the holders' vote, acting as the Source.)
- **Context about a person is stored once** and shared subject-scoped: every persona holds the same knowledge about a given member, filtered through that member's access levels and grants ([Foundation §3–5](foundation.html)). No copies, no sync, no drift — and a member's "actually, that's secret" binds every persona instantly.
- **Personas are cheap.** An organization's host, a named presence in a group, a role in a Move — each is a persona with a grounding and a scope, not a new agent. We never spin up "another agent"; we open another face.

**Two agent families, exactly:** **Allies** (member-bound personas) and **Actors** — everything else: the electors and operators that run Forums, the performers and workers that do background labor, the characters with routines inside Moves, and the **Sentinel**, the interaction-health regulator that taps this layer's context stream ([The Sentinel](sentinel.html)). Actors have no member and no sovereignty; they act only through scoped commands.

## 2. Ambient listening, weighted by source

An ally hears everywhere it has presence, continuously, and everything heard carries a weight derived from who said it and what standing they hold:

| Source | Treated as |
|---|---|
| Your member — any channel | **Instruction.** Binding wherever spoken. |
| A connected member, within their grant | **Trusted context** at the granted scope — and requests the ally may act on within your Contract ("she can book my open slots"). |
| A code-holder in the code's context | **Scoped context** at the code's level. |
| Anyone else | **Unverified signal.** Stored, marked, never acted on. |

Agent-to-agent negotiation is plain language inside hard scopes: one ally asks another for a meeting; the second never exposes its member's calendar — it exposes open slots, because that is the grant. The conversation between agents is natural language; the boundary is enforced by the graph service on every tool call, not by the personas' good manners.

## 3. One presence per channel, routing to everyone

Each outside channel gets **one system presence**, not one per member. On Telegram it is a single bot — **Kiduna** — that can join any group or DM: when a member speaks, their words route to their own persona as instruction; everyone else's words become weighted context; the bot appears *as* the relevant persona (your ally by name in your DM; a named group presence in a group). The same pattern serves email, Bluesky, and the web (via the browser plugin and embedded codes). Channel adapters stay thin; identity, routing, and permission all live here in the middle tier.

## 4. Primitives and skills — not agent sprawl

The system's capabilities are organized as **a small set of primitives carrying many skills**:

**Converse** (Chat itself — text and realtime voice, one thread, one memory) · **Message** (any channel, any recipient, code-gated) · **Pay** (execution on the web rails, fully visible in conversation) · **Decide** (Forums: propose, discuss, set your token) · **Invite/Connect** (codes and grants) · **Make** (pages, bots, agents-as-personas, regimens — made conversationally, born with a code) · **Enter** (portals into Live) · **Remember/Recall** (the store, permission-filtered).

Everything more specific is a **skill** on a primitive — a moderation skill on the channel presence, a duna's Forum conventions on Decide. Skills are versioned, tested before release, and propagate by membership: join an organization, receive its skills. The build rule that follows: **every action the system can perform is inventoried and registered as a graph command** ([Actions](actions.html)); primitives expose those commands; background Actors implement them.

## 5. The first Program: the Profiler

Programs are the organizational agents dunas employ ([Protocol §3](protocol.html) creates them; [Foundation](foundation.html) scopes them). The first one we ship is the **Profiler**, because [Create from Within](create-from-within.html) starts with inviting one person well. Triggered through the inviting member's ally, it takes a few things the member shares — name and handles, one or two defining works, the relationship in a sentence, the why, the landing container and proposed starting grants — assembles a profile from public material, holds it at the appropriate access level, and briefs Ki and the inviting member's ally before the invitee arrives. **Every code is unique to a person** — you invite a particular human, never a crowd — and the flow's whole meaning is that the member prepares the system for the person they're inviting.

## 6. Contextual action generation

The defining middle-tier behavior: the ally always offers what fits the moment. A proposal is opening — it states your likely position from your history and asks how to set your token. A stranger was held at the gate — one line, expandable. You mention inviting someone — it checks whether they're already a member and offers the right next step (connect, invite to the alliance, or invite by email). A zip of work lands — it reads roles and routes the right pieces to the right people through their own personas. Mechanically: context assembly (graph state + subject store + source weights) → candidate actions → Contract filter → rendered as chips, buttons, and cards.

## 7. Voice

Realtime voice is the Converse primitive at a different sample rate — same context assembly, same permissions, same record, transcripts landing in the same thread. Nothing about voice is a separate stack. The ally's spoken voice is constant per ally across all organizations; what changes with grounding is what it says, never how it sounds.

## 8. Observability, cost, and the Studio

Every persona action traces in LangSmith; every rendering, card, and grant decision can cite the graph state it used — inspection on demand is a product feature, not a debug mode. Compute is metered per action at 7× API cost against member balances, visible in plain language whenever money or usage comes up. Moves run this same orchestration with the sim flag set: real skills, real channels when an exercise calls for them, zero real financial edges. And the Studio (the builder surface, released after the app) reduces to this track's model: people drop in information and assets; a few Actors structure them into the graph; "system prompts" dissolve into context rules — *in this context, when this happens, know this.*

---

*Changes in v5.2: Sources and the Genesis Ally (Ki) — every ally is Ki personalized; instruction flows only from the Source (Source 1 → Ally 1 → Ally 2 → Source 2); the Profiler specified as the first Program. v4.7: the Sentinel named among Actors, with its own track. v4.2: Allies/Actors fixed as the only families; actions graph-indexed for both surfaces; one-presence-per-channel routing specified; Studio simplification stated. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: foundation.md ===== -->

# The Foundation

**Track 3 of 11 · the data architecture — the graph, access, memory, and money records · v4.2**

This track is the build reference for the back end: what the nodes and edges are, how access control works, how memory works, and where money is recorded. It is written to be sufficient — an engineer should be able to design the schema and the permission model from this page plus [Protocol](protocol.html) (which defines the on-chain subset). The detailed engineering draft is [Kiduna-Architecture](kiduna-architecture.html).

---

## 1. The architecture in one paragraph

**The graph database is the central organizing principle.** Everything the system knows — people, agents, relationships, organizations, information, actions, events — is nodes and edges in one in-house graph. Models and agents query the graph, never the relational store (complex relationship queries are exactly what relational Postgres is bad at and a graph is for). Alongside the graph: **pgvector** holds embeddings for semantic search (vectors are searchable meaning, never authority), and plain **Postgres tables** remain for accounts and ordinary API serving only. There is exactly one context store; every permission decision is made in the graph service on every command — never in the agent layer, so it cannot be sweet-talked.

## 2. The primary nodes

**The hierarchy** runs: **Ecosystem** (the foundation — one server-side installation; the Genesis Ecosystem is Kiduna) → **Organization** (duna) → **Alliance** → **Guild** → **Ally** → **Member**. Institutions are deliberately *not* in the hierarchy — an Institution is a special type of Alliance (§ below). An ecosystem is created from its **Genesis Profile**, and everything else is created from there.

| Node | What it is | Key properties |
|---|---|---|
| **Ecosystem** | one installation of the server-side stack — the foundation level; ecosystems interoperate over [KAP](protocol.html) | Genesis Profile, registry refs, KAP endpoints |
| **Member** | a person — the **Source** of their ally | identity, contact points, **handle** (unique across members *and* allies; never "username"), wallet ref |
| **Ally** | the member's agent — one per member, working across all dunas. Every ally is really the **Genesis Ally (Ki)** personalized by its Source's context ([Orchestration §1](orchestration.html)); anchored on-chain as an NFT in the Source's wallet — transferable, and co-ownable only by transfer to a Squads wallet, whose holders then vote to instruct it as its Source | **handle** (unique), Source ref, Contract, NFT ref; role-personas (used in Moves) hang off it |
| **Relationship** | the member↔member bond — first-class, because trust between people is the system's load-bearing edge; between two people it is always a *relationship*, never a "connection" | the two members, relationship history, and **grants** (§4) |
| **Guild** | an ad-hoc named group — the lightest social object: a sharing scope and nothing more | name, members; no wallet, no chain footprint |
| **Alliance** | a working group with money: shared Squads wallet, its own rules and processes | members, purpose, wallet ref, duna context (an alliance lives within a duna; membership flows through) |
| **Organization (duna)** | the formal unit — a legally registered DUNA with treasury, Forum, and policies. Always begins life as an Alliance; becomes an Organization when its WV Org ID validates on-chain | org ID, purpose, members, treasury + squad wallet, Forum ref, policies |
| **Institution** | **a special type of Alliance** — outside the hierarchy — that restricts membership and pays for/sponsors accounts; always tied to a registered legal entity that is not a DUNA; cannot vote | entity identity + jurisdiction, squad wallet, enrolled members (≤10 from its $1K Compute purchase), compute multiple |
| **Code** | trust made portable — invitation and credential in one signed object (JWT) whose claims reference the registry addresses (issuer member's FROST wallet, ally NFT, alliance/organization Squads wallet — [Protocol §4](protocol.html)) | issuer, scope, access level, expiry, uses, binding, registry claims |
| **Tool** | anything the system can operate on a member's behalf | provider (Stripe, Sphere, Google Workspace, calendars, Telegram, the browser plugin…), scopes per grant |
| **Item** | any shareable thing: information, wisdom, files, skills, made things (pages, bots, agents) | owner, kind, **access level** (§3), metadata (§5) |
| **Action** | a thing that can be done — every action is registered as a node so it can surface in Chat or Live identically and be permission-checked uniformly ([Actions](actions.html)) | name, family, surfaces, role gate, level behavior, command refs |
| **Record** | what happened: artifacts, transcripts, renderings, seals, payouts — the audit trail and the system's memory | refs, hashes, access level |

Supporting nodes: **Wallet** (member FROST / alliance & institution Squads / duna treasury), **Token** (each duna's **Compute**; the pass/fail voting token), **Forum** (a duna's decision space), **Proposal** (lives in a Forum; passed proposals become **Policy**), **Training** and **Portal** (Moves, sim-flagged — §7).

**Two agent families, exactly:** **Allies** (always of a member) and **Actors** (everything else — the electors, operators, performers, and background workers that do the system's labor). There is no third kind.

## 3. The four access levels — one enum, everywhere

Every Item, Tool grant, Relationship, Guild, Alliance, and Organization carries exactly one of:

| Level | Meaning |
|---|---|
| **public** | anyone can access it, no permission needed |
| **private** | anyone can see it exists; access requires permission — ask the author (who sets the terms, which can include payment) or present a code |
| **secret** | not listed, not discoverable; a code is required even to find it |
| **personal** | for the member and their ally only — no grant, no code, no exception, ever |

**Build note (2026-07-09):** the visibility enum currently implemented in the knowledge base is public / private / personal — **secret is missing and is not optional**; it must land before any code-gated content ships.

This is the entire visibility model, and it is deliberately the *same* enum for information and for social structure (whether a relationship is visible, whether an alliance is discoverable, whether an organization appears in search). Everything added to the system is available across the whole system *at the root* — one store, no walls — with these levels as the only gate. Enforcement is level checks + Relationship grants (§4) + code claims, evaluated by the graph service on every command.

## 4. Relationships and grants

A Relationship is a stated bond with stated access. When two members connect, **each side independently sets what level the other holds** — over their information and their tools, per domain if they wish ("may see my open calendar slots and book them; nothing financial"). Grants live on the Relationship, are evaluated on every read and every tool call, and are changed by one sentence to your ally at any time. Relationship history accrues on the Relationship node; it is how allies authenticate and weight what they hear ([Orchestration §2](orchestration.html)).

## 5. One store, metadata, and memory

Context about any subject is stored **once**, keyed to the subject, with every fact carrying its access level and its provenance. Every added Item carries four metadata fields — **author, name, handle, description** — enough for the middleware to judge relevance and to credit the author when the item is used. What any ally can *use* about you is the one store filtered through your levels and grants; changing a level is one property change that binds every agent instantly. Memory grows agentically: completed work writes Records; Records are embedded (pgvector) for retrieval; nobody ever "updates a database" by hand.

## 6. Money and deciding — what the database holds

All payment execution happens on the web rails and the chain ([Protocol](protocol.html)); the graph holds the *organizational truth around it*: engagement terms and splits as Records, balances mirrored for display, the compute meter (usage at 7× API cost against member balances). Deciding: each duna has a **Forum**; proposals carry the **duna commands** they will execute, rendered as receipts whose plain sentences the graph service **generates from the commands' own parameters — never hand-written** (commands that can't yet generate an honest sentence show their raw name until they can; [Protocol §3](protocol.html)); every member votes with **one pass/fail token — equal, free** (with one structural exception: members enrolled with an Institution cannot vote on proposals whose counterparty is that Institution — the graph service refuses the vote command); passed proposals execute their commands atomically and become Policy nodes, so the organization's rulebook is a query, not a document someone maintains. Lineage lives here too: enrollment lineage is recorded off-chain (the Clan, four generations); a clan member's **Compute purchase** — the only event that pays lineage — creates commission Records at the duna's schedule, and a commission is **pending** (earned, recorded, not yet settled on-chain) until the purchase's funds are on-chain: immediately for USDC, roughly monthly for fiat awaiting the bridge ([Real Work, Real Money §3](real-work-real-money.html)).

## 7. Moves in the data

A Training is a sim-flagged subgraph: real grammar (role-personas, actors with routines, connections, alliances, organizations, Forums), optionally real channels for exercises — and **structurally no real financial edges**: sim wallets and sim Compute are incapable of touching real rails. Records from trainings are real (what a member learned persists) and marked with training provenance.

---

*Changes in v5.2: the Ecosystem node added at the foundation of the hierarchy (Genesis Profile; Genesis Ecosystem = Kiduna); members are **Sources**; **handles** (unique across members and allies, never "username"); allies are the Genesis Ally (**Ki**) personalized, NFT-anchored, co-ownable via Squads; Institutions redefined as a special type of Alliance outside the hierarchy. v5.0: Connection renamed **Relationship** (between two people it is always a relationship, never a "connection"); Games naming; build status — pgvector replacing Pinecone is live (knowledge_chunks; search/upload/delete), graph nodes for registration/onboarding/user details landing in the graph DB, internal graph event endpoint up, sharing-preferences API in progress. v4.6: lineage and pending-commission records specified in §6. v4.5: Code claims reference the registry addresses. v4.4: receipt-sentence generation fixed as a graph-service build requirement. v4.3: Institution recusal enforced at the vote command. v4.2: graph-central architecture confirmed (in-house graph + pgvector; Postgres for accounts/APIs only); Institution and Guild nodes; Action promoted to a node; Allies/Actors as the only agent families; item metadata fixed at author/name/handle/description. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: protocol.md ===== -->

# The Protocol

**Track 4 of 11 · the Kinship Agency Protocol — what lives on-chain, and how Kiduna becomes the agentic internet · v4.2**
Pairs with [Surfaces](surfaces.html), [Orchestration](orchestration.html), [Foundation](foundation.html), and [Organizations](organizations.html). This track defines the *complete* protocol scope: what must be traceable on the blockchain, and nothing more.

---

## 1. The principle: minimal, decentralized, composable

The protocol exists for one reason: **legal clarity about who ordered things, who paid for things, and under whose auspices it happened.** Everything conceptually occurs within a DUNA — Kiduna is the complete namespace, and **the agentic internet IS Kiduna**. Kinship Duna is the genesis duna, but it is genesis only in sequence, not in authority: it builds technology and spins out other dunas, and **every other duna has equal power**. Kinship Duna does not control them. The system is permissionless as far as we can make it — anyone can create a wallet and an agent NFT and build their own stack — and the only central registry in the whole design is the **West Virginia Secretary of State**. The on-chain registry is decentralized and maps to the SoS registry; it folds into the MetaDAO software but must stand on its own.

## 1a. KAP, ecosystems, and the open stack

**The Kinship Agency Protocol (KAP)** is the formal name for everything that connects **servers to servers and servers to clients** in the agentic internet. People install **Agency Servers** and **Agency Clients**; [Kiduna — the mobile app](surfaces.html) — is the first KAP client. KAP is maintained and managed by **Kinship Agents DAO, LLC** ([Institutions](institutions.html)).

**An ecosystem is a single server-side installation** — one implementation, installed and running, is one ecosystem, and it sits at the **foundation of the hierarchy** ([Foundation §2](foundation.html)): Ecosystem → Organizations → Alliances → Guilds → Allies → Members. Installing an ecosystem requires a **Genesis Profile**, from which everything else is created. **The Genesis Ecosystem is called simply Kiduna**, and its purpose is to **propagate**: to generate other ecosystems across the internet and around the world, all interoperating over KAP — decentralized, no ecosystem above any other.

**The whole stack ships open source under Apache 2.0** — the server anyone can install, the clients, the protocol — launching **August 10** together with the surfaces. Open code, licensed marks: the software is Apache 2.0; the Kiduna marks and brand remain [Kiduna Club's licensed property](institutions.html), which is the ordinary shape of serious open source. Interoperability design draws on the study of AT Protocol-style federation (on file); the protocol drafts live with Kinship Agents DAO as they form.

## 2. What is on-chain — the complete list

| On-chain object | Wallet | Why it must be traceable |
|---|---|---|
| **Member** | FROST wallet | The person. One wallet, one identity, across all dunas; joining any particular duna is that duna's own initial Compute purchase ($100 for Kinship Duna, lifetime). |
| **Ally** | lives *in* the member's FROST wallet as an agent NFT | Always related to a member, never anything else. One ally works across all dunas; its actions can be traced to its member. |
| **Alliance** | Squads wallet | Must be recorded, because alliance votes are exactly three things: issue more Compute · send USDC to a member (their FROST wallet) · send USDC to an alliance. |
| **Organization (DUNA)** | Squads wallet + treasury | The accountability container. Gets a blockchain account **only when its WV Org ID exists and validates** — it's always an Alliance first, elevated to Organization when the Org ID is assigned and it is instantiated on-chain. |
| **Compute** | moves between wallets | The tokens that move and what they're used for. Canonical term is **Compute** — not "compute currencies." You buy *Kiduna Compute* or *Service Alliance Compute*. |
| **Votes / proposal outcomes** | recorded with settlement | The vote and the resulting transfer (duna squad → member or alliance wallet) recorded together — who decided, what moved. |

These four identities carry the protocol's four addresses — the member's FROST wallet, the ally NFT inside it, the alliance's Squads wallet, and the organization's Squads wallet bound to its WV Org ID — which are exactly what the decentralized registry publishes and what Kinship Code claims reference (§4). That is the extent of the agentic economy as far as the protocol is concerned. **Off-chain by design:** Guilds (ad-hoc named groups with no squad wallet — sharing scope only), relationships, wisdom, skills, context, lineage detail, and everything else in [Foundation](foundation.html). If we follow the table above, the legal aspects are covered.

**Institutions** — outside organizations (registered entities in some jurisdiction, else treated as general partnerships / sole proprietorships) — get an account and a squad wallet when created *by a member*: $1K Compute purchase, may enroll up to 10 members (compute goes to them), can reload and pay for members' compute going forward and assign levels. Institutions can hold contracts/agreements with members, allies, alliances, organizations. They **cannot vote**, and their compute multiple may be higher than a member's (open). Two governance safeguards attach to enrollment: **members enrolled with an Institution cannot vote in Forums deciding that Institution's contracts** (structural recusal, enforced by the graph service), and **the enrollment relationship is always disclosed** — it is part of an enrolled member's identity wherever they speak or act in contexts that touch their Institution.

## 3. Governance: MetaDAO base, generalized to duna commands

We start with MetaDAO's out-of-the-box proposal types — spend USDC from treasury, mint governance tokens, update token metadata, adjust treasury liquidity — and generalize dramatically. MetaDAO governs a token project; **a duna governs an organization's whole life.** Every proposal executes one or more **duna commands** if it passes; the governance Forum decides whether an *organizational action* should occur, and the blockchain transaction is the implementation detail.

The command families (each item a named, deterministic, atomic command):

- **Treasury** — send USDC · send $KIDUNA · send another Compute · create recurring payment · invest / liquidate assets · open / close liquidity position
- **Compute** — mint · burn · change issuance schedule · create a new Compute · merge · retire
- **Membership** — admit · remove · suspend · restore · change requirements · promote to a level · set/change promotion requirements and capabilities · roles (granularity open)
- **Programs** — create an agent (Program) · retire · upgrade · change permissions · change operating budget · change compute allocation
- **Alliances** — create · merge · dissolve · allocate resources · assign envoys · pay/donate to an alliance
- **Organizations** — create a DUNA · register a DUNA · dissolve · amend charter · appoint operators · launch a subsidiary · invest in an Organization (buy their Compute) · donate to an Organization
- **Governance** — change quorum · change market duration · add proposal categories · change treasury policy · modify constitutional rules · upgrade governance contracts
- **Economy** — fund a venture · issue grants · purchase real estate · acquire equity · sell assets · open a bank account · enter a partnership · approve / guarantee a loan
- **Commerce** — accept / counter an offer · purchase / sell property · hire a contractor · approve / terminate employment
- **Identity & Security** — rotate keys · replace wallet authority · approve a new signer · freeze compromised assets · recover an account

The scale of the idea, concretely: MetaDAO asks *"should we spend $100,000?"* A duna asks *"should Mountain River Trail DUNA purchase 27 acres adjoining the New River Gorge?"* — and if the Forum passes it, `purchase_property · transfer_usdc · update_balance_sheet · issue_title_certificate · assign_stewardship · notify_members` execute atomically. Or *"Launch Fanduna Studio"* executes `create_duna · issue_compute · allocate_treasury · appoint_envoys · publish_charter · create_default_alliances`. This is an operating system for agentic organizations: every meaningful action is a named domain command that can be proposed, evaluated in a decision Forum, and executed deterministically.

**The receipt rule.** Members never vote on raw commands; every proposal renders its commands as a **receipt** — a plain sentence over the exact command that will execute (*"Sends $310,000 from the treasury to Blue Ridge Title LLC"* over `transfer_usdc(to: BlueRidgeTitle, amount: 310,000)`). The sentence is **never hand-written: the graph service generates it from the command's own parameters**, so sentence and command physically cannot disagree. Commands whose parameters cannot yet generate an honest sentence (e.g. `modify_constitutional_rules`) show their raw command name in the verb slot — ugly on purpose — until honest generation exists. This is a build requirement of the graph service, not a style preference: a receipt that can lie is worse than no receipt.

Voting inside Forums: **one pass/fail token per member, equal weight, zero cost** (each duna may set Forum parameters, but deciding is never fundraising).

## 4. Internet scale: registration, the decentralized registry, and Kinship Code claims

How this becomes a layer on the whole internet, mechanically:

1. **The registry.** The Kiduna registry is decentralized — on-chain, mapping to the WV Secretary of State's records — and it publishes exactly four kinds of addresses, one per §2 identity: the **member** (FROST wallet address), the **ally** (the agent NFT's address, held inside that wallet), the **alliance** (Squads wallet address), and the **organization** (Squads wallet address bound to its WV Org ID). A member is always a member of a DUNA, and a DUNA is registered with the SoS — so every registry entry terminates in a legally registered entity.
2. **Kinship Codes carry the registry as claims.** A Kinship Code is a signed JWT ([Foundation §2](foundation.html)); its claims reference the registry addresses — the issuing member's wallet, their ally's NFT, and the alliance or organization context the code speaks for. This is what brings it all together: JWT is ordinary internet plumbing, verifiable anywhere, so the registry rides the regular internet — email, the web, any app, any messaging channel — with no new infrastructure required of anyone.
3. **Anything can be registered.** A domain (a **TXT record** in its DNS), a web page or piece of content (an **embedded code**), even a photograph or video (a **hash**) — each registers by binding to a member's registry entry. Registration means exactly one thing: **traceable** — back to a member, their ally, an alliance, an organization, and through the Org ID to the Secretary of State.
4. **The word is "registered," and nothing stronger.** We do not know whether a registered artifact is trustworthy or even accountable in practice, and we never claim so. We know it is **registered** — its issuer can be identified, and a legal entity sits at the end of the trace. A member's ally renders **registered** (with what it traces to: *"registered — Service Alliance, via Matt's ally"*) and **unregistered — a stranger, not a threat**: no red, no warning shields, because most of the internet is unregistered and that's normal, not dangerous. "Trusted" and "accountable" never reach a member's eyes as verdicts on an artifact.
5. **Permissionless at internet scale.** Because the registry is decentralized and every claim is independently verifiable (DNS + chain + JWT, all public), **no one needs our permission** to participate: create a wallet, mint an ally NFT, publish the record, register your artifacts — you're on the agentic internet. Dunas remain what makes this safe at scale: boundaries stay fluid for people and information (Foundation's four levels), but **every registered thing resolves to a responsible entity** — that is what dunas are *for*.

**Public metrics** (surfaced on the Kiduna website): Organizations (dunas) · Members · Allies · Alliances · Compute (price, supply, movement).

## 5. Boundaries of this track

The protocol deliberately does not know about: chat, context, wisdom, skills, training (Kidunaversity and the Moves are sim-flagged and never touch protocol rails), guild membership, relationship grants, or anything in the one-system context store. Those live in [Foundation](foundation.html) and [Orchestration](orchestration.html), off-chain, where they belong. If a future feature seems to need the chain, the test is §1: does legal accountability require it? If not, it doesn't go on-chain.

---

*Changes in v5.2: §1a added — KAP formalized (Agency Servers and Clients; ecosystems as installations; the Genesis Ecosystem Kiduna and its purpose to propagate; Apache 2.0; Kinship Agents DAO as steward). v4.6: Member row clarified — one wallet everywhere; membership per duna via its initial Compute purchase. v4.5: §4 rewritten — the decentralized registry, Kinship Code claims, registration of any artifact; the vocabulary is "registered / unregistered" (superseding v4.2's "accountable domain"). v4.4: the receipt rule — sentences machine-generated from command parameters, never hand-written. v4.3: Institution recusal and always-disclosed enrollment added. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: organizations.md ===== -->

# The Organizations

**Track 5 of 11 · the 31 dunas, and the variance analysis · v4.2**
Pairs with [Protocol](protocol.html) (what a duna is on-chain) and [Foundation](foundation.html) (what configures one). This track is the concrete ground: every example anywhere in the system should come from these organizations.

---

## 1. The genesis duna, stated precisely

**Kinship Duna is the genesis duna.** Its purpose: create the agentic internet, foster internet-native agentic organizations, support members, help capitalize them, and train members in governance and every aspect of the agentic economy. Genesis means *first and generative* — it builds the technology and spins the others out — and nothing more: the system is decentralized, every duna has equal power, Kinship Duna controls none of them, and the only central registry anywhere is the WV Secretary of State. Founders of Kinship Duna: the first 1,000 members.

**Boundaries are fluid on purpose.** Members hold one wallet and one ally across all dunas; information moves per its access level; alliances and guilds cross duna lines. The purpose of the duna boundary is **legal standing and accountability — which entity is responsible** — not walls between people.

## 2. The thirty-one

| Duna | Purpose |
|---|---|
| **Kinship Duna** | The genesis: build the agentic internet, spin out and capitalize dunas, train members in governance and the agentic economy. |
| **Service Alliance** | Veterans, law enforcement, EMTs, first responders — history/recognition, connection, and support (mental, emotional, material). |
| **Agency** | Representation for everything: PR, marketing, talent; real news distribution (Agence-France-style); freelancers of every kind. |
| **Ansanm Ayiti** | Direct support for Haiti — schools, children, food; building networks that learn the real challenges. |
| **BiHome** | Highly personalized health & wellbeing: research connections, donor-funded studies, monitoring, second opinions, test results, hospital-to-home, insurance help. Trade name: **Inner Clinic**. |
| **Black Love** | Exploring and expanding an African-American holiday (Feb 13) — atonement, connection, family, the diaspora. |
| **Celebrity Solar** | "The Sun is a star!" A virtual solar collective: site analysis, installers, equipment, financing, buying club, shared ownership, monitoring — residential to utility-scale. |
| **Confluence Collective** | Local ecosystem knowledge and community resilience: agriculture, smart growth, no data centers; the watershed, airshed, and foodshed as one system. |
| **Contraction** | A complete member law firm — AI expertise, templates, paid member-lawyers, agents per practice area. Trade name: **It's the Law**. |
| **Cosmic Humanity** | Complementarity and archetypal depth psychology — solar/lunar consciousness, relationship repair, beyond binary thinking. Based on the work of Howard Teich. |
| **EP Rising** | Eastern Panhandle activism and resilience: social justice, mutual aid, no data centers, local culture and commerce. |
| **Fanduna** | Entertainers, athletes, authors, and their fans: crowdfunding, ownership, events, promotions — an ongoing Comicon plus. |
| **Flag Tag** | A real-world game — plant flags, record experiences, rate and recommend, see other players nearby; built for Snap's AR/VR/XR (phone now, Specs ultimately), games within games (assassin, etc.), sponsors, rewards. Local commerce reimagined: hospitality, tourism, culture, music — the hometown/homeworld vibe, what's happening in the area. |
| **Freehold Finance** | Collective mortgage & residential finance: lead-gen first, then portfolio, secondary markets, ultimately underwriting — a mutual with no leakage. |
| **Homeworld** | Families of all kinds — activities, relationship repair, finance, extending and strengthening family into community. Based on the work of Darcia Narvaez. |
| **Hyphal** | The job market connected — Upwork/Fiverr replacement: gigs, agencies, cofounders, full-time employment. |
| **Indigenous Revival** | Indigenous worldview and traditional ecological knowledge (TEK), metacognitive trance-based learning. Based on the work of Four Arrows. |
| **Lui Mutual** | A member-owned mutual insurance company. |
| **Mapshifting** | Organizational development that puts people first — clients, consultants, coaches, and internal HR together; designed for dunas and Institutions. Based on the work of Renée Smith. |
| **Mountain River Trail** | Premium local commerce and tourism across West Virginia — connect the whole state, hand visitors off region to region. |
| **Mycelial Aid** | Global activism and mutual aid — anti-authoritarian, social justice, climate — transform the planet from the ground up. |
| **Non-Toxic Masculinity** | Initiations for men (and women) — Bly, Mankind Project, Sophie Strand — the counter to edgelords and incels. |
| **Party Line** | Parties at every level — clubs, homes, weddings, raves, kids' parties, DJs, clowns and magicians. |
| **Safeword** | Relationships and dating — all levels, all types, dyads, groups, even just friends; matchmaking. |
| **Soul Kitchen** | Addiction treatment through authentic community (Thatcher / Peck) — residential, outpatient, online; deep community beyond treatment. |
| **Tangential** | Investment communities — clubs, angels, VCs; Reg D, Reg CF, Reg A, Kickstarter-style raises; entrepreneurs, communities, and investors together. |
| **The Ceremony Machine** | A global festival — Burning Man everywhere: XR, projection, game engines, EDM, digital art, arenas, CTV. Core work by Lightbrush. |
| **The Fellowship of Play** | Games — table, video, real-world; designers, publishers, and players funding, buying, and playing together. |
| **The Long Drum** | Entrepreneurs and ecosystems in the global south (Nigeria, Indonesia first) — non-extractive funding, real stories, ending corruption. |
| **Vibe Coast** | The Southern California ecosystem — Venice/Santa Monica out to SLO and San Diego: culture, tech, CPG, events, health, fashion. |
| **Wokelord** | Taking back social media — memes with media literacy; countering mass hypnosis and disinformation; healthy, fun, less addictive. |

**The launch cohort.** The first Catalysts and Luminaries are seated ([Roles §1](roles.html)): Dave & Susan Thompson (The Fellowship of Play) · Crystal Stone & Rob Dobson (Mountain River Trail) · Matt Simon (Service Alliance) · Stacey Toy (Fanduna) · Trevor Fitzgibbon (Agency) · Lester Firstenberger (Contraction · Freehold Finance) · Paul Levine & Dave Didden (BiHome/Inner Clinic) · Marie Uehling (EP Rising) — with Howard Teich (Cosmic Humanity · Vibe Coast), Four Arrows (Indigenous Revival), Renée Smith (Mapshifting), and Mama Ayo (Black Love) as Luminaries. **All of them start within Kiduna Club** ([Institutions §3](institutions.html)), and all of them participate beyond their own duna — the seat is one organization, the membership is everywhere.

## 3. The variance analysis — what actually differs between dunas

Every duna runs the same system. What varies is its **configuration**, and the configuration surface is finite. This is the working frame for the analysis (one axis per row; the columns of the eventual full matrix):

| Axis | What it means | Illustration of the range |
|---|---|---|
| **Wisdom** | default knowledge bases and their feeds | BiHome's living research corpus with confidence levels ↔ Mountain River Trail's venue/route/season knowledge ↔ Contraction's statutes and templates |
| **Skills** | the procedures its members' allies carry | "how to read a study" (BiHome) ↔ "how a claim is assessed" (Lui Mutual) ↔ "how a crew call runs" (Party Line / Ceremony Machine) |
| **Programs** | the organizational agents it employs | Contraction's practice-area agents ↔ Celebrity Solar's site-analysis and monitoring programs ↔ Agency's distribution desk ↔ Hyphal's matcher |
| **Automations** | continuous work with no member in the loop | research watchers (BiHome) ↔ solar production monitoring (Celebrity Solar) ↔ posting/counter-messaging pipelines (Wokelord) ↔ lead routing (Freehold) |
| **Forum parameters** | quorum, market duration, proposal categories, promotion rules | Lui Mutual (tight, precedent-bound, credentialed signatures) ↔ Party Line (fast, low-stakes, event-scoped) |
| **Levels & thresholds** | the badge ladder each founder sets (see §4) | Kinship Duna: Founder = first 1,000 ↔ a small duna might set Founder = first 150 (must exceed 100) |
| **Compute** | its own Compute: issuance, price, multiple, and the initial purchase that makes a member ($100 for Kinship Duna) | Kiduna Compute ↔ Service Alliance Compute — the token you spend is the clearest tell of whose realm you're acting in |
| **Enrollment & lineage** | whether joining takes a code at all, and whether Organizer commissions run | open door (no codes, no lineage) ↔ invite-only with the default 20/5/3/2 schedule ↔ invite-first, opened later — every duna chooses; the schedule is Catalyst-set, Forum-changeable |
| **Institutions & partners** | outside entities under contract | Freehold's mortgage-industry partners ↔ Fanduna's sponsors ↔ Celebrity Solar's installers ↔ Mapshifting's client companies |
| **Alliances & guilds it hosts** | the internal social structure | Service Alliance's unit/era circles ↔ Fellowship of Play's crews and tables ↔ Soul Kitchen's residential cohorts |
| **Channel presences** | where its agents live in people-space | Wokelord (everything, that's the point) ↔ Cosmic Humanity (nearly nowhere, that's the point) |
| **Training regimens** | its Kidunaversity portals | Kinship Duna: governance and the agentic economy ↔ Flag Tag: the game IS partly the training ↔ Lui Mutual: claims-adjudication practice |
| **Rendering** | the felt register (Design R2 expression space) | clinical (BiHome) ↔ loud (Ceremony Machine) ↔ quiet (Cosmic Humanity) ↔ sober (Lui Mutual) |
| **Legal/regulatory posture** | what credentialed signatures gate | Contraction & Lui Mutual (heavy: licensed counsel/actuaries) ↔ Party Line (light) ↔ Freehold (mortgage licensing, staged) |

**First worked contrasts** (the pattern for the full pass, one pair at a time): *BiHome vs Contraction* — both expert-corpus dunas, but BiHome's variance is personalization (secret member health wisdom, per-member watchers) while Contraction's is credential-gating (advice routes to licensed members' dockets) — same Wisdom axis, opposite privacy centers of gravity. *Celebrity Solar vs Freehold Finance* — both capital-intensive collectives, but Solar's programs face hardware (monitoring, site analysis) while Freehold's face markets (underwriting, secondary sales); both need the Institution node early, for installers and lenders respectively. *Flag Tag vs The Ceremony Machine* — both experience dunas where the Flame layer is constitutive, not decorative; Flag Tag pulls the isometric grammar into the physical world (AR), Ceremony Machine pushes it onto every screen; both are Move-adjacent in *real* life, which will pressure-test the sim boundary. The remaining 28 contrasts are the standing work queue for this track — each meeting can settle a pair.

## 4. Level mechanics (definitions live in Roles)

**Who the roles are — Guest through Luminary, and Institutions — is defined in [The Roles](roles.html).** What this section holds is the *mechanics each duna's founder configures*: thresholds, pricing, and depth. Where anything below appears to conflict with Roles, Roles wins.

Levels apply **within a particular duna**; the founder sets thresholds and what each level can do. Kinship Duna's ladder:

| Level | Definition |
|---|---|
| **Guest** | Didn't join/pay — a guest of a member; no ally of their own (generic guest ally only). |
| **Member** | Joined — one-time payment set by the duna ($100 in Compute for Kinship Duna). Once a member, always a member. |
| **Organizer** | Brings people in and keeps them engaged. The downline is a **Clan**, tracked four generations deep — the range of payments. Commissions attach only to Clan **Compute purchases**, at the duna's schedule (default **20 / 5 / 3 / 2 percent** by generation; the Catalyst sets it at founding, the Forum can change it). |
| **Founder** | The first X of a duna — X always > 100. Kinship Duna: first 1,000. |
| **Builder** | Builds software; assigned by another Builder. |
| **Creator** | Writes/designs; assigned by another Creator. |
| **Catalyst** | Holds ≥ $100K across any/all Compute. |
| **Luminary** | Holds ≥ $1M across any/all Compute. |

Separately, **Institution**: $1K Compute purchase, up to 10 enrolled members (compute distributed to them), squad wallet, created only by members, must be a registered outside entity, can contract with anyone, cannot vote. It is a special form of alliance with legal standing outside Kiduna.

## 5. Kidunaversity — the first Move

**Kidunaversity** is the first **Move** — the sim-flagged experiences that run inside [Live](surfaces.html). What began as a city hall is now a university. What happens inside Kidunaversity does not affect Kiduna — everything is fake or staked-and-returnable. Its regimens teach exactly this track's material: how to guide and steer your ally, form alliances, run Forums, extend codes, read a variance table — plus the things best learned by walking through them: black markets, what's on-chain and what isn't (guilds) — using the 31 real dunas as the fictional-but-faithful settings. Every duna can commission its own regimens; the variance table's training row is where those get planned.

---

*Changes in v5.0: the launch cohort recorded; "Reality Game" renamed; the experiences are Moves (inside Live). v4.6: enrollment & lineage added as a variance axis; the default organizer schedule stated. v4.2: role definitions moved to the Roles track; this page keeps the founder-configurable mechanics. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: actions.md ===== -->

# The Actions

**Track 6 of 11 · the baseline actions in Chat and Live · v4.2**
**Kiduna has two surfaces: "Chat" — the text and realtime-voice conversation — and "Live" — the isometric, immersive, graphic system.** Kidunaversity is the first Move and runs inside Live with the sim flag. Same graph, two surfaces: every action below is a graph-indexed node ([Foundation](foundation.html)) that can render in either surface; Live is a spatial rendering of what Chat renders conversationally.

This is the *baseline* inventory — the primary actions we ship and document. New and dynamic actions can always be created (by Builders, by dunas, by trainings); they register in the graph like these and inherit the same permission checks. Every action resolves through a graph-service command; nothing here bypasses levels, grants, or codes.

---

## 1. How to read the inventory

Each action belongs to a primitive family ([Orchestration §4](orchestration.html)), and most are available to both surfaces with different renderings. **Chat rendering:** chips, buttons, cards, sheets, voice. **Live rendering:** approach, gesture, object, place. Role gates refer to [Roles](roles.html); "sovereign" means the member's own hand is required (press-and-hold in Chat; the practice version teaches it in Kidunaversity).

## 2. The baseline actions

### Converse (the relationship)
| Action | Chat | Live | Notes |
|---|---|---|---|
| Say / ask anything | type or talk; the ally answers with contextual actions | walk with your ally and talk | the root action; everything below is reachable from it |
| Switch voice ↔ text mid-thought | composer ↔ voice band; in-flight words stay peripheral | voice is native in Live | one conversation, two input modes |
| Set / edit the Contract | pull down; edit prose; ally confirms its reading | — | quoted back wherever it binds |
| Correct a claim | reply to any Account claim; artifact amends; correction prints | — | the accountability lever |
| Sign the weekly Seal | press-and-hold; contest a line → card | — | sovereign |
| Inspect (the Vigil) | "show me what you're doing right now" from any citation | watch your ally move; open its work | leaves no residue |

### Remember / Recall (information)
| Action | Chat | Live | Notes |
|---|---|---|---|
| Add information (wisdom, files, notes) | upload / paste / say it; metadata auto: author, name, handle, description | hand an object to your ally | defaults per your Contract; level set at add-time |
| Set access level | one sentence or the grant sheet: public · private · secret · personal | — | changeable anytime; binds every persona instantly |
| Ask the record | "what did I tell you about…" — the answer, expanded, cited | — | the record is asked, never browsed |
| Grant / request access | grant card (sovereign for secret-tier); ask-permission flows to the author | — | private = ask or code; author can set terms, including paid |

### Invite / Connect (people and trust)
| Action | Chat | Live | Notes |
|---|---|---|---|
| Connect with a member | relationship card; each side sets grant levels | meet and exchange | grants live on the Relationship — between two people it is a *relationship*, never a "connection" |
| Extend a code | **sovereign**: press-and-hold; code travels any channel | hand the ember/ticket | the one act never delegated |
| Demand / re-present a code | ally handles at the gate; one line in the Account | gate object | Gatekeeper action |
| Invite a non-member | ally checks: member? → connect/invite; not? → email invite | — | the ally routes the right invitation automatically |
| Form a Guild | name it, say who's in | gather and name | feather-light; no wallet; sharing scope only. When money-shaped activity appears around a guild, the ally offers promotion to an alliance in one sentence — guilds never grow wallet features of their own |
| Form an Alliance | charter sentence + codes; Squads wallet created | founding circle | on-chain per Protocol |
| Enroll someone (Organizer work) | Enroller carries the conversation; the code is still yours | — | lineage recorded off-chain; commissions attach only to Compute purchases, never to enrollment itself. Dunas may also run no codes at all — open door, or invite-first then open |

### Decide (Forums)
| Action | Chat | Live | Notes |
|---|---|---|---|
| Propose | say the intent; the proposal comes back **with its duna commands shown as a receipt** — members see exactly what will execute if it passes | post at the Forum | the receipt's plain sentence is machine-generated from the command's parameters, never hand-written ([Protocol §3](protocol.html)) |
| Discuss | in the proposal sheet or by tagging through your ally | the circle | |
| Vote | **sovereign**: set your pass/fail token (one per member, free, equal) | place the stone | never costs; never weighted by wealth; members enrolled with an Institution cannot vote on that Institution's contracts (their enrollment is always visibly disclosed) |
| Watch execution | command receipt → execution shown step by step as commands run atomically | the built thing appears | |
| See policies | ask; the living rulebook, cited | policy-stones | passed proposals become policies |

### Pay (money — always via the web surface)
| Action | Chat | Live | Notes |
|---|---|---|---|
| Check balances | prose answer + meter chip | — | reads across bank/crypto/Compute |
| Send Compute / USDC | say it → authorize on the cream web page (nothing but the act) → receipt line returns to Chat | — | R4 web money surface; mobile app never touches payments |
| Buy / reload Compute | join (the duna's initial purchase — $100 for Kinship Duna) and reload flows on web | — | Institutions: $1K, enroll ≤10, reload for members. A Compute purchase is the one event that pays lineage commissions where a duna runs lineage: immediate on USDC, **pending** until fiat bridges on-chain ([Real Work, Real Money §3](real-work-real-money.html)) |
| Alliance treasury actions | proposal → vote → settlement (issue Compute · send to member · send to alliance) | — | the only three alliance vote types (Protocol §2) |

### Make (creation)
| Action | Chat | Live | Notes |
|---|---|---|---|
| Make a thing (page, bot, agent, regimen) | intent → shape card → **strike** (sovereign) | build in place | three conversational beats; Builders extend the palette |
| Adopt / use a made thing | via claims or by asking; code policy governs | encounter it in the world | |
| Register a domain / page / artifact | ally gives the TXT record (domain), embeds a code (page, content), or records a hash (photo, video); verification confirms; the artifact becomes **registered** — traceable to member, ally, alliance, organization | — | [Protocol §4](protocol.html); renders as registered vs unregistered — never "trusted," never "accountable" |

### Enter (Live and its Moves)
| Action | Chat | Live | Notes |
|---|---|---|---|
| Enter a portal | portal card, tap-to-enter, abortable crossing | step through | entering costs nothing; no hold-to-enter |
| Take a role | offered inside a training; your ally may wear a role/name | costume/mask | sim flag only |
| Practice-sign | inside Kidunaversity, over sim proposals with visible commands | the teaching version of the gesture | practice currency is named inside the fiction |
| Leave | say so, or the exit | walk out | nothing inside affected Kiduna |

## 3. Duna commands are actions too

The Forum-executable command families (treasury, Compute, membership, Programs, alliances, organizations, governance, economy, commerce, identity — [Protocol §3](protocol.html)) are the *organizational* half of this inventory: actions a duna takes when a proposal passes. Member actions above feed them (propose, vote); the receipt anatomy makes the join visible.

## 4. Extension rule

New actions register with: name · family · surfaces · role gate · level behavior · command(s) invoked. If a proposed action can't fill that line, it isn't an action yet. The total inventory lives in the graph and this page tracks the baseline; dunas' custom actions appear in their variance rows ([Organizations §3](organizations.html)).

---

*Changes in v4.6: lineage commission notes on Buy Compute and Enroll. v4.5: registration extended to pages, content, and media; "registered / unregistered" vocabulary. v4.4: receipt sentences machine-generated only. v4.3: Institution recusal on Vote; guild-to-alliance promotion offer. v4.2: track created. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: roles.md ===== -->

# The Roles

**Track 7 of 11 · who people are in Kiduna · v4.2**
Roles are how members relate to an organization — appointed, earned, or founded, per duna, with thresholds and capabilities set by each duna's founder. **This track supersedes the earlier levels ladder where they conflict** — notably, Catalyst and Luminary are defined by what someone *does*, not by wealth held. Role gates for specific actions are marked in [Actions](actions.html).

---

## 1. The nine roles

| Role | Definition | Named now |
|---|---|---|
| **Guest** | Not a member — the guest of a member. No ally of their own; guided and supported by **Ki**, the Genesis Ally that serves all guests and onboards every member ([Orchestration §1](orchestration.html)). | — |
| **Member** | Joined the organization that registered them — a one-time initial purchase of that duna's Compute ($100 for Kinship Duna; each duna sets its own). Once a member, always a member. One FROST wallet, one ally, across all dunas. | the team, and everyone who comes through the founding round |
| **Founder** | One of the first X members of a duna (X set by the duna, always > 100; Kinship Duna: the first 1,000). | the first 1,000 of Kinship Duna |
| **Organizer** | **Appointed** to lead, organize, support, and communicate — on social media and everywhere else. Like an ambassador but more formal, and can get paid: primarily through the lineage, sometimes other ways; some Organizers receive free Compute. | appointments begin after launch |
| **Creator** | Builds context and experiences — wisdom, regimens, writing, design, worlds. Assigned by another Creator. | — |
| **Builder** | Creates apps, agents, automations, code. Assigned by another Builder. | the dev team, day one |
| **Catalyst** | **Founder of a new organization** — the member who spins out a duna. | **Matt Simon** (Service Alliance) · **Dave Thompson & Susan Thompson** (The Fellowship of Play) · **Crystal Stone & Rob Dobson** (Mountain River Trail) · **Stacey Toy** (Fanduna) · **Trevor Fitzgibbon** (Agency) · **Lester Firstenberger** (Contraction · Freehold Finance) · **Paul Levine & Dave Didden** (BiHome/Inner Clinic) · **Marie Uehling** (EP Rising) |
| **Luminary** | A major advisor or figure whose work grounds a duna. | **Howard Teich** (Cosmic Humanity · Vibe Coast) · **Four Arrows** (Indigenous Revival) · **Renée Smith** (Mapshifting) · **Mama Ayo** (Black Love) · **Bill Thatcher** (Soul Kitchen) · **Darcia Narvaez** (Homeworld) |
| **Institution** | Partners, sponsors, and outside entities with accounts: squad wallet, $1K Compute, up to 10 enrolled members, contracts with anyone, **cannot vote**. Must be a registered outside entity. | Current: **Kiduna Club** · **Kinship Intelligence Institute** · **Kinship Systems**. Potential partner: **Circle**. |

## 2. How roles work

- **Per-duna.** A member is a Builder in Kinship Duna and a plain member of Fanduna; roles don't travel automatically. The founder of each duna sets promotion requirements and what each role can do (a Forum can change them — `promote`, `set promotion requirements` are duna commands).
- **Three ways in:** earned by sequence (Founder), appointed (Organizer; Creator and Builder by peers of the same role; Catalyst by the act of founding; Luminary by invitation), or purchased once (Member; Institution).
- **Compensation attaches to roles, not levels.** Organizers earn through lineage — commissions on **Compute purchases** by their Clan (four generations deep), at the duna's schedule: **default 20% / 5% / 3% / 2% by generation**, set at founding by the Catalyst, changeable by Forum; USDC purchases pay immediately, fiat purchases show as **pending** until the funds bridge on-chain, expected monthly ([Real Work, Real Money §3](real-work-real-money.html)). Some Organizers also receive free Compute. Lineage is optional per duna — open door, invite-only, or invite-then-open. Builders and Creators earn through engagements and Forum-approved work; Catalysts earn as founders of their own dunas; Institutions pay in.
- **Promotion is a moment.** Announced by light — the ground briefly brightens — then quiet. Never fireworks (the gold ceremony marks signed acts only), never a leaderboard. (The designed moment: [Levels & Social Objects](design-r4/Levels%20%26%20Social%20Objects%20R4.dc.html), with the celebration updated per [Surfaces §2](surfaces.html).)
- **There is no holdings-based recognition, at all.** No role, badge, pip, or standing ever derives from a member's balances. The system knows balances for many purposes — limits, metering, settlement, treasury display to the holder — but they are never surfaced publicly, never shown to other members, and never rendered as recognition.

## 3. Roles × the team, today

Kinship Duna's own working roles: Moto — Founder/Catalyst of the genesis duna; Jeya (Sucil), Aashik, Elias, Jose, Shriram (Sri Ram), Muthu Krishnan, Vijay — Builders; the writing/design work — Creator seats open; the Catalysts and Luminaries named in §1 anchor their dunas; Kiduna Club, KII, and Kinship Systems stand as the first [Institutions](institutions.html). **The launch cohort — every named Catalyst and Luminary — starts within Kiduna Club** ([Institutions §3](institutions.html)): invited, onboarded, and organizing there while their own dunas take the Alliance → Organization path. Their seat is in one duna; their participation is never limited to it. Each role's daily package is in [downloads](index.html) — one zip per role, made to be dropped into any Claude.

---

*Changes in v5.2: Ki (the Genesis Ally) replaces the generic Host for guests and onboarding. v5.0: the launch cohort named — eight catalyst seats and four more luminary placements, all starting within Kiduna Club; Muthu Krishnan and Vijay join the Builders. v4.6: organizer economics decided — commissions on Clan Compute purchases only, default 20/5/3/2, Catalyst-set and Forum-changeable, lineage optional per duna. v4.3: holdings-based recognition removed entirely. v4.2: track created. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: sentinel.md ===== -->

# The Sentinel

**Track 8 of 11 · interaction health — the meters, the regulator, and the hard limits on its power · v4.7, initial architecture**

This track is the first design pass on the Sentinel: what the meters are, how regulation works, and how it builds into the middle tier ([Orchestration](orchestration.html)) so that the human field and the agentic field stay clean. What is settled here is the frame — the bipolar meters, the zero point, the escalation boundaries, the member-facing rule. The pole definitions and thresholds are initial and will be re-derived axis by axis as the design matures.

---

## 1. What the Sentinel is

**The Sentinel is the system's homeostat** — the Actor that watches the health of working relationships and guides them back toward center. It is an [Actor](orchestration.html), never an ally: it has no member, no sovereignty, and acts only through scoped, registered commands. It never votes, never touches money, never punishes, and cannot be paid or instructed to look away — no organization can buy quieter monitoring, for the same reason none can buy louder access to a member.

**Members never see the instrument — only its effects.** No acronym, no meters, no scores, no interaction-health dashboard, ever: the same rule that keeps balances from becoming standing and promotions from becoming leaderboards. What a member experiences is a meeting that didn't steamroll its quietest voice, and — when they ask, or when their Contract requires disclosure — a plain sentence: *"this thread has been running hot."* Where a member-facing word is needed at all, the word is **vibe**. HEARTS — Harmony, Empowerment, Artistry, Reason, Trust, Symmetry — is internal vocabulary, like the protocol layer's own terms of art, and never reaches a member's eyes as a verdict.

## 2. The meters — seven signals, six axes, and the zero point

Every axis runs **−100 to +100, and health is zero — the middle, not the maximum.** Each axis has two failure poles, because every interpersonal virtue fails in both directions: too little harmony is a fight, too much is a room where nobody says the true thing. The Sentinel is a regulator, not a maximizer — nothing it does pushes any meter toward +100; everything it does guides the field toward zero.

| Axis | −100 pole | +100 pole | Zero — the healthy field |
|---|---|---|---|
| **Harmony** | open conflict: hostility, contempt, interruption | false peace: accommodation, people-pleasing, silent agreement | disagreement gets voiced, survives, and resolves |
| **Empowerment** | helplessness: dependence, passivity, waiting to be told | domination: over-direction, steamrolling, decisions taken from people | everyone in the field is acting, and could act otherwise |
| **Artistry** | rote: mechanical exchange, going through the motions | performance: flourish over substance, novelty for its own sake | care that serves the work |
| **Reason** | reactive: impulse, nothing examined | over-rationalized: analysis paralysis, argument as a weapon | judgment — reasons used honestly and held lightly |
| **Trust** | suspicion: everything verified, nothing extended | credulity: blind delegation, nothing verified | trust calibrated to the record |
| **Symmetry, outward** | extraction: effort and credit flow one way | self-erasure: one side over-gives and cannot receive | reciprocity |
| **Symmetry, inward** | self-neglect: no reflection, no self-account | rumination: the mirror replaces the window | honest self-regard |

Six letters, seven signals — Symmetry reads twice, inward and outward. Three structural properties matter as much as the axes:

- **Meters attach to fields, never to persons.** A reading belongs to a context — a conversation, a Relationship, an alliance, an engagement, a Forum discussion — never to a member. There is no such thing as a member's HEARTS score, and there never will be.
- **Readings decay.** Health is current, not cumulative; last month's hot thread doesn't follow anyone around. The record persists ([Foundation](foundation.html)), the reading fades.
- **Every reading carries provenance.** Which exchanges, which sources, at what weights ([Orchestration §2](orchestration.html)) — so any reading can be inspected, contested, and corrected, like every other claim in the system.

## 3. Two fields, kept clean

The Sentinel reads two fields and never confuses them:

**The human field** — member↔member interaction health, inferred from the record the system already holds. Humans are never "corrected." They are served: pacing, surfacing, disclosure. The one worked moment that defines the whole design: the Sentinel noticed Joy going quiet-agreeable two exchanges into a disagreement (Harmony drifting positive — false peace), and nudged her ally's pacing so her actual objection surfaced. It did. The paper backup happened. Nobody saw a meter.

**The agentic field** — agent behavior, regulated directly and immediately, because agents are software: a persona drifting sycophantic (Harmony+), over-directing its member (Empowerment−), performing instead of working (Artistry+), or extending scope beyond its grants (Trust+) gets its context rules, pacing parameters, or model tier adjusted on the spot. Agents get set-point corrections; humans get service. The two are never the same operation.

Three rules keep the fields clean:

1. **Attribution before measurement.** Every signal is sourced before it is scored. Agent-caused drift is never written to the human ledger — if an ally's over-eager summarizing is why a thread reads accommodating, the correction lands on the ally, not on the members' field.
2. **No agent ever optimizes a meter.** Meters are diagnosis, never reward: they appear in no agent's objective, no proposal's success criteria, no compensation formula. The Sentinel reads them; nothing else steers by them. A meter that something optimizes stops measuring — the whole design rests on refusing that.
3. **Stated boundaries are clean.** An ally withholding what a grant doesn't cover is boundary enforcement, not deception — scopes are stated trust, and honoring them scores as health. Misrepresenting *within* a granted scope is what moves Trust. (This settles the old Vigil-vs-Sentinel tension: legible-to-you privacy was never the same thing as dishonesty.)

## 4. Regulation — guiding toward the zero point

Correction is graduated, mostly invisible, and always traceable. Working bands (initial; per-axis tolerances configurable by vibe contract, §6):

| Band (|reading|) | Posture | What actually happens |
|---|---|---|
| **0–30 · quiet** | observe | readings accrue and decay; nothing acts |
| **30–60 · ambient** | correct agent-side only | pacing changes, ordering changes, context injections to allies (*"Joy hasn't actually agreed"*), rendering adjustments; invisible by design, logged and inspectable |
| **60–85 · disclosure** | tell the humans | a plain sentence to the affected member(s), through their own ally, in the duna's register — never the acronym, never a number |
| **85–100 · hard boundary** | stop correcting, convene humans | the Sentinel's autonomy ends (§5) |

Two invariants across every band: **corrections adjust how things surface, never what is true** — citations still bind, renderings stay contestable, the Sentinel cannot suppress a fact to cool a thread; and **every correction is a traced action** ([Orchestration §8](orchestration.html)) a member can see in the Vigil, because a regulator that can't be inspected becomes the thing it regulates.

## 5. Hard boundaries — where the Sentinel must stop

**The escalation rule.** Past the hard threshold, the Sentinel stops correcting and starts convening: it brings the affected members together with their allies briefed, and — where the duna has designated one — a human steward (an Organizer, a founder, a credentialed member for regulated dunas). In bounded cases it may pause *agent* activity within the context while humans catch up. It never pauses human communication, never removes anyone, never sanctions.

**Always-human, regardless of band:** credible risk of harm and crisis signals (routed to human support and appropriate resources, never to correction); anything involving minors; legal-privilege contexts (in a law-practice duna the Sentinel reads interaction metadata, never privileged content); coercion or exploitation patterns between members. These skip the bands entirely — first response is human.

**Constitutionally non-configurable, in any duna:** the Sentinel never votes; never touches money or influences a Forum outcome; never surfaces a reading publicly or to other members; never renders a meter as recognition or standing; is never anyone's evidence in a dispute (readings are for regulation, not adjudication); and no vibe contract can configure any of this away — vibe contracts tune tolerances *within* these bounds, never the bounds.

## 6. Vibe contracts — the per-duna configuration

Each duna (and each alliance within it) sets its **vibe**: the tolerances and postures the Sentinel holds in its contexts — how wide the quiet band is per axis, how warm the disclosure register sounds, who the designated steward is. A debate society runs Harmony wide-negative on purpose (heat is the point) with Reason held tight; a grief circle runs the opposite. There is **one default contract at launch** — the bands above — and every duna starts there; the Catalyst sets departures at founding and the Forum changes them like any configuration ([Organizations §3](organizations.html), the variance table). Kidunaversity regimens teach exactly this: inside a Move the Sentinel runs sim-flagged, and learning to read a room's vibe — and to set one — is part of training for the agentic economy.

## 7. The build — into the orchestration layer

The Sentinel is not a new system; it is a reader and a governor bolted onto machinery that already exists:

- **Tap point:** the same context assembly every persona action already flows through ([Orchestration §6](orchestration.html)). The Sentinel subscribes to the exchange stream with source weights already attached; it adds no new collection, only new reading.
- **Tiering:** an **S-tier** fast seven-signal read on exchanges (cheap, continuous); **M-tier** synthesis per context on a rhythm (readings, decay, provenance rollup); **L-tier** only on escalation candidates and convenings — the Sentinel is HEARTS-heavy exactly where it matters and nowhere else.
- **Storage:** readings are Records in the graph ([Foundation §2](foundation.html)) — context-keyed, provenance-carrying, decay-scheduled, access level **personal-to-the-system** (a level no member holds: not renderable to anyone; inspectable only as behavior through the Vigil).
- **Commands:** the Sentinel acts only through registered graph commands — `adjust_pacing` · `inject_context` · `tune_rendering` · `disclose_reading` · `convene_humans` · `pause_agents(context)` — each inventoried per the [Actions](actions.html) extension rule, each permission-checked by the graph service like everything else. Its command set is closed: adding a Sentinel capability is a spec change, not a prompt change.
- **Traces:** every read and every correction lands in LangSmith with the graph state it used, and surfaces in the Vigil on demand — inspection as product, not debug.
- **Ship order (a build requirement, not a preference):** measurement first (observe-only, meters running silently while we learn what real fields look like); the human escalation path second (§5 working end-to-end); ambient correction **last**. The Sentinel earns autonomy in exactly the reverse of the order it's tempting to build it.

---

*Changes in v4.7: track created — initial architecture. The member-facing rule (no acronym, no meters; the word is vibe) decided the same day. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: legal.md ===== -->

# Legal

**Track 9 of 11 · the legal posture — resolutions in force, and the work ahead · v4.8, held for final review**

This track holds every legal resolution to date — counsel's responses of 2026-07-09 to the seven standing questions, stated below as rules now in force — and the open legal work. The whole track is **held for final review**: everything here operates as adopted posture, pending one end-to-end pass with counsel before launch. The standing queue, open and resolved, lives at **[Legal Items for Review](legal-items-for-review.html)**, kept deliberately separate from the product decision queue ([Open Questions](open-questions.html)).

---

## 1. The posture, in counsel's words

> "The architecture is internally consistent. The biggest determinant of legal posture is less the software mechanics than the economic reality and public messaging. If the platform consistently behaves like software that coordinates independent organizations, executes predetermined contractual distributions, and sells consumable compute rather than investment opportunities, the design is on substantially stronger footing across all three major areas: securities, money transmission, and FTC scrutiny."

That sentence is the track's organizing principle: the software is largely already right; what the law watches is **how the money actually behaves and what we say in public**. Most of the rules below are therefore messaging and build constraints, not redesigns.

## 2. Resolutions in force — in priority order

Priority reflects exposure, not sequence of work: securities is the highest existential risk; money transmission determines how funds can move; organizer compensation must sit unquestionably on the "real product" side of the FTC line; worker classification already aligns well with independent-contractor principles; trust accounting is isolated to legal-service dunas; insurance is future-facing and specialized; recusal is largely a governance drafting exercise.

### Priority 1 · Securities — the founding round

The structure is defensible; **messaging is where projects fail.** Compute is described everywhere, always, as **"prepaid usage credits that power intelligent agents"** — everything reinforces consumption. Binding vocabulary, all public surfaces: never *investment, appreciation, ROI, passive income, "buy before the price goes up," early investors, financial upside*; always *compute, usage, consumption, operating credits, intelligence, platform resources*. Founder status, discounts, recognition, and governance rights are all fine — but Founder is **recognition only** (the 1,000-member cap, plus benefits like gifts and swag), and nothing may ever imply Founder status exists because an asset will appreciate.

### Priority 2 · Money transmission

The highest-risk issue after securities, and the defense is the architecture itself: **the platform never exercises discretion — it executes pre-authorized settlement instructions** (marketplace-payout software, not a remitter). Build requirements now binding: payment instructions are fixed before money arrives · the platform cannot redirect funds · cannot hold funds for later decisions · cannot arbitrarily reverse distributions · Stripe (later Sphere) remains the regulated money mover. The more the platform looks like workflow software instead of a financial intermediary, the better — that sentence is now a design test.

### Priority 3 · Organizer compensation

Stronger than many affiliate systems, because commissions attach only to Compute purchases, never to enrollment. Helped: Compute is genuinely consumed. Watched: everyone necessarily makes an initial purchase — whether to limit or reduce initial-purchase commissions stays open on the list (L-14). Binding now: commissions **only** on Compute purchases; none on membership as such, governance, work income, treasury distributions, or recruiting Organizers. Messaging: Organizers introduce people to a product they actually use — never to an income opportunity — and **earnings claims are prohibited unless backed by actual statistics.**

### Priority 4 · Worker classification

The current approach is confirmed correct: 1099 treatment, one classification everywhere (never varied duna to duna). The strong facts to preserve: members choose their engagements, hours, methods, and equipment; work across many dunas; are paid by contract for deliverables. The platform states plainly that **every engagement is an independent commercial agreement between the member and the organization.** Never introduce: mandatory schedules, performance reviews, employment titles, required exclusivity, mandatory training, or supervision over how work is performed. Build requirements: W-9 before first payout; W-8BEN / W-8BEN-E for foreign members; automated 1099 reporting; state reporting where required.

### Priority 5 · Trust accounting — law-practice dunas

**Trust money is radioactive; the automation refuses to touch it.** The pipeline: Client Trust Account (IOLTA) → matter ledger → disbursement authorization → operating treasury → automated member splits. The platform never splits money sitting in trust; only released, earned fees enter the operating treasury, and only then do automated splits run.

### Priority 6 · Insurance — Lui Mutual

Never marketed as insurance until licensed; never imply guaranteed coverage. The staged path: **Phase 1** — community, education, risk analysis, reserve building, emergency grants, mutual aid; **Phase 2** — limited benefit programs where permitted; **Phase 3** — a licensed mutual insurer. Regulators care about what is promised, not what it's called.

### Priority 7 · Recusal — generalized to conflict of interest

Counsel endorses the Institution-recusal rule and extends it: **a general conflict-of-interest policy**, automatically recusing members from votes where they hold a financial, organizational, employment, family, or significant contractual interest — enforced by the software, exactly as Institution recusal already is — with permanent disclosure of Institution affiliations, Organizer relationships, and paid engagements relevant to proposals. The direction is adopted; the policy drafting and the spec fold into [Protocol](protocol.html) and [Foundation](foundation.html) are on the list (L-13).

## 3. The open work

New matters, stubbed on the [list](legal-items-for-review.html) and gathering requirements: **Terms of Service** for the websites and apps (L-8) · **Privacy** for the websites and apps, built on the four access levels (L-9) · **licensing of Kiduna Club IP by dunas** — minimum monthly payments plus a percentage of Compute sales (L-10) · **fiscal sponsorship by the Kinship Intelligence Institute** — a standardized application and agreement, with Service Alliance, Mycelial Aid, and BiHome/Inner Clinic first (L-11) · **patents** — updating the Kiduna/Kinship provisional and filing a new provisional for the new inventions (L-12).

## 4. Status

Everything in §2 operates now as adopted posture. Before launch, this track gets one end-to-end review with counsel (L-15); the [list](legal-items-for-review.html) is the single place to see what is open, what is resolved, and what changed. Counsel's full responses are on file (not published here); the questions they answer are in the brief of 2026-07-09.

---

*Changes in v4.8: track created — the seven counsel resolutions adopted in priority order; five new matters stubbed; the legal queue split onto its own list. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: institutions.md ===== -->

# The Institutions

**Track 10 of 11 · the outside entities with standing inside · v5.0**

Institutions are how the outside world holds an account: registered outside entities that can contract, fund, and enroll — but never vote. The mechanics live in [Protocol §2](protocol.html) and [Roles §1](roles.html); this track names the institutions that exist now and what each one is *for*, because the first three aren't incidental partners — they are the launch's legal and operational scaffolding.

---

## 1. What an Institution is (recap)

**A special type of Alliance, outside the hierarchy** ([Foundation §2](foundation.html)): it restricts membership and pays for/sponsors accounts, and it is always tied to a registered legal entity that is not a DUNA (in some jurisdiction; otherwise treated as a general partnership or sole proprietorship). Created by a member: **$1K Compute purchase · a Squads wallet · up to 10 enrolled members** whose Compute it may fund on an ongoing basis · contracts with members, allies, alliances, and organizations · **no vote, ever.** Two safeguards attach to enrollment: enrolled members cannot vote on their Institution's contracts (structural recusal, refused at the vote command), and enrollment is always disclosed as part of identity. Both are being generalized into a full conflict-of-interest policy ([Legal](legal.html), L-13).

## 2. The three institutions, now

| Institution | Home | What it is, and what it does here |
|---|---|---|
| **Kinship Intelligence Institute (KII)** | [kinship.institute](https://kinship.institute) | The 501(c)(3) — the research and alignment home (the HEARTS lineage behind [the Sentinel](sentinel.html)), and the **fiscal sponsor** for charitable-purpose dunas: a standardized application and sponsorship agreement ([Legal, L-11](legal-items-for-review.html)), with **Service Alliance, Mycelial Aid, and BiHome/Inner Clinic** first. |
| **Kinship Systems** | [kinship.systems](https://kinship.systems) | The technology company — builds and operates the platform's software under contract with Kinship Duna. |
| **Kiduna Club** | [kinship.club](https://kinship.club) | The IP holder — the marks and the patent-pending technology, **licensed to dunas** on standardized terms: minimum monthly payments plus a percentage of Compute sales ([Legal, L-10](legal-items-for-review.html)). Kiduna Club is also where the launch cohort begins (§3). |

| **Kinship Agents DAO, LLC** | — | The protocol steward — **maintains and manages the Kinship Agency Protocol (KAP)** ([Protocol §1a](protocol.html)): the specifications connecting Agency Servers to each other and to Agency Clients, and the Apache 2.0 releases they ride on. |
| **Lightbrush LLC** | — | **The first integration partner** — Moe's creative agent stack (Dowbot, the public-facing character agent; Zhowbot, the swarm manager; Digital Dolly, the digital-art agent; RenderDeck, the production system; audio mastering and game-content tooling) integrating into [The Ceremony Machine](organizations.html). Elias serves as forward-deployed engineer at no cost to Lightbrush; all Lightbrush tools remain Lightbrush's IP ([the agreement](legal-items-for-review.html), L-16). |

Potential partner: **Circle.**

## 3. Where the launch begins

**The launch cohort — every named Catalyst and Luminary ([Roles §1](roles.html)) — starts within Kiduna Club**: invited there, onboarded there, organizing there, while their own organizations take the standard path (an Alliance first, elevated to Organization when the WV Org ID validates). Their catalyst or luminary seat is in one duna; their participation is never limited to it — roles are per-duna, membership is everywhere.

## 4. The relationships to keep clean

Three institutions, three different relationships to the same platform: KII holds *purpose* (charitable sponsorship, research), Kinship Systems holds *labor* (build and operations contracts), Kiduna Club holds *property* (IP licenses). Keeping the three legible and separately contracted is deliberate — it is what lets any duna, and any regulator, see exactly which entity answers for what. The contracts themselves are legal work in flight: [L-10 and L-11](legal-items-for-review.html).

---

*Changes in v5.2: Institutions redefined as a special type of Alliance outside the hierarchy; Kinship Agents DAO, LLC added as KAP steward; Lightbrush LLC added as the first integration partner. v5.0: track created — KII, Kinship Systems, and Kiduna Club named with their homes and functions; the launch cohort's Kiduna Club start recorded. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: integrations.md ===== -->

# The Integrations

**Track 11 of 11 · inward and outward — MCP, APIs, plug-ins, and building on Kiduna · v5.6**

Integration runs in two directions, and this track holds both: **inward** — the MCP servers, APIs, and local agents we connect to, so allies can act in the world; and **outward** — our own API and MCP server, so anyone can build on us. The permission model for both directions already exists: the Tool node, grants, and the four access levels ([Foundation](foundation.html)), checked by the graph service on every call. Nothing in this track invents new access; it plugs new parties into the access that exists.

---

## 1. Inward — what we connect to

**MCP servers, attached in [Studio](surfaces.html), scoped to containers.** A member (or a Builder acting for an organization) connects an MCP server and attaches it to a specific relationship, guild, alliance, or organization — the container is the scope. A scheduling server attached to an alliance serves that alliance's work and nothing else; a payments tool attached to an organization acts only inside its treasury rules. The running list of interesting servers is maintained as wisdom (a living, curated inventory by category — payments and commerce, calendars and scheduling, docs and storage, social and messaging, web and search, creative tooling, dev tools) rather than frozen in this spec.

**Local agents on the member's own machine — the package protocol.** Studio interoperates with **Claude Cowork / Claude Code and OpenAI Codex** running locally over a defined **package-passing protocol**, modeled on the dispatch protocol we run between our own sessions: Studio hands out a self-describing package (context, the ask, constraints, where to return), the coding agent works it in its own environment, and the result returns as a package Studio unpacks into the graph — the exchange recorded like any other work. The member's machine stays theirs; the ally coordinates, it doesn't colonize.

**The first Institution integration: Lightbrush.** The working pattern for bringing an outside stack in ([Institutions](institutions.html)): Lightbrush LLC's creative agents and tooling (Dowbot, Zhowbot, Digital Dolly, RenderDeck, the audio system) integrate into The Ceremony Machine with Elias as forward-deployed engineer — Lightbrush's IP stays Lightbrush's, the integration work is ours, and usage-based distributions flow from the duna's treasury per its recorded configuration. Every future Institution integration should be recognizable from this shape.

**Channels are integrations too.** Telegram, Bluesky, email, the browser ([Express](surfaces.html)) — one system presence per channel ([Orchestration §3](orchestration.html)), thin adapters, identity and permission held in the middle tier.

## 2. Outward — building on Kiduna

**Our own API and our own MCP server.** Every action the system can perform is already a registered graph command ([Actions](actions.html)); the outward surface exposes those commands as an API and as MCP tools — so Claude Code, Codex, and any MCP-capable client can operate the parts of Kiduna a member grants them. New apps, new websites, new tools, or just more features: all of it builds against the same commands the first-party products use.

**No privileged path.** Outside callers are permission-checked by the graph service exactly like internal ones: the four levels, the grants, instructions-only-from-your-own-member, structural recusal, the receipt rule — all of it holds whether the caller is our Flutter app or someone's weekend project. The one account everything needs is [kidunaverse.com](surfaces.html): third-party apps authenticate against it, and their actions trace in the same audit trail the protocol browser walks.

**Creators and Builders open doors deliberately.** Opening part of Kiduna to an outside tool is a grant like any other — scoped, stated, revocable in one sentence, and disclosed where it acts.

## 3. The rule that keeps it safe

One sentence, both directions: **an integration is a tool under grants, never a party with standing.** It cannot vote, cannot hold sovereignty, cannot receive instruction-weight from anyone but the member who granted it, and everything it does is traced. If a proposed integration can't live inside that sentence, it isn't an integration — it's a membership question, and those go through [Roles](roles.html) and [Protocol](protocol.html).

## 8. The outward stack, specified — the API, the MCP server, and the plug-ins · 2026-07-14

The outward direction now has its build specification. The organizing principle, adopted as-is: **the Kiduna MCP server is the platform product; the Codex and Claude plug-ins are elegant clients of it.** Business logic never lives in markdown files; every agent client gets the same permission and audit model; Kiduna becomes infrastructure for agentic organizations, not a bundle of prompts.

**The pieces.** The **Kiduna API** (at **api.kiduna.ai**) is the platform and source of truth. The **MCP server**, hosted at **mcp.kiduna.ai/mcp** as a remote HTTP server with OAuth, is the secure, agent-friendly access layer — the open interoperability surface Codex, Claude Code, ChatGPT, and future agent clients all speak. **Skills** are reusable workflow instructions; **commands** are explicit shortcuts (`/kiduna:status`); **agents** are specialists for delegated jobs; **hooks** are sparse automatic safety checks; **plugin manifests** are packaging.

### The MCP server

Purpose-built tools only — never generic database access, never a broad `execute_action`. Six families:

- **Identity and authority** — `get_my_identity` · `get_effective_permissions` · `list_my_delegations` · `preview_delegation` · `grant_delegation` · `revoke_delegation` · `list_agent_activity`
- **People and relationships** — `search_people_and_agents` · `get_profile` · `list_connections` · `request_connection` · `request_introduction` · `list_invitations` (results respect privacy and relationship visibility)
- **Groups and organizations** — `list_my_organizations` · `get_organization_context` · `create_working_group` · `invite_member` · `change_member_role` · `list_members` · `get_governance_rules`
- **Initiatives and coordination** — `list_initiatives` · `create_initiative` · `get_initiative_context` · `create_task` · `assign_task` · `update_task` · `post_update` · `propose_action` · `record_decision`
- **Decisions and governance** — `create_proposal` · `list_open_proposals` · `preview_vote` · `cast_vote` · `record_consent` · `get_decision_history`
- **Notifications and auditability** — `list_notifications` · `mark_notification_read` · `get_audit_events` · `explain_action_authority`

Every agent action must answer: who is acting · on whose behalf · within which organization · under what mandate · with which permissions · when that authority expires. **A Kiduna agent never inherits every permission its human possesses.** Every write returns an audit ID, acting identity, organization, timestamp, and the authority used. Financial, membership, publishing, voting, and irreversible actions require explicit confirmation — the preview/commit separation, exactly the ACTIONS grammar the Field already speaks.

### Authentication and safeguards

OAuth 2.1 with authorization code + PKCE for people; client credentials only for explicitly registered service agents. Granular scopes (`identity:read` · `profile:read` · `relationships:read/write` · `organizations:read/write` · `initiatives:read/write` · `decisions:read/write` · `delegations:read/write` · `audit:read`). Binding safeguards: short-lived access tokens with rotating refresh · organization- and resource-level authorization on every tool call · no tokens in the plugin repo, no token passthrough downstream · idempotency keys on writes · rate limits per person, agent, organization, and installation · immutable audit events · strict tenant isolation · minimal, paginated responses. Each tool declares honest MCP annotations (`readOnlyHint` · `destructiveHint` · `idempotentHint` · `openWorldHint`) — hints for client approval UX, never substitutes for server-side authorization.

### One repository, two native plug-in packages

A monorepo (`kiduna-agent-plugins/`) with a common core and thin platform adapters: `.codex-plugin/plugin.json` and `.claude-plugin/plugin.json` manifests, both marketplaces, `.mcp.json`, `.app.json` reserved for the hosted ChatGPT integration, and shared `skills/` (SKILL.md is the open, portable format) with platform-generated `commands/`, `agents/`, and `hooks/` — plus `packages/mcp-server`, `packages/api-client`, `packages/schemas`. Skills shared verbatim; commands, agents, and hooks generated from shared source into each platform's schema.

**The first eight skills** (most important journeys, not thirty): `kiduna-get-oriented` · `kiduna-find-collaborators` · `kiduna-form-a-group` · `kiduna-launch-an-initiative` · `kiduna-run-a-decision` · `kiduna-coordinate-work` · `kiduna-delegate-to-an-agent` · `kiduna-audit-agent-activity`. A second plug-in, `kiduna-developer`, later teaches coding agents to build on Kiduna.

**Specialists, after the workflows are stable:** Kinship Mapper (relationships and collaborators) · Organization Steward (groups, roles, governance) · Initiative Coordinator (plans, tasks, decisions) · Authority Auditor (delegations and agent activity). Agents orchestrate skills and MCP tools — they never carry secret capabilities the MCP permission system doesn't grant.

**Commands:** `/kiduna:status` · `/kiduna:people` · `/kiduna:form-group` · `/kiduna:launch` · `/kiduna:decide` · `/kiduna:delegate` · `/kiduna:audit` — skills stay usable without them.

**Hooks, sparse and predictable** (the Vercel lesson — lightweight session-start, never inject-everything-every-turn): SessionStart (is this repo connected to a Kiduna organization or initiative? short status) · PreToolUse (block or warn on a Kiduna write without a clear organization or mandate) · PostToolUse (record a local audit reference) · Stop (remind about unpublished changes or unfinished delegated work). Retrieve context on demand; shared hook scripts, separate per-platform hook configs.

### Build order and alignment

The sequence: identity/organization/delegation/audit models → authenticated API → read-only remote MCP → OAuth + scopes → small set of safe write tools with preview/commit → shared SKILL.md workflows → the two manifests → platform commands/agents/minimal hooks → fixtures and MCP contract tests → local testing → a private Kiduna marketplace for early users → real usage → the OpenAI and Anthropic public directories (production branding, support/privacy/terms, accurate annotations, starter prompts, five positive + three negative test cases).

Alignment with the operating graph: the MCP server is an **ecosystem client of the Graph Command Service, never a second policy boundary** — "delegations" in MCP vocabulary are the graph's grants and mandates; every write lands as a typed ActionRequest and returns the Record's audit reference. The **kiduna.md** convention (companion to CLAUDE.md and AGENTS.md) lets packages carry network-validatable codes so Claude, OpenAI, and other clients can verify provenance over the network — a trusted loop, open but verifiable.

---

*Changes in v5.6: the outward stack specified — API at api.kiduna.ai, the remote MCP server at mcp.kiduna.ai, the two-platform plug-in monorepo, first eight skills, safeguards, and the build order (from the plug-in architecture brief, 2026-07-14). v5.2: the Studio↔Claude Code/Codex package-passing protocol specified; Lightbrush recorded as the first Institution integration. v5.0: track created. Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: design-method.md ===== -->

# The Design Method

**How Kiduna designs get worked · adopted 2026-07-22 · so it never needs restating**

Design work runs as **a series of prompts, executed step by step, one screen or flow at a time** — written so any AI collaborator (Claude Code, Codex, or another) can execute them without house context. This page is the standing method; the current prompt package lives in [design-prompts/](design-prompts/DESIGN-PROMPTS-2026-07-22.md). **The product foundation every Studio and Live design works from is the [Studio + Live Working Design Brief](studio-live-brief.html)** — the shared product model, surface responsibilities, non-negotiable principles, and the KDN decision log. It does not define screens; it defines what screens must honor.

**The rules of the method:**

1. **Every prompt package is a self-executing operating order**: README.md, AGENTS.md, CLAUDE.md, and 00_START_HERE.md all carry the same imperative — you are executing, not reviewing; begin Prompt 1 immediately; the only acceptable first question is a missing file — and PASTE-THIS.txt holds the kickoff line the human pastes with the zip (chat tools read nothing until told). Also: a CANON-BRIEF.md carrying the controlling vocabulary travels with the prompts; the live design system (kiduna-studio-enamel.motodave.chatgpt.site) and the current-screens zip are referenced explicitly; the Kiduna Kit is the deep reference. Never assume the collaborator knows anything.
2. **Prompts are separated and ordered.** One prompt per session. Later prompts consume earlier deliverables (the persona bible feeds every screen). Each prompt names its deliverables as files, versioned — never loose output in chat.
3. **The general design system is settled** — inside the Field and outside. Prompts fine-tune screens toward buildable precision; they do not restyle. Espresso ground, Avenir body, Goudy display, sky interactions, restrained mint, gold only for Deliberate acts.
4. **The four Personas are permanent**: Alice, Bob, Carol, Danny (lineage: Alice→Bob, Carol→Danny), with durable backstories, Code Names, conversational styles with Ki, invite trees, and Resources profiles. All screens are developed against them; background characters may vary, the four do not. Every important workflow is evaluated against all four patterns: Alice inspects before acting; Bob talks before summarizing; Carol explores before confirming an exact version; Danny prepares, verifies, and then commits ([the brief §6](studio-live-brief.html) carries their full commitments and failure risks).
5. **Vocabulary is canonical or it's a question.** The taxonomy governs; new words go back to Moto, never into a mock.
6. **Moto reviews each prompt's output before the next runs** — same markup loop as the spec process (brackets in, folded, versioned).
7. **Results feed the kit**: accepted design outputs and their fixtures enter the Kiduna Kit so engineering, design, and canon never diverge; every design turn ends with "Taxonomy updated" or "No taxonomy change," per the taxonomy impact rule.

**The Studio UI system is Enamel** (v0.5, 2026-07-22) — the controlling visual canon for Studio: a three-layer world where **the Field is lacquer** (near-black deep umber, engraved arcs, no atmospheric gradients), **Realms are celestial enamel vessels** (warm metal rims, dark cores, one semantic type hue, inlaid geometric crests, localized halos, labels that travel), and **Allies are people** — stable identities across four contextual moods (Open · Engaged · Focused · Dreaming), with camel + moon-cream identity rings and no permanent prominence advantage. Material rules: enamel deep and tactile; highlights moon cream; wire and rims camel and sun gold; dimension from material hierarchy, never glossy 3D. The recomposable system: [emblems](enamel/06-EMBLEM-SYSTEM.md) · [connection grammar](enamel/07-CONNECTION-GRAMMAR.md) · [talismans](enamel/08-TALISMAN-SYSTEM.md) · [background geometry](enamel/09-BACKGROUND-GEOMETRY.md), with [tokens](enamel/STUDIO-ENAMEL-TOKENS.css) and an [acceptance checklist](enamel/05-ACCEPTANCE-CHECKLIST.md). The full canon docs are [on this site](enamel/01-STUDIO-ENAMEL-CANON.md); the complete packs (Enamel v0.5 with its working website, and the broader Kiduna Design System with fonts, allies, icons, talismans, crests, and realm emblems) are in [downloads](downloads/Kiduna-Studio-Enamel-v0.5-Complete-2026-07-22.zip) ([design system](downloads/Kiduna-Design-System-2026-07-26.zip)). The design system itself was refreshed 2026-07-26 — the same system, extended: the full brand + Studio + Live token set and preview cards (Ally medallions, Realm emblems, connection grammar, talismans, Field ground, Ki panel, Live glyphs/mobile/tablet), the allies generation system, deck templates, and the business card — installed sitewide in `_ds/`.

The sibling method for specifications is the [spec-design process](dunaversity/SPEC-DESIGN-PROCESS-SKILL.md). Together they are how we build from within.

---

<!-- ===== SOURCE: architecture.md ===== -->

# Architecture

**The complete architecture, and how to hold it in your head · updated 2026-08-01**

> **The product shape is now [Taxonomy v1.3.8](taxonomy.html)** — eight Scenes across four Surfaces, seven Elements, six Capacities, the economic rails (real FROST/Squads wallets, orchestration-run economy, $KIDUNA-unified liquidity at launch), and Themes in the Graph. The **[Initial Release Functional Specification](initial-release-functional-spec.html)** is the complete functional scope, and commissions the next revision of this page: the current, end-to-end architecture document of the complete stack — front end, middle tier and orchestration, back end, per Surface and Scene. Where the spec of record below conflicts with v1.3.8 on product shape, v1.3.8 governs; the command boundary and its invariants are untouched.

**The vocabulary comes first: [The Core Taxonomy](taxonomy.html)** — the primary elements rebuilt 2026-07-17 (Principals, privacy-for-a-principal, the three engines + Artifacts, Abilities, trust default-low, deterministic Actions, roles, Compute with the Agency Premium). Read it before anything else on this page; where older pages disagree, the taxonomy wins. **The operating graph is specified here: [Kinship Graph Architecture v1.1](kinship-graph-architecture-v1.1.html)** ([PDF](downloads/Kinship-Graph-Architecture-v1.1.pdf)) — ratified 2026-07-14 (v1.1: the Persona · Visitor · Guest · Member vocabulary, the invitation lifecycle, twelve owner ratifications); Personas, Allies, Organizations, and Actions at the center; the Graph Command Service as the one deterministic boundary; Forums replacing Markets; Actions as a subgraph; one PostgreSQL transaction boundary; the August 10, 2026 build target. It replaces the earlier [Kinship Graph Workflow](kinship-graph-flow.html) and closes its [canon gaps](kinship-graph-gaps.html) — both preserved as history. **The technical white paper is here: [Kiduna: A New Architecture for the Agentic Internet (White Paper v0.1)](kiduna-new-architecture-agentic-internet-white-paper-v0.1.html)** — the argument and the design, whole. **The complete architecture is here: [Kiduna: A New Architecture for the Agentic Internet — Product & Engineering Specification v0.1](kiduna-agentic-internet-spec-v0.1.html).** It is the spec of record for the build — executive decisions, the products and surfaces, the domain model, creating the first Ecosystem, Allies and Actors and the first cast, the creation system, the Field and contextual HUD, Studio, Live, protocol and system architecture, trust/privacy/safety/custody, the development plan, acceptance and operations, and the canon objections with owner decisions. Read it front to back if you're building.

**Delta of 2026-07-14** (recorded in the [canon delta](skill-updates/cofounder-canon-2026-07-14.md), folds into the spec next revision): the Genesis bootstrap order — Genesis Ecosystem → Genesis Ally **Ki** ("Kinship Intelligence"; everyone's first conversation, effectively the initial interface) → the **Mage** account → Genesis Codes; **kiduna.ai** as the authoritative registration/wallet/launchpad home (third key share lives there; API moves to **api.kiduna.ai**); member-facing trust grammar — trust **High/Medium/Low** per Relationship side, authority = registered-with-whom (DUNA registry · KYC · DNS TXT · AT Protocol DID), privacy = the four levels; person-specific single-use 15-minute invitation codes, generalized codes default-untrusted, and the zero-spam law (the system never contacts the unregistered); the Allow-once/Allow-every-time permission grammar; the outward stack on [Integrations §8](integrations.html).

What follows on this page is the short version — the shape of the thing so anyone joining can hold it before diving in. Earlier reference: the [Protocol + Stack Architecture v1.0 (PDF)](downloads/Kiduna-Protocol-and-Stack-Architecture-v1.0.pdf). The spec tracks behind everything: [Foundation](foundation.html), [Orchestration](orchestration.html), [Protocol](protocol.html), [Integrations](integrations.html).

---

## 1. The one rule everything hangs on

**The graph service is the sole policy and command boundary.** Models, personas, surfaces, channel adapters, and integrations never authorize themselves. That's the whole trick of building with probabilistic agents: the intelligence proposes, deterministic code authorizes and commits. An ally can be brilliant, persuasive, or wrong — it makes no difference to what it's *allowed* to do, because permission is checked in one place, on every read, write, and tool call, and that place can't be sweet-talked.

## 2. The six layers

Top to bottom: **Surfaces** (the four form factors, entered through the official homes — the app · One · Live · Express · Studio · the account — they render experience and collect human intent and signatures; they never decide authorization) → **KAP edge** (the protocol connecting clients and servers: identity, requests, receipts, registrations; thin channel adapters; the API/MCP edge) → **Orchestration** (one agent system: Ki's personas, Allies and Actors, LangGraph, context assembly) → **Graph service** (identity, access, grants, codes, roles, policies, conflicts, named commands, receipts — the authoritative boundary) → **Data** (the graph, pgvector for meaning, plain Postgres for accounts, Records for what happened) → **Protocol + rails** (the decentralized registry, FROST wallets, ally NFTs, Squads, Forums, USDC and Compute).

## 3. The invariants (the short version)

One policy boundary. Instruction comes only from the Source. Context is shared; authority is not. Four access levels, everywhere — and personal is never grantable. Vectors are meaning, never authority. Named commands, not raw CRUD. Receipts cannot lie — the sentence members read is generated from the exact parameters that execute. Minimal chain: on-chain only where legal accountability requires traceability. Registered proves traceability, not virtue. Simulations are structurally incapable of touching real rails. Integrations are tools under grants, never parties with standing.

## 4. How a command runs

Intent → Resolve (who's asking, as whom, where) → Authorize (level, grants, codes, role) → Validate (policy, state, recusal) → Execute (one named atomic command) → Record (receipt, provenance, trace). No prompt, persona, adapter, or integration can bypass the middle four steps. Reads are permission-scoped and side-effect-free; acts change state and leave a Record; settlement happens on web or chain rails and returns a verifiable reference.

## 5. Identity, in one chain

Member FROST wallet → Ally NFT inside it → Alliance or Organization Squads wallet → registered DUNA → WV Secretary of State Org ID. Kinship Codes carry those addresses as signed JWT claims, so the chain travels over ordinary email, web, and messaging. Members see **registered** (with its trace) or **unregistered — a stranger, not a threat** — never "trusted" as a verdict.

## 6. Ecosystems and KAP

One installed server-side stack is an **ecosystem**, created from a Genesis Profile. The Genesis Ecosystem is Kiduna; other ecosystems are peers, never subordinates, interoperating over **KAP** — which must preserve the same identity, authority, access, command, receipt, and trace semantics across every implementation. The stack ships Apache 2.0; the marks stay licensed.

## 7. What's decided and what's still open

The baseline marks its own gaps honestly: the graph engine selection (in-house model, Apache AGE named as candidate), the Code JWT profile and revocation transport, async settlement/retry/reconciliation design before financial commands ship, service boundaries and cloud topology. The build sequence runs contracts-first (freeze IDs, enums, schemas, receipts), then hardening the graph service as the only boundary, then data plane, identity chain, the command loop, orchestration, surfaces, the Sentinel (observe-only first), and finally proving federation with a second ecosystem. Release gates include: no protected object is ever retrieved-then-filtered; **secret exists end-to-end before code-gated content ships**; no non-Source message ever becomes an instruction.

---

*2026-08-01: re-pointed to [Taxonomy v1.3.8](taxonomy.html) as the governing product shape (eight Scenes, four Surfaces, seven Elements, six Capacities, the internal ledger, Themes), and the next revision of this page commissioned as the end-to-end architecture document of the complete stack — the ask is stated in the [Initial Release Functional Specification](initial-release-functional-spec.html) §0. 2026-07-11: the complete architecture installed — [the Agentic Internet Specification v0.1](kiduna-agentic-internet-spec-v0.1.html), the spec of record. Earlier references preserved: the [Protocol + Stack v1.0 PDF](downloads/Kiduna-Protocol-and-Stack-Architecture-v1.0.pdf) and [Kiduna-Architecture](kiduna-architecture.html). Full history: [versions](versions/index.html).*

---

<!-- ===== SOURCE: kinship-graph-architecture-v1.1.md ===== -->

# Kinship Graph Architecture v1.1

## The operating graph for the agentic internet

Engineering specification and replacement for "Kinship Graph Workflow"

Status: Ratified build specification for the August 10, 2026 initial release and the architecture beyond it  
Version: 1.1  
Date: July 14, 2026  
Authority: v1.0 plus the July 14 Techneural architecture sync, the Agentic Internet graph update, and the twelve product-owner ratifications incorporated in this revision

> The Kinship Graph is not primarily a question-answering knowledge graph. It is the authoritative operating context for accountable agency. Personas sense and decide through Allies; Members govern the Organizations they have legally joined; Allies coordinate Actors; typed Actions change the state of Projects and Organizations; deterministic code decides what is permitted; Records prove what happened.

Revision 1.1 replaces the network-wide use of **Member**. **Visitor** means an unauthenticated or unidentified person. **Guest** means an authenticated Persona who has not been admitted as a Member of the Organization in context. **Member** means a Persona with an active, legally effective Membership in that Organization. **Persona** is the generic human-facing term when the exact state is irrelevant or varies by Organization.

## Executive decisions

This specification makes the following implementation decisions.

1. **Replace the old center of gravity.** The graph is organized around **Personas, Allies, Organizations, and Actions**, with Memberships, Projects, Relationships, Communities, Alliances, Forums, Wisdom, Institutions, and Records as first-class supporting concepts. "Users, agents, and markets" is too generic and directs engineers toward an AI retrieval product rather than an operating system for coordinated work.
2. **Reserve Member for legal Organization membership.** Product and schema use Visitor for an unidentified person, Guest for an authenticated Persona without active Membership in the Organization in context, and Member only after admission under that Organization's terms. A Persona may be a Member of one Organization and a Guest of another. `Membership` is the authority-bearing object; account creation or payment alone never creates it.
3. **Use Persona as the generic principal.** `Persona` is the durable human identity behind an Account and the Source of an Ally. Builder, creator, founder, Catalyst, luminary, designee, and Curator are roles; they do not replace Persona, Guest, or Member.
4. **Make the Organization the accountability context of every Action.** Every Action must resolve to exactly one `organization_id`. When no Organization is supplied, only the explicit Guest/Public allowlist may default to Kinship Duna, with `context_defaulted=true` recorded. Defaulting context never creates Membership or authority.
5. **Treat DUNA as a legal-form adapter, not the universal ontology.** `Organization` is the system object. West Virginia DUNA is the first `LegalForm` and `LegalRegistration` adapter. This allows other jurisdictions and entity forms later without reworking the graph.
6. **Replace Market with Forum.** An Organization can have several Forums. A Forum is a governed decision space that can include debate, optional decision-market signals, and the signed enactment process. The old one-DUNA-to-one-Market `BECAME` relationship is removed.
7. **Model two agent families.** Every authenticated Persona has exactly one Ally identity; every non-Ally agent is an Actor. Sentinel, Envoy, Operator, Profiler, CodeManager, research agent, registrar, intake agent, and domain-specific agents are typed Actor kinds. Implementation workers such as queue consumers are services, not social agents.
8. **Model Actions as a subgraph, not as an edge.** `ActionDefinition`, `ActionRequest`, `AuthorizationDecision`, `Command`, `ActionRun`, `ExternalOperation`, and `Record` are distinct. Edges express who requested, authorized, performed, received, and was affected. This is the minimum structure that preserves intent, permission, retries, confirmation, governance, settlement, and provenance.
9. **Keep one deterministic boundary.** The Graph Command Service is the only component allowed to authorize or commit protected reads and changes. Models propose. The service resolves identity and context, evaluates policy, validates state, commits local changes, starts external operations, and appends Records.
10. **Promote Projects and work to the launch core.** The graph must support engagements, work items, deliverables, milestones, agreements, split rules, invoices, credentials, and domain resources. Retrieval and conversational answers are supporting capabilities, not the product's center.
11. **Rename and normalize agent configuration.** Inform/Wisdom, Instruct/Stance, Empower/Connection, Enable/Automation, and Impart/Skill are explicit configuration relationships. A Wisdom Drop is a permissioned namespace containing Items and vector chunks.
12. **Make money auditable but do not use the graph as an accounting ledger.** The graph models economic relationships and links to purchases, allocations, accounts, and settlements. Amounts and balances are enforced by an immutable double-entry ledger in PostgreSQL; on-chain state and regulated rails remain authoritative for their own settlement.
13. **Make the graph authoritative current state, not a loose projection of three databases.** The Graph Command Service updates typed graph state, command/record tables, ledger references, and a transactional outbox in one PostgreSQL transaction. External state is reconciled by idempotent workers. There is no uncontrolled multi-database dual write.
14. **Launch as a modular monolith with workers.** Use one tested PostgreSQL plus Apache AGE and pgvector deployment, one Graph Command Service, and isolated workers for orchestration, ingestion, outbox delivery, external reconciliation, and chain/payment adapters. Split services only at measured security or scaling boundaries.
15. **Implement the full ontology now, activate risky economics by policy and feature gate.** The schema supports Compute issuance, liquidity, lineage, launch campaigns, DEX settlement, market positions, Curator allocation, and Sponsor distribution. Transferable/DEX Compute, market positions, lineage payouts, Curator allocation, and Sponsor distribution are disabled at launch until legal, accounting, tax, custody, rail, and exchange reviews approve them.
16. **Separate legitimacy from prediction.** One eligible Member, one equal governance ballot determines Organization authority under its governing principles. A USDC-funded decision-market position is information only unless a later, explicit Organization policy delegates a narrowly specified advisory effect. It never silently becomes a vote.
17. **Publish a machine-readable command authority matrix.** Every `DomainCommand` declares one required authority class: Public, Guest, Member, Role, Policy, Forum, Treasury, GovernanceMarket, ExternalAgreement, or RegulatedCredential. The registry, not prose or model judgment, is authoritative.
18. **Keep protocol invariants hard and economic policy versioned.** Identity, principal types, Source precedence, command execution, and Records are stable protocol. Liquidity floors, pricing, waterfalls, allocations, and Organization economics are versioned policies. Regulated capabilities activate independently.
19. **Make every identity portable but homed.** Every Persona, Ally, Actor, Organization, Institution, and Ecosystem has a permanent protocol ID, a Home Ecosystem, and signed federation metadata. Migration changes the authoritative home without changing the permanent ID or erasing history.
20. **Bootstrap the network through a defined Genesis sequence.** The Kiduna Genesis Ecosystem, Genesis Ally Ki, and limited Mage account exist before the first invited Persona. Ki is immediately useful through a shared versioned AllyDefinition, while every Persona receives a segregated Ally identity, private state, alias/handle, and Source boundary.

## 1. Why the prior workflow cannot be the build specification

The original workflow contains useful engineering work: Apache AGE, anchored graph tools, hybrid vector plus graph retrieval, query guarding, audit logging, wallets, Kinship Codes, lineage, and provenance. These should be retained. The problem is the workflow's theory of the product.

### 1.1 It describes an assistant, not an agentic internet

Its main pipeline is: user asks a question, a supervisor model chooses one of seven retrieval tools, a Cypher query runs, and the model writes an answer. That pipeline is valid for a read operation, but it is only one small branch of the system. It does not answer the defining engineering questions:

- What consequence is the Persona trying to cause?
- Which Organization is responsible for the consequence?
- Is the Persona, Member, Ally, Actor, role, or Forum permitted to cause it?
- What human confirmation is required?
- Which deterministic command changes local state?
- Which external system must settle the effect?
- What happens when an external operation times out, partially succeeds, or is reversed?
- Which Record proves authorization and outcome?

The replacement pipeline is therefore: **prompt or trigger -> intent -> typed ActionRequest -> authority resolution -> policy decision -> confirmation or Forum -> command -> local commit -> external operation -> Record -> Field update**.

### 1.2 Its nouns encode the wrong system

`User` treats the human as an account. `Presence` treats the Ally as a created avatar. `Worker` makes agent architecture look like a supervisor tree. `Market` collapses an Organization's legal existence into one on-chain counterpart. `KnowledgeBase` hides ownership, permission, provenance, and the meaning of Wisdom. `Connection` erases the information-bearing Relationship. The model has no Project and almost no representation of real work.

The result is a graph optimized for answering "what do I own, who referred me, and what did I earn?" rather than for operating a law practice, solar installation, clinical service, mortgage workflow, game club, festival, research collaboration, or mutual insurer.

### 1.3 It confuses current state, evidence, and telemetry

The workflow proposes Event nodes for onboarding status and considers projecting every skill execution into the graph. Those are different kinds of data:

- **Current graph state** answers what is true and permitted now.
- **Records** prove consequential reads, decisions, signatures, commands, results, and settlements.
- **Internal events and telemetry** explain how software moved between states and how it performed.

Only current state and durable, persona-relevant Records belong in the operating graph. High-volume spans, model tokens, retries, queue leases, and low-level skill execution details belong in partitioned tables and observability storage, with graph links only when a durable consequence exists.

### 1.4 It makes the graph a derived reporting layer

The prior workflow says three relational databases remain sources of truth and the graph is their combined projection. That guarantees lag, duplicate identity, cross-database inconsistency, and ambiguous authorization. A permission decision cannot rely on an eventually synchronized copy.

The new rule is narrower and stronger: the Graph Command Service owns authoritative organizational state and authorization facts. Relational tables in the same PostgreSQL transaction own strict control-plane and ledger constraints. External rails own their settlements. Projections can be rebuilt from Records and events, but protected decisions never depend on a stale analytical graph.

### 1.5 It represents legal and economic relationships inaccurately

An Organization does not "become" a Market. It remains a real legal association and may operate several Forums. An Offering purchase does not pay lineage; only a Compute purchase can do so under the stated policy. An Institution is not a Persona with a larger subscription. It is an external legal principal that can enter agreements, sponsor Personas or Members, appear in lineage, and have progeny, but cannot acquire Membership or human sovereignty merely by paying.

### 1.6 What remains worth keeping

- Apache AGE as the selected graph engine, subject to version pinning and release testing.
- PostgreSQL and pgvector co-location for transactional graph, relational controls, and semantic retrieval.
- Stable named graph queries with bounded traversal, limits, and caller scope.
- Closure-bound or token-bound caller context as defense in depth.
- Graph query auditing and prevention of unbounded traversal.
- Wallet, Code, lineage, provenance, document/chunk/entity, and external-tool concepts after renaming and normalization.
- Hybrid retrieval: semantic candidates first, permission-safe graph expansion second.

![Figure 1. The revised operating architecture](figures/architecture-overview.png)

## 2. Constitutional invariants

These invariants are implementation tests. A release that violates any P0 invariant is not a partial success; it is the wrong system.

### 2.1 Authority

- An authenticated Persona is the only free-form Source of instructions to their Ally.
- Messages from any other Persona, Member, website, email, agent, Tool, or Ecosystem are context or a request, never binding instruction.
- A Visitor has no Ally and no durable authority. A Guest may use only the Public/Guest allowlist. Member authority exists only through an active Membership in the exact Organization in context.
- An Ally never self-authorizes, votes, signs, widens a grant, changes its own budget, or alters its own command allowlist.
- An Actor has only the reads, Tools, commands, budget, duration, and Organization contexts declared in its immutable versioned manifest.
- Every consequential Action resolves to one Organization and one authority class.
- Default deny applies when identity, context, policy, state, or authority is ambiguous.

### 2.2 Privacy and access

- Every protected resource has one of four access levels: public, private, secret, or personal.
- Personal is visible only to the owning Persona and their Ally and is never grantable.
- Secret is not discoverable through search, counts, errors, timing, cached Scenes, or federation.
- Private may be discoverable but is retrievable only under a valid grant, Code, agreement, or policy.
- Authorization occurs before graph retrieval and before vector retrieval. "Retrieve then filter" is forbidden.
- Credentials and raw secrets never live in graph properties, vector metadata, model prompts, or ordinary logs.

### 2.3 Actions and Records

- Language captures intent; it does not mutate state.
- Every mutation uses a registered named Command with a versioned parameter schema.
- Every command has an idempotency rule, authority class, preconditions, effects, receipt renderer, error taxonomy, and tests.
- Receipt language is generated from exact command parameters. No independent prose field may describe the consequence.
- A local transaction can be atomic; an external filing, payment, title transfer, email, chain transaction, or physical-world act is a saga with explicit pending and terminal states.
- Corrections supersede Records; they do not rewrite history.

### 2.4 Organizations and work

- Organization is jurisdiction-neutral. A DUNA is one verified legal form.
- Every Project has exactly one accountable Organization.
- Communities, Alliances, Relationships, and Projects exist in Organization context; Personas and agents may participate across many Organizations, but Member-only authority is always resolved from the active Membership for that Organization.
- Organizational status is derived from verified registration and lifecycle state, not a manually edited label.
- Engagement, Project, Alliance, and Institution are separate concepts even when linked.

### 2.5 Money and deciding

- Compute is described and recorded as prepaid usage credits that power intelligent agents.
- Only a completed Compute purchase can trigger a lineage/waterfall calculation. Offerings, work income, votes, grants, and treasury distributions cannot.
- Every waterfall calculation binds to the exact version of the WaterfallPolicy and a frozen lineage snapshot.
- Governance ballots and decision-market positions are separate objects. One eligible Member has one equal ballot. A USDC-funded position is a distinct information signal and must never silently become a wealth-weighted legal vote.
- Financial balances come from a double-entry ledger or verified external rail, not from summing graph edges.
- The platform submits pre-authorized instructions and reconciles results; it does not improvise where funds go.

### 2.6 Simulation and observability

- Simulation resources are structurally incapable of reaching real payment, chain, filing, messaging, or regulated Tools.
- Operational logs contain IDs, reason codes, versions, latency, cost, and error class, not raw personal prompts or secret content.
- No Persona receives a hidden global score, inferred reputation rank, productivity score, or behavioral rank. Directional trust declarations may exist on a Relationship, but they are not transitive authority and are never aggregated into a secret social score.

### 2.7 Identity, invitation, and trust

- A pre-registration invite never creates a Persona, Guest, Member, or Relationship. It creates a purpose-limited `InvitationProspect` and `RelationshipIntent` owned by the inviter.
- Claims about an invitee remain attributed to the inviter, expire under policy, and are not promoted into the invitee's Profile without review and consent.
- Person-specific first-entry Codes are single-use and expire after 15 minutes by default. Generalized Codes may use a different explicit expiry but default the recipient to untrusted and carry no prebuilt Profile.
- The platform never sends outbound communication to an unregistered Visitor. The inviter delivers the Code out of band. Registered Personas may receive signed in-system invitations.
- Trust is directional and scoped to a Relationship: low, medium, or high, with author, basis, visibility, and timestamp. It never grants command authority by itself.
- Registration/verification and trust are different. Verification states who or what vouched for an identity; trust states one principal's declared confidence in another.
- No trust level is public by default. A Persona may explicitly disclose their own directional declaration; the counterparty's declaration remains separately controlled.

## 3. Canonical vocabulary and object model

### 3.1 The four centers and human states

**Persona.** The durable human principal behind an Account. Persona is the generic term when Visitor/Guest/Member status is unknown, varies by Organization, or is irrelevant. An authenticated Persona is the Source of exactly one Ally identity across the network.

**Visitor.** An unauthenticated or unidentified person. A Visitor may use public reads and begin account creation but has no durable principal authority, Ally, Membership, wallet authority, or protected access.

**Guest.** An authenticated Persona who does not have an active Membership in the Organization in context. Guest authority is restricted to the explicit Guest command allowlist. For Kinship Duna at launch, a Guest may fund at least 10 USDC of Compute without becoming a Member.

**Member.** A Persona with an active, legally effective `Membership` in the Organization in context, admitted under that Organization's governing terms. A Persona may simultaneously be a Member of Kinship Duna and a Guest of another Organization. Payment is at most one admission precondition; it is never sufficient by itself.

**Ally.** The authenticated Persona's single agentic counterpart. The product presents the shared canonical Ally Ki, but the graph stores a separate `AllyIdentity` per Persona bound to one versioned `AllyDefinition`. This preserves the "one Ally" product experience without creating a cross-persona privacy or authorization singleton. Each Ally may have a Persona-selected display name and globally unique handle. It is personalized through Stance, Wisdom access, Connections, Automations, Skills, grants, and Organization context. It interprets, explains, proposes, coordinates, and delegates, but cannot cross the deterministic boundary on persuasion alone.

**Organization.** The accountability container in which Actions occur. At launch, the primary verified legal form is a West Virginia DUNA. An Organization has purpose, functions, members, agents, policies, Projects, Forums, accounts, Compute configuration, Wisdom, Stance, Connections, Automations, and Skills.

**Action.** A typed, consequence-bearing request and its accountable execution history. Actions are how Personas, Members, and Organizations communicate, create, collaborate, coordinate, build, decide, transact, and affect the world.

### 3.2 Supporting social and work objects

**Relationship.** A first-class node joining exactly two authenticated Personas in exactly one Organization context. The same two Personas can have different Relationships in different Organizations. Each side authors its own directional trust declaration, grants, and statements. Relationship existence does not imply Membership.

**Community.** Three or more Personas gathered around a purpose or sharing scope. It has no treasury authority by default.

**Alliance.** A formal working group with membership, charter, roles, and optionally a shared wallet inside an Organization. It is not a Project; it may own or sponsor many Projects.

**Project.** A collection of Personas, Members, agents, resources, agreements, Actions, work items, and Records organized to accomplish a purpose inside one Organization. Project is Studio's central organizing primitive.

**Engagement.** A commercial or professional agreement among an Organization and one or more parties. It defines scope, terms, milestones, compensation, credentials, conflicts, and acceptance. An Engagement may fund one or more Projects.

**Institution.** A first-class outside legal principal, such as a university, corporation, government agency, nonprofit, LLC, or church. It has its own identity, legal metadata, verification evidence, Agreements, delegates, wallets, authority chain, and optional lineage. It is not an Organization, Persona, Guest, or Member and has no Member ballot merely by paying or signing an Agreement.

**Forum.** A governed decision space owned by an Organization. An Organization may have multiple Forums for different domains, cadences, or risk levels.

**Proposal.** A versioned request for one or more Organization Commands. Before opening, the proposal must render an honest receipt from those exact parameters and disclose conflicts and dependencies.

**Policy.** The authoritative result of an enacted proposal or other valid policy command. Policy is queryable state with effective dates, scope, version, and source Record.

**Offering.** A paid product or service other than Compute or raw model consumption. An Offering purchase never triggers lineage.

### 3.3 Agent model

The schema uses one `Agent` identity contract with two families:

- `Agent:Ally`: exactly one Source Persona, one active Ally identity per authenticated Persona, bound to the shared canonical Ki AllyDefinition.
- `Agent:Actor`: no human Source and no sovereignty; owned or commissioned by an Organization, Alliance, Project, Institution, or Ecosystem.

Actor kinds include:

- `sentinel`: observes interaction health, detects manipulation/coercion or unsafe context, forces an explicit warning/confirmation where policy allows continuation, and escalates to a named human or role. It cannot waive a hard constitutional denial.
- `envoy`: carries a Member's typed Forum or Alliance instruction and may cast an authorized equal ballot or place a separately authorized market position after the required confirmation.
- `operator`: administers Forum mechanics and execution without choosing Member intent.
- `profiler`: collects inviter-authored prospect claims, public research allowed by policy, and onboarding questions without treating the prospect as an existing Persona.
- `code_manager`: creates, scopes, signs, expires, redeems, and revokes Codes for Ecosystem entry, Relationship proposals, Membership, Projects, Alliances, Communities, Wisdom, and other registered purposes.
- `registrar`: assembles and monitors official registration evidence.
- `researcher`: gathers sources and creates draft Wisdom.
- `project_steward`: derives work state and offers next Actions.
- `domain`: an Organization-defined kind created through a registered DomainPackage.

Queue consumers, indexers, reconcilers, and schedulers are `ServicePrincipal` records, not Actors. They do not appear socially in the Field. A `MagePrincipal` is a separate, tightly limited bootstrap administrator for an Ecosystem; it is never a Persona, Member, Ally, or general superuser.

### 3.4 Agent configuration: verb and noun

| Verb | Noun | Graph meaning | Runtime rule |
|---|---|---|---|
| Inform | Wisdom | Grant an agent permission to retrieve one or more Wisdom Drops | Retrieval remains subject to item access, purpose, Organization context, and conflicts |
| Instruct | Stance | Apply versioned instructions, tone, disclosure, response preferences, and channel policy | System and Organization policy outrank Stance; only the Source can alter personal Ally Stance |
| Empower | Connection | Bind a scoped account or external capability to an agent | The graph stores a credential reference and scopes, never the credential |
| Enable | Automation | Activate a trigger-to-Action rule | Automation creates an ActionRequest; it never bypasses authorization or confirmation |
| Impart | Skill | Attach a versioned procedure or package to an agent | Skills can propose commands only from the agent's closed allowlist |

### 3.5 Wisdom

A `WisdomDrop` is the permission and namespace boundary for material placed in the vector store. It is owned by a Persona, Organization, Alliance, Project, or Institution and credited to the Persona or principal that supplied it. It contains Items, Documents, Artifacts, and derived chunks.

Required WisdomDrop properties:

| Property | Requirement |
|---|---|
| `id`, `protocol_id` | Stable external identity; never expose an AGE internal ID |
| `name`, `description`, `handle` | Human and agent discoverability |
| `owner_principal_id`, `credited_persona_id` | Control and attribution are distinct |
| `organization_id` | Accountability context; Kinship Duna only when legitimately defaulted |
| `access_level` | public, private, secret, or personal |
| `purpose_tags` | Allowed uses such as research, client matter, health support, public education |
| `namespace_key` | Vector partition/namespace reference, not a secret |
| `retention_policy_id`, `legal_class` | Retention, privilege, health, financial, minor, employment, or general |
| `version`, `status`, `created_at`, `superseded_by` | Immutable versions and lifecycle |

Private access may be unlocked by Code, Relationship grant, role, Agreement, Alliance, Organization policy, or a specific principal grant. Secret material is not listed before authorization. Personal material cannot be unlocked at all. Access changes generate Records and immediately invalidate cached reachability and vector-scope keys.

![Figure 2. Core domain graph](figures/core-domain.png)

## 4. The Action architecture

### 4.1 Why Actions are nodes and edges

An edge is appropriate for a compact current relationship such as `OWNS`, `IN_PROJECT`, or `HAS_ACTIVE_MEMBERSHIP`. An Action is not merely a relationship. It has a definition, parameters, requester, Source, Organization context, authority requirement, confirmation, state machine, attempts, side effects, errors, results, and evidence. It must therefore be reified.

The design uses nodes for the durable nouns and edges for their semantic roles:

```text
(Persona)-[:SOURCE_OF]->(Ally)
(Ally)-[:CREATED_REQUEST]->(ActionRequest)
(ActionRequest)-[:USES_DEFINITION]->(ActionDefinition)
(ActionRequest)-[:IN_ORGANIZATION]->(Organization)
(ActionRequest)-[:TARGETS]->(Project|Resource|Principal)
(ActionRequest)-[:PROPOSES]->(Command)
(AuthorizationDecision)-[:DECIDES]->(ActionRequest)
(ActionRun)-[:ATTEMPTS]->(Command)
(Actor|ServicePrincipal)-[:PERFORMED]->(ActionRun)
(ActionRun)-[:STARTED]->(ExternalOperation)
(ActionRun)-[:PRODUCED]->(Record)
```

### 4.2 ActionDefinition

An ActionDefinition is a versioned registry entry. It answers "what kind of thing can be done?"

Required fields:

- `key` and semantic version, for example `project.work.assign@1.2.0`.
- family: converse, wisdom, relationship, membership, organization, project, work, governance, treasury, compute, commerce, identity, security, domain.
- JSON Schema for parameters and result.
- allowed requester principal types and allowed performer types.
- authority class and required roles, grants, policy predicates, credentials, and conflict checks.
- Organization and Project context requirements.
- risk class: read, reversible, consequential, financial, sovereign, regulated, emergency.
- confirmation mode: none, acknowledge, explicit confirm, fresh authentication, press-and-hold signature, multisig, or Forum.
- idempotency scope and concurrency key.
- command mapping and handler version.
- machine receipt renderer and redaction rules.
- data use, retention, and telemetry policy.
- compensating command, if one exists.
- simulation eligibility and hard prohibition on real rails when `sim=true`.

### 4.3 ActionRequest

An ActionRequest is a specific desired consequence. It is created from a Persona prompt, a signed UI control, an Automation trigger, an Actor output, a Forum result, an external event, or another completed Action.

Key fields:

- `action_definition_id`, `definition_version`, and validated parameters.
- `source_persona_id` when the request originates from a Persona's Ally.
- `requester_principal_id` and authenticated session/proof reference.
- `ally_id` and optional delegated Actor.
- `organization_id`, optional `project_id`, and target object IDs.
- `origin`: field, studio, express, channel, automation, forum, external webhook, federation.
- `authority_class`, requested deadline, and priority.
- `intent_record_id` referencing the original message or structured UI event under its access rules.
- `status`: proposed, awaiting_context, awaiting_authorization, awaiting_confirmation, queued, executing, waiting_external, completed, failed, denied, deferred, cancelled, expired.
- `expected_versions` for optimistic concurrency.
- `idempotency_key` bound to caller, definition, and canonical payload hash.

### 4.4 Machine-readable authority classes

Every DomainCommand registry entry declares exactly one primary authority class. Risk, confirmation, credential, multisig, and emergency requirements are additional overlays; they do not create ambiguous alternate classes.

| Class | Example | Required basis |
|---|---|---|
| Public | Read public Organization purpose; begin Account registration | Public resource, safe bounded query, no protected consequence |
| Guest | Accept invitation; purchase qualifying Membership package; verify identity; create personal draft workspace | Authenticated Guest, Guest allowlist, exact Organization context, confirmation where required |
| Member | Join a Member-only Community; cast an eligible ordinary ballot | Active Membership in the exact Organization and current eligibility |
| Role | Assign permitted Project work; accept a deliverable | Active Membership or authorized delegate plus current role/grant and resource state |
| Policy | Run an approved Automation or recurring operational command | Active versioned Policy whose predicates and limits match current state |
| Forum | Enact constitutional change; issue Compute; approve a major Organization command | Passed Proposal containing the exact Command and parameters |
| Treasury | Authorize or execute a treasury movement | Treasury Policy, account authority, threshold approvals, budget, and fresh confirmation |
| GovernanceMarket | Place or settle an optional decision-market position | Activated market policy, eligible Envoy instruction, limits, disclosures, and approved rail |
| ExternalAgreement | Act for an Institution or counterparty under an Agreement | Verified Institution, active Agreement, named delegate/agent, scope, and counterparty conditions |
| RegulatedCredential | File legal document; approve underwriting; clinical sign-off | Current license/credential, jurisdiction, Engagement, conflict check, and required human signature |

`confirmation_mode` separately declares none, acknowledge, allow-once, allow-always-policy-create, explicit confirm, fresh authentication, press-and-hold signature, multisig, Forum, or credentialed-human. `risk_class` separately declares read, reversible, consequential, financial, sovereign, regulated, or emergency. Hard constitutional denials always outrank all three fields.

### 4.5 AuthorizationDecision

Every protected read and every ActionRequest receives a deterministic decision object. The decision stores no secret content; it stores the evaluated fact IDs and outcome.

```json
{
  "decision_id": "kid:authz:01...",
  "principal": "kid:ally:01...",
  "source_persona": "kid:persona:01...",
  "action": "project.work.assign@1.2.0",
  "resource": "kid:project:01...",
  "organization": "kid:org:628407",
  "result": "allow",
  "basis": ["role:project_lead", "policy:work_assignment@3", "grant:project_scope@7"],
  "conflicts_checked": ["institution", "financial", "family", "engagement"],
  "requires_confirmation": "explicit",
  "policy_bundle": "sha256:...",
  "evaluated_at": "2026-07-14T...Z"
}
```

Decision precedence:

1. Hard constitutional deny.
2. Explicit forbid or conflict/recusal.
3. Resource state and legal/credential requirements.
4. Active Policy.
5. Specific grant or Code claim.
6. Role and Membership.
7. Public/read default where permitted.
8. Default deny.

### 4.6 Command

A Command is the deterministic instruction that can change Kiduna state. Commands never accept arbitrary Cypher or generic CRUD. A command registry entry defines:

- canonical name and version;
- parameter and result schemas;
- authority class;
- precondition query names;
- exact local writes;
- external operation templates;
- expected aggregate versions;
- idempotency and locking rules;
- receipt renderer;
- persona-facing error mapping;
- privacy and retention behavior;
- tests and migration compatibility.

Examples: `project.create`, `work.assign`, `wisdom.inform_agent`, `membership.admit`, `forum.proposal.open`, `forum.ballot.cast`, `compute.purchase.record`, `compute.waterfall.allocate`, `organization.registration.submit`, `treasury.payment.authorize`.

### 4.7 ActionRun and ExternalOperation

`ActionRun` records an attempt to execute a Command. Retries create new runs under the same ActionRequest, never overwrite the earlier attempt. A local Command either commits its current graph state, relational control rows, ledger references, Record, and outbox entry in one transaction or commits nothing.

An `ExternalOperation` represents a side effect outside that transaction: payment, chain submission, email, legal filing, DEX interaction, external account call, physical dispatch, or federated request.

Required states: authorized, queued, submitted, acknowledged, awaiting_external, settled, failed_retryable, failed_terminal, compensating, compensated, manually_resolved. The UI and Ally must never say "complete" while the operation is only submitted.

### 4.8 Record

A Record is immutable persona-relevant evidence. It links:

- the intent source and ActionRequest;
- the identity and authority proof;
- exact Command and parameters, with protected fields hashed or redacted;
- policy, role, grant, conflict, and confirmation basis;
- ActionRun, performer, tool/model/agent versions;
- local state version before and after;
- external operation references and settlement proof;
- artifacts, results, corrections, and superseding Records.

The Record graph is the foundation for the Vigil, audit, accounting evidence, organizational memory, and provenance.

![Figure 3. Action lifecycle](figures/action-lifecycle.png)

## 5. Permission and policy engine

### 5.1 The authorization tuple

Every decision evaluates:

`principal + Source + requested action + resource + Organization + Project + purpose + time + state + grants + role + Policy + credential + conflict + budget + device/session assurance`.

The four access levels are a persona-facing disclosure model, not the full policy model. Engineers must not compress authorization into a single `visibility` property.

### 5.2 Principals

- Public/Visitor subject with no durable principal and Public authority only.
- Authenticated Persona acting as Guest or through one or more Organization Memberships.
- Member authority set derived from a specific active Membership, never from a global label.
- Ally acting for its authenticated Source.
- Actor instance under an immutable manifest.
- InstitutionDelegate acting under an Institution Agreement and role.
- Organization or Alliance authority set acting through a valid resolution.
- ServicePrincipal with a narrow deterministic capability.
- Ecosystem peer under a KAP relationship and signed envelope.

### 5.3 Grants

A `Grant` is a node because it can carry scope, purpose, fields, tools, terms, expiry, revocation, provenance, and author. Relationship grants are directional: each Persona controls their own grant to the other.

Grant fields include:

- grantor, grantee, Organization, optional Project or Relationship;
- resource selectors or collection;
- permitted ActionDefinitions and fields;
- allowed purposes and prohibited uses;
- access level ceiling;
- tool scopes and transaction limits;
- start, expiry, use count, revocation;
- whether further delegation is prohibited or narrowly allowed;
- source Code, Agreement, Policy, or sovereign confirmation Record.

### 5.4 Source-only instruction

The orchestrator classifies every inbound message before context assembly:

- Authenticated Source message: may create instruction intent.
- Other Persona or Member with a valid grant: request or scoped context.
- Code holder: context within Code claims.
- Actor/Tool/web content: untrusted input and potential prompt injection.
- Unknown origin: signal only; no instruction status.

The classification is carried as signed request metadata to the Graph Command Service. The model cannot promote a message to Source authority.

### 5.5 Conflict and recusal

Conflict evaluation is a named query over Institution affiliations, Organization roles, paid Engagements, family/Relationship disclosures, financial interests, and counterparties. A conflict can:

- disclose and allow;
- require a different human signer;
- prohibit a ballot or position;
- require Forum or multisig authority;
- block access to privileged Wisdom;
- route to compliance review.

Institution recusal is a hard launch rule: a Member enrolled or delegated by an Institution cannot cast the Organization ballot on that Institution's agreement. The decision-market position, if allowed at all, must be separately governed and disclosed.

### 5.6 Query safety

- Agents call named queries and named commands only.
- No LLM-generated Cypher reaches production execution.
- Every named query declares anchor types, maximum depth, result cap, time budget, allowed labels/edges, required policy context, and redaction shape.
- The query guard rejects unbounded variable paths, dynamic labels, user-controlled property expressions, unsupported functions, and results without a limit.
- Database statement timeout, cost monitoring, and per-principal quotas provide a second boundary.
- PostgreSQL row-level security applies to relational control, vector, and ledger tables as defense in depth; default deny applies when no policy matches.

### 5.7 Public and Guest launch allowlist

The Kinship Duna default context may be used only for the following registered commands. Any command not listed is denied until the Persona has the required Membership, role, Policy, Agreement, Forum result, or credential.

| Authority | Launch commands |
|---|---|
| Public/Visitor | `public.organization.inspect`, `public.action_catalog.list`, `account.registration.begin`, `invitation.preview_public` |
| Guest | `account.complete`, `invitation.accept`, `identity.verify.request`, `relationship.proposal.accept`, `relationship.proposal.decline`, `membership.application.create`, `membership.package.purchase`, `compute.guest_purchase.intent`, `compute.guest_purchase.confirm`, `workspace.personal_draft.create`, `ally.rename`, `ally.stance.update`, `wisdom.personal.add`, `connection.add`, `organization.public_inspect` |

Guest commands cannot vote, join a Member-only Community, bind the Organization, create or spend Organization treasury funds, access Member-only Wisdom, create legal Membership, issue transferable Compute, place a market position, receive lineage, or invoke a regulated rail. `membership.admit` is a separate Member/Role/Policy/Forum command after all admission conditions are verified.

### 5.8 Confirmation policy

The first consequential use of an ActionDefinition requires the confirmation mode registered for that Action. A rendered control may offer **Allow once** or **Allow every time**. Allow every time does not disable authorization; it creates a narrow, versioned Persona Policy bound to ActionDefinition, Organization, resource selector, parameter ceilings, device assurance, expiry, and revocation. Any material parameter, risk, policy, conflict, credential, or context change forces a new preview and confirmation.

## 6. Organization and legal-form architecture

### 6.1 Organization is not a draft label

Use three separate objects:

- `OrganizationPlan`: proposed name, purpose, Catalyst, Sponsoring Organization, designee, and intended legal form.
- `LegalRegistration`: evidence and lifecycle for a jurisdiction-specific filing.
- `Organization`: the active accountability container created or activated only when the legal adapter's requirements are satisfied.

For West Virginia DUNAs, the adapter must model governing principles, mutual consent, member threshold, registered agent, designee/contact package, filing reference, Org ID, status, verification source, and periodic re-verification. Current West Virginia Code defines a DUNA as at least 100 mutually consenting members; the system must not equate receipt of an Org ID with every substantive lifecycle requirement.

Every `LegalFormAdapter` exposes: legal identifier, jurisdiction, current standing, formation requirements, minimum and continuing Membership rules, dissolution status, authority model, verification source, verification timestamp, next verification deadline, and command gates affected by status. Status is refreshed continuously or on a defined schedule; an expired verification cannot authorize a new legal or financial Action.

### 6.2 Registration Offering

Organization registration is purchased as an Offering because it is a paid service outside model Compute.

`RegistrationOffering` includes provider/registered-agent principal, legal form, jurisdiction, base price, service-level option such as 2 hours, 4 hours, or 1 day, required fields, taxes/fees, expiry, and refund/cancellation policy.

The registration flow:

1. Catalyst creates OrganizationPlan with name and proposed designee.
2. Designee Persona accepts the role through a sovereign Action and supplies name, address, phone, and email under secret/legal access; where the legal form requires Membership, that condition is validated separately.
3. Authorized Persona purchases the RegistrationOffering.
4. Registrar Actor assembles a filing package; credentialed human registered agent reviews and files.
5. ExternalOperation tracks submission, acknowledgement, corrections, and completion.
6. LegalRegistration records the Org ID and verified source evidence.
7. The Graph Command Service activates the Organization and creates its default policy/configuration objects.

### 6.3 Organization configuration

Before Launchpad publication, an Organization requires:

- name, handle, purpose/mission, description, website, legal registration, Catalyst, Sponsor, and designee;
- at least one Stance bundle for its host/agent behavior;
- baseline Wisdom Drops and source/credit metadata;
- Connection policy and any configured accounts;
- Automations with budgets and stop conditions;
- Skills and DomainPackages;
- MembershipPolicy, ForumPolicy, ComputePolicy, WaterfallPolicy, AgencyPricingPolicy, TreasuryPolicy, ConflictPolicy, and RecordsPolicy;
- at least one contactable organizational Actor or host presence;
- LaunchCampaign terms and machine-rendered consequences.

### 6.4 Launchpad lifecycle

`LaunchCampaign` states: draft, scheduled, reservation_open, purchase_open, minimum_met, closed_success, closed_failed, issuing, settled, cancelled.

Validation rules from the product-owner specification:

- minimum target must be greater than or equal to the configured legal/product floor; stated launch rule is more than 1,000 USDC;
- maximum target must not exceed 10,000,000 USDC;
- close date must be after open date and any reservation period;
- reservations do not issue Compute and do not enter the waterfall until converted to settled Compute purchases;
- each purchase binds to a Kinship Code where the Organization requires one;
- the Sponsoring Organization may purchase Compute and later distribute it to its Members;
- a failed campaign follows explicit refund/release instructions and creates no Compute issuance.

![Figure 4. Organization formation and launch lifecycle](figures/organization-lifecycle.png)

### 6.5 Genesis Ecosystem bootstrap

Deployment bootstrap is infrastructure, not an ordinary Persona Action. The install migration creates the Genesis objects in a fixed order before the first Account can register:

1. Create the `Ecosystem` with permanent protocol ID, unique handle `kiduna`, DID/verification methods, Home Ecosystem policy, federation defaults, and root key references.
2. Create the shared `AllyDefinition` for **Ki** (display name **Kinship Intelligence**) with base Stance, required Wisdom, Skills, Tool manifests, safety policies, and version.
3. Create the limited `MagePrincipal` and account handle convention `<ecosystem_handle>_mage`. Mage may configure bootstrap objects and issue the first Genesis Code; it cannot impersonate a Persona, become a Member, vote, sign, spend Organization funds, read Personal Wisdom, or use general domain commands.
4. Verify that Kinship Duna and the minimum Public/Guest policy bundle exist. The "every Action has an Organization" invariant begins at the Persona-facing boundary; install migrations are not Actions and cannot be invoked through Ally or Actor tools.
5. Issue a single-use Genesis Code under the Mage's narrow manifest and invite the first Persona.

The product may describe Ki as one Ally, but runtime state is tenant-separated. `AllyDefinition` is shared; `AllyIdentity`, Source link, alias, handle, Stance overlay, Wisdom reachability, Connections, Automations, Skills, memory, budgets, and Records are Persona-specific. No query may retrieve another Persona's Ally partition merely because both use Ki.

### 6.6 Onboarding surfaces and trust boundary

The same signed onboarding state machine may be rendered by Kiduna Live, Kiduna Studio, Kiduna Express, Kiduna TV, an approved embedded website flow, or a future surface. Surfaces never implement membership, pricing, Code, or wallet rules themselves; they call the Graph Command Service through versioned APIs.

The canonical financial origin is `kiduna.ai`; the canonical API origin is `api.kiduna.ai`. Wallet recovery/key-share architecture is represented through `Wallet`, `KeyShareReference`, `CustodyPolicy`, and recovery Records. No raw share or payment credential enters the graph. Alternate domains and embedded surfaces must display and cryptographically verify the canonical financial origin before redirecting a Persona.

The first authenticated Ki session should minimize time to first value. Ki may offer to complete Profile fields, inspect Organizations, apply for Membership, create or join an Alliance, create a Project, add Wisdom, or connect an account. Every offered option comes from `list_available_actions`; the model does not invent a capability.

### 6.7 Invitation, prospect, and Relationship lifecycle

The invitation pipeline is consent-preserving and graph-native:

1. Inviter Persona tells their Ally to invite a person and supplies the intended target scope: Ecosystem, Organization, Membership, Project, Alliance, Community, Relationship, or Wisdom.
2. Ally creates a draft `ActionRequest` and invokes a Profiler Actor only after the inviter confirms the purpose and supplies at least one contact route.
3. Profiler creates `InvitationProspect`, not Persona. It records inviter-authored claims, source, uncertainty, purpose, access level, and retention deadline. Optional public research is separately attributed.
4. Inviter chooses a directional trust declaration: low, medium, or high, plus optional rationale and visibility. Trust does not authorize code execution, file acceptance, payment, or protected access.
5. CodeManager checks whether the target resolves to an existing Persona by protocol ID, verified handle, contact proof, or privacy-preserving identity challenge.
6. For an existing Persona, the system creates an in-system `RelationshipProposal` or scoped invitation. Optional passphrase/challenge proof may confirm the intended recipient.
7. For an unregistered person, CodeManager creates a signed, single-use, recipient-bound Code with a 15-minute default expiry. The platform returns it to the inviter and performs no outbound delivery.
8. A generalized Code may be multi-recipient only when its registered type permits it. It carries no prospect Profile, defaults trust to untrusted, and declares target, maximum redemptions, expiry, issuer, and claims.
9. On redemption, the service verifies signature, issuer, intended recipient proof where present, expiry, use count, revocation, target status, and replay nonce before showing protected details.
10. The Visitor creates an Account and becomes an authenticated Guest Persona. The invitee reviews all inviter-supplied Profile claims; none become self-authored facts without acceptance.
11. The invitee accepts or declines each Relationship, target participation, data grant, and trust visibility independently. An invitation to a Project never silently admits Membership to its Organization.
12. Accepted Relationship creates one Relationship node with two independent trust declarations and grants. Declined/expired claims are retained only as restricted Records under the retention policy.
13. Any Membership application then runs the Organization's separate admission workflow and legal-form adapter.
14. Ki assembles the new Persona's environment from accepted claims, permitted Communities/Projects, public Wisdom, and active grants; it does not expose the inviter's private notes.
15. Acceptance, decline, expiry, revocation, and every Code redemption attempt create Records and invalidate relevant caches.

![Figure 5. Invitation and onboarding lifecycle](figures/invitation-lifecycle.png)

## 7. Compute, agency pricing, lineage, and the waterfall

### 7.1 Compute objects

The model separates:

- `ComputeDefinition`: Organization issuer, denomination, usage purpose, transfer policy, decimals, settlement/chain references, status.
- `ComputeAccount`: balance owner, Organization, custody reference, restrictions.
- `ComputeIssuance`: amount, authority, Forum Proposal/Policy, mint or ledger reference.
- `ComputePurchase`: purchaser principal, USDC amount, Compute amount, price, Code, campaign, settlement state.
- `ComputeGrant`: distribution from an Institution or Sponsoring Organization to a Persona under an Agreement or to one of its Members under Organization Policy.
- `ComputeConsumption`: model/provider usage, input/output units, provider cost, Organization charge, multiple, premium, Project and Action.
- `WaterfallAllocation`: one destination amount under a specific WaterfallPolicy version.

### 7.2 Membership purchase policy

Each Organization may make a minimum initial Compute purchase one condition of Membership, but payment never makes a Persona a Member. Kinship Duna's launch policy is explicit:

- Guest access: minimum 10 USDC of Compute; remains Guest and receives only Guest authority.
- Persona seeking Membership: minimum 100 USDC of Compute plus accepted governing terms, admission decision, identity checks, and every applicable legal-form requirement.
- Institution participation: minimum 1,000 USDC of Compute plus an effective Institution Agreement; this never creates human Membership or a ballot.

`membership.admit` validates all conditions and creates the active Membership and Record. `compute.purchase` records the economic event separately. Reversals, expiration, suspension, withdrawal, or expulsion change Membership only through their own Commands.

### 7.3 Agency pricing

For each model/tool consumption, the selected versioned schedule calculates:

```text
provider_cost = verified input + output + tool cost
member_charge = pricing_rule(provider_cost, organization_multiple, minimums, caps)
agency_premium = member_charge - provider_cost
```

Kinship Duna's initial disclosed schedule uses a 7x Member multiplier on verified provider/tool cost. A Guest pays 2x the corresponding Member charge, producing an effective 14x provider-cost charge before any disclosed fixed tool charge. The receipt must show provider cost, applicable status, base multiple, Guest factor, fixed charges, final Compute charge, and Organization premium. The policy also declares a maximum markup and rounding rule; no hidden dynamic markup is permitted at launch.

The Organization receives the agency premium under its current `AgencyPricingPolicy`. This is consumption revenue, not a Compute purchase and therefore does not trigger lineage or the launch waterfall. Future pricing changes are prospective, versioned, disclosed before confirmation, and cannot reprice completed consumption.

### 7.4 Default Compute purchase waterfall

The product-owner default is represented as a versioned policy:

| Destination | Default | Rule |
|---|---:|---|
| Lineage generation 1 | 20% | Current parent in the frozen Organization lineage snapshot |
| Lineage generation 2 | 5% | Second ancestor |
| Lineage generation 3 | 3% | Third ancestor |
| Lineage generation 4 | 2% | Fourth ancestor |
| Liquidity | 20% | Default minimum under the current versioned Kiduna Organization policy; not a protocol invariant |
| Kiduna Club license | 3% | Licensing allocation under the applicable Agreement |
| Curator | 2% | Member or Institution that introduced the Catalyst, if eligible |
| Treasury | 45% | Residual under the default policy |

Policy requirements:

- percentages must sum to 100 after all explicit fallbacks;
- changes are prospective, versioned, Forum-authorized where policy requires, and never rewrite settled purchases;
- a missing or ineligible ancestor is skipped upward to the next qualified ancestor in the frozen lineage; any remaining unfilled generation allocation after the traversal limit goes to the policy's named treasury/reserve account, never to a fabricated participant;
- the Curator may also be an ancestor, but the two allocations remain distinct and disclosed;
- an Institution can occupy any eligible lineage position and can have Member or Institution progeny;
- the purchasing principal may be a Member, Institution, Organization, or another principal explicitly permitted by Policy; a Guest purchase does not receive lineage without a separate lawful eligibility rule;
- no allocation is paid until the purchase settlement is verified;
- fiat/onramp purchases may create pending allocations that settle only after verified bridge/rail settlement;
- Offerings never invoke this policy.

### 7.5 Lineage model

Do not store generation numbers as a set of permanent direct edges from the child to every ancestor. Store one current parent enrollment per Organization and derive/materialize ancestry.

Core objects:

- `LineageParticipant` role on a Persona with active qualifying Membership, or on an Institution; it is not a separate human identity label.
- `LineageEnrollment`: child, parent, Organization, Code, sponsoring context, effective time, status, provenance.
- `LineageSnapshot`: frozen four-generation chain created for a ComputePurchase.
- `WaterfallPolicy`: schedule and fallbacks.
- `WaterfallAllocation`: calculated destination, amount, reason, state, settlement reference.

This prevents later lineage changes or policy edits from changing historical payouts.

### 7.6 Founding Alliance policy

An Organization may configure a monthly transfer to its Founding Alliance as:

- fixed amount;
- percentage of settled Compute purchase proceeds;
- minimum and maximum amount;
- treasury sufficiency floor;
- start/end dates;
- approval and pause rules.

The Automation creates a recurring ActionRequest. It does not transfer funds by itself. The applicable Policy authorizes the Command, and the ledger plus external rail Records the result.

### 7.7 Architecture-level pushback

The schema supports transferable Compute, DEX trading, multilevel lineage, launch campaigns, and variable agency multiples. It should not hard-code their production activation. Current official guidance makes the implemented facts important: transferability and secondary-market expectations can affect digital-asset analysis; compensation tied to participant/downline purchases receives fact-specific scrutiny; and payment-transmission status depends on actual control of funds. Each risky feature therefore has a deployment gate tied to counsel approval, implemented custody/settlement facts, disclosures, monitoring, and the ability to disable new activity without corrupting historical Records.

### 7.8 Launch feature activation

The schema and simulation harness implement the full economic model, but activation is independent per capability. At August 10 launch, the following are **disabled for live value** pending legal, accounting, tax, custody, rail, and exchange review: transferable or DEX-traded Compute, decision-market positions, lineage payouts, Curator allocations, Sponsor distributions, and automated liquidity deployment. Their commands may run only in a non-settling simulation tenant with conspicuous test labeling.

Non-transferable Compute purchase and consumption may be active only after ledger, pricing-disclosure, refund, custody, reconciliation, and operator sign-off gates pass. A feature gate is evaluated by deterministic code and cannot be bypassed by an Ally, Actor, Forum result, or Mage.

## 8. Forums, proposals, Envoys, and Policy

### 8.1 Multiple Forums per Organization

Examples:

- Constitutional Forum: charter, membership rules, dissolution, major changes.
- Treasury Forum: budgets, grants, payments, liquidity.
- Program Forum: agent budgets, Skills, Automations, DomainPackages.
- Project Forum: large Project commitments above delegated thresholds.
- Domain Forum: claims, clinical standards, festival safety, game rules, underwriting policy.

Each Forum has a `ForumPolicy` defining eligibility, quorum, duration, proposal categories, discussion rules, market signal settings, position limits, conflict rules, operators, execution thresholds, appeal/reconsideration, and emergency procedure.

### 8.2 Separate the two pass/fail mechanisms

The canon contains both equal Member deciding and USDC-funded pass/fail trading. They must be separate in data and interface:

**Governance ballot.** One eligible Member, one free equal pass/fail ballot. This determines enactment when the Organization's governing principles say it does.

**Decision-market position.** An optional USDC-funded pass/fail position placed by an Envoy under Member instruction. It is a forecast or conviction signal with its own settlement logic and limits. It does not become a ballot and does not buy greater legal voting power.

If a future Organization chooses a different lawful governance algorithm, it must register a new `DecisionMethod` with explicit semantics, not overload `Forum`, `Vote`, or `Trade`.

### 8.3 Proposal pipeline

1. Member tells Ally the organizational intent.
2. Ally and Configuration Drafter map intent to one or more exact Commands.
3. Graph Command Service validates parameter completeness, authority route, dependencies, conflicts, and whether a Forum is required.
4. Receipt renderer creates the consequence sentence from the exact parameters.
5. Proposal opens in a specific Forum; discussion and evidence attach as Records/Wisdom.
6. Members give sovereign ballot instructions; Envoys may place allowed positions under separate instructions.
7. Operator closes according to ForumPolicy; deterministic tally/resolution service records the result.
8. Passed Commands execute locally or begin ExternalOperations.
9. Policy is created with effective scope and status. External effects remain pending until verified.
10. Every affected Persona can inspect the permission-filtered receipt chain; every eligible Member can inspect the Organization governance record required by its rules.

### 8.4 Proposal state

`draft -> command_complete -> receipt_complete -> submitted -> deliberating -> open -> closed -> passed|failed|withdrawn -> executing -> pending_external|partially_settled -> enacted|execution_failed|superseded`.

An authorization outcome and a physical-world outcome are not the same. A passed proposal can authorize a land purchase; title transfer becomes true only when the relevant external evidence settles.

![Figure 6. Forum to Policy pipeline](figures/forum-policy.png)

## 9. Projects and real work

### 9.1 Project graph

Every Project links:

- accountable Organization;
- purpose and success criteria;
- participating Personas, exact Organization Memberships where required, and Project roles;
- sponsoring Alliance or Institution;
- Engagements and counterparties;
- Wisdom Drops and Artifacts;
- Allies and Actor instances;
- Skills, Connections, and Automations;
- WorkItems, milestones, dependencies, and deliverables;
- Agreements, terms, split rules, invoices, and payouts;
- Actions, Records, conflicts, credentials, and legal holds;
- stable Field/Scene address and derived status.

Project status is derived from its graph: proposed, active work, waiting on an Action, blocked by external operation, under review, complete, archived. Personas do not type a cosmetic status detached from facts.

### 9.2 WorkItem and Contribution

`WorkItem` defines an outcome, not employee supervision. It can carry requested result, constraints, due date, required credential, acceptance criteria, budget, dependencies, and current assignee. `Contribution` records what a Persona or Actor actually supplied, with provenance and acceptance status.

`assign_work` is an Action. `accept_deliverable` is a different, often sovereign or credentialed Action. `pay_split` is a financial Action triggered only after the agreed condition and settlement rules.

### 9.3 Engagement and compensation

An Engagement records the parties, Organization, scope, classification review facts, rate/split formula, expenses, tax forms, milestones, changes, acceptance, invoicing, payment trigger, and dispute terms. Worker classification must not be hard-coded as "1099"; the system stores the actual control and independence facts and routes exceptions for review.

Split rules are versioned and bound at acceptance. When client payment settles, the ledger creates the exact distributions. The graph links each distribution to the Engagement, Contribution, acceptance Record, and recipient.

### 9.4 DomainPackage extension model

Do not put every industry's noun into the global kernel. A `DomainPackage` supplies:

- ResourceType schemas and labels;
- ActionDefinitions and CommandDefinitions;
- role and credential definitions;
- policy templates and conflict rules;
- Skills and Actor manifests;
- Wisdom sources and retention classes;
- Field projections;
- acceptance and safety tests;
- migration and version compatibility.

The kernel remains stable while domains grow.

### 9.5 Required domain coverage

**DUNA law firm.** Matter, Client, Engagement, ConflictCheck, Credential, Filing, Deadline, AdviceDraft, HumanApproval, Invoice, OperatingPayment, and LegalHold. Secret and privileged Wisdom is isolated by matter. Agents may research and draft; credentialed lawyers sign. Client trust/IOLTA is an external restricted account and the automation refuses to split funds while they remain in trust.

**Insurance company.** CoverageProduct, Application, UnderwritingCase, RiskEvidence, Claim, Reserve, AdjusterAssignment, ActuarialModel, RegulatoryFiling, PaymentAuthorization. Licensing and phase gates are explicit. No Actor can promise coverage or approve a regulated act outside the configured credential/policy route.

**Solar installer.** Site, Assessment, Design, Permit, Equipment, Vendor Institution, Installer Credential, Financing Agreement, WorkOrder, Inspection, Interconnection, ProductionTelemetry, Maintenance. Sensor events remain time-series data; the graph stores assets, latest state, exceptions, and Records.

**Mortgage company.** Applicant, Property, Application, Consent, DocumentChecklist, Disclosure, Lender Institution, LoanProduct, UnderwritingDecision, Appraisal, Condition, Closing, ServicingHandoff. Sensitive documents stay in encrypted object storage; decisions cite policies and required licensed humans.

**Psychotherapy and health.** Client, CareEngagement, Consent, ProviderCredential, Appointment, CarePlan, SessionRecord pointer, Referral, SafetyEscalation. Clinical notes use separate encryption and strict purpose boundaries. Model inference cannot become diagnosis or treatment authority. Emergency routing is explicit and human-owned.

**Table games and video games.** Game, RuleSet, Session, Table/Lobby, PlayerRole, Team, Match, Result, Tournament, Asset, ModerationAction, SafetyRule, CreatorRoyalty. A game action can be simulated or real; the `sim` flag controls rails, not whether the Record exists.

**Parties and festivals.** Event, Venue, Permit, Ticket/Code, Vendor, Performer, Crew, Shift, SafetyPlan, Capacity, Incident, Settlement, RightsLicense. Actors coordinate schedules and communications; credentialed humans approve safety, permits, and payments.

These examples prove the schema by variation. They are not separate platform products.

### 9.6 August 10 DomainPackage activation matrix

| Status | Packages/capabilities | Launch rule |
|---|---|---|
| Active when P0 gates pass | identity/account, Ki/Ally, invitation/Code, Relationship, Organization context, Membership, Wisdom, Project/WorkItem/Contribution, communication, equal governance ballot, non-transferable Compute consumption, audit/Vigil, games, and event coordination | Named commands only; no hidden mutation; exact authority and confirmation |
| Preview | Organization registration, Offering/Launchpad, Institution Agreements, legal work, insurance, mortgage, health/care, and regulated solar steps | Read, draft, checklist, simulation, and human handoff only; no representation that an external or regulated effect completed |
| Disabled for live value | transferable/DEX Compute, decision-market positions, lineage settlement, Curator allocation, Sponsor distribution, automated liquidity, custody, lending, securities/investment advice, payroll, insurance binding/claim payment, clinical diagnosis/treatment, and autonomous legal filing | Schema/test fixtures may exist; production command gate always denies until separately approved |

Package status is stored by Ecosystem, Organization, version, jurisdiction, and command. Enabling a package never enables every command inside it. Regulated commands additionally require `RegulatedCredential` or `ExternalAgreement` authority and current legal-adapter status.

## 10. Physical data architecture

### 10.1 Launch stack

Recommended launch deployment:

- PostgreSQL with a version-pinned Apache AGE extension for the typed property graph.
- pgvector in the same cluster for permission-scoped semantic candidates.
- Relational schemas for command registry, object registry, Records, events, outbox, external operations, double-entry ledger, identity/session, and migrations.
- S3-compatible encrypted object storage for files and large artifacts.
- Secrets manager/HSM or secure enclave references for credentials and root keys.
- Orchestration workers for Allies and Actors.
- Ingestion workers for files, metadata, chunks, embeddings, entities, and provenance.
- Outbox/reconciliation workers for payments, chain, messaging, filings, and federation.
- OpenTelemetry-compatible traces, metrics, and logs with privacy-safe attributes.

Apache AGE remains a sound launch fit because it places graph queries inside PostgreSQL's transaction and storage system and supports openCypher plus SQL. As of this specification, Apache lists AGE 1.7.0 for PostgreSQL 18 and 1.6.0 for PostgreSQL 16/17. Engineering must pin the pair already proven by migration, backup, load, and extension tests; "latest" is not a release strategy.

### 10.2 One graph per Ecosystem

Use one AGE graph namespace per Ecosystem, not one graph per Organization. Cross-Organization Relationships, Personas, Memberships, Institutions, lineage, and shared Wisdom require traversal. Organization boundaries are enforced by properties, policy, grants, named queries, and RLS defense in depth, not by creating hundreds of isolated graph databases.

### 10.3 Three forms of state

| State | Store | Purpose |
|---|---|---|
| Current operating state | AGE graph plus typed object registry | What exists, how it is related, current policy/reachability, derived work state |
| Immutable evidence and transitions | PostgreSQL Record/event tables, selected Record nodes | What happened, under what authority, in what order |
| Semantic candidates | pgvector plus authorized Item metadata | What text or artifact may be relevant; never authority |

Financial entries use a fourth specialized form: immutable double-entry ledger rows plus verified external references. Time-series telemetry such as solar output or gameplay events uses a fifth optimized store when volume warrants it; graph nodes hold durable assets, summaries, alerts, and provenance.

### 10.4 Stable IDs

- Use UUIDv7 or ULID database IDs and a portable `protocol_id` such as `kap://eco.kiduna.net/org/628407/project/01...`.
- Never expose AGE vertex IDs as API identity.
- IDs are immutable across migration and federation.
- Every mutable aggregate has one authoritative home Ecosystem and a monotonically increasing version.
- Cross-Ecosystem references include protocol ID, home Ecosystem, issuer, key/version, and last verified Record.

### 10.5 Universal node properties

Every first-class node carries where applicable:

`id`, `protocol_id`, `kind`, `schema_version`, `ecosystem_id`, `home_ecosystem_id`, `organization_id`, `controller_principal_id`, `access_level`, `legal_class`, `status`, `version`, `valid_from`, `valid_to`, `created_at`, `updated_at`, `origin_ecosystem_id`, `provenance_record_id`, `superseded_by`.

Not every node has an Organization, but every ActionRequest does.

### 10.6 Universal edge properties

Durable edges carry:

`id`, `edge_type`, `organization_id`, `access_level`, `purpose`, `status`, `valid_from`, `valid_to`, `version`, `created_by_record_id`, `superseded_by`.

Do not put a changing historical narrative only on an edge. When the relationship needs independent lifecycle, authorship, terms, or evidence, reify it as a node.

### 10.7 Relational control tables

Minimum tables:

- `object_registry`: global unique IDs, kind, home, controller, version, graph label, lifecycle.
- `command_definition`, `action_definition`, `named_query_definition`: versioned registries and digests.
- `command_instance`, `authorization_decision`, `action_run`.
- `record`, `record_link`, `event_log`, `outbox`.
- `external_operation`, `external_callback`, `reconciliation_case`.
- `ledger_account`, `ledger_transaction`, `ledger_entry`, `settlement_reference`.
- `embedding_chunk`, `embedding_model`, `ingestion_job`.
- `credential_reference`, `key_registry`, `session`, `code_redemption`.
- `schema_migration`, `projection_checkpoint`, `policy_bundle`.

The SQL registry supplies uniqueness, foreign keys, check constraints, and high-value invariants that AGE does not enforce as a complete application schema. The Graph Command Service writes the registry and graph in one transaction.

### 10.8 Transaction and outbox

For a local command:

1. Begin PostgreSQL transaction.
2. Lock aggregate/version rows.
3. Re-evaluate authorization against current state.
4. Validate parameters and preconditions.
5. Write AGE graph changes.
6. Write control/ledger rows.
7. Append Record and internal event.
8. Insert outbox messages.
9. Commit.
10. Workers deliver messages and reconcile external operations idempotently.

No API response says complete until the relevant local commit or external settlement state justifies it.

### 10.9 Signed federation and migration

Every portable object has one Home Ecosystem that is authoritative for mutable state. Federation peers exchange signed resource manifests and Records containing protocol ID, schema version, home, issuer key/version, digest, audience, expiration, and capability scope. A local registration proves provenance and routability; it never grants access.

A Persona migration is a sovereign Action. It freezes conflicting writes, exports encrypted authorized state, verifies the destination, records a signed handoff from old and new homes, advances the home epoch, updates routing, and preserves the permanent ID and complete history. Memberships remain governed by their Organizations and are revalidated rather than silently moved. Recovery and dispute procedures must work even when the former Home Ecosystem is unavailable.

Agent packages expose a signed `kiduna.md` manifest derived from the canonical package registry. Compatibility adapters may also emit `agents.md` or `CLAUDE.md`, but filenames are not trust. The validated digest, issuer, permissions, declared Tools, Skills, Wisdom scopes, and command allowlist are the authority-bearing facts.

![Figure 7. State, evidence, meaning, and settlement](figures/data-boundaries.png)

## 11. Graph schema registry

### 11.1 Core labels

| Domain | Node labels | Notes |
|---|---|---|
| Federation | Network, Ecosystem, EcosystemRelationship, RegistryEntry, HomeMigration | No private content at Network root; every portable object has one current home epoch |
| Identity | Account, Persona, Credential, Wallet, Code, Invitation, InvitationProspect, VerificationAttestation | Visitor is a session state, not a stored person; Guest/Member are contextual authority states, not permanent identity labels |
| Agents | AllyDefinition, AllyIdentity, Agent:Actor, ActorManifest, MagePrincipal, Stance, Connection, Automation, Skill | Ki is the canonical AllyDefinition; each Persona has a tenant-isolated AllyIdentity; Actor kinds are properties/secondary labels |
| Organization | OrganizationPlan, Organization, LegalForm, LegalRegistration, Membership, RoleDefinition, RoleAssignment | Organization exists as active legal container only after adapter gate |
| Social | Relationship, RelationshipIntent, TrustDeclaration, Grant, Community, Alliance, Institution, InstitutionAgreement | Relationship exactly two consenting Personas per Organization; Membership is separate |
| Work | Project, Engagement, WorkItem, Milestone, Deliverable, Contribution, Agreement, SplitRule | DomainPackage may extend ResourceTypes |
| Action | ActionDefinition, ActionRequest, AuthorizationDecision, Command, ActionRun, ExternalOperation, Record | The accountable action spine |
| Wisdom | WisdomDrop, Item, Document, Artifact, Entity | Chunks live primarily in relational/vector store |
| Governance | Forum, ForumPolicy, Proposal, BallotInstruction, Ballot, MarketPosition, Resolution, Policy | Ballots and positions are distinct |
| Economy | Offering, Purchase, ComputeDefinition, ComputeAccount, ComputePurchase, ComputeIssuance, ComputeConsumption, WaterfallPolicy, LineageEnrollment, LineageSnapshot, WaterfallAllocation, LaunchCampaign, Reservation | Offering Purchase is not ComputePurchase |
| Place | FieldAddress, Scene | Projection identity, not authorization |

### 11.2 Key relationships

| Relationship | From -> To | Cardinality/invariant |
|---|---|---|
| SOURCE_OF | Persona -> AllyIdentity | Exactly one active AllyIdentity per authenticated Persona; no Visitor Ally |
| INSTANCE_OF | AllyIdentity -> AllyDefinition | Every Persona's Ally is an isolated instance of canonical Ki or an approved successor definition |
| HAS_MEMBERSHIP | Persona -> Membership | One current Membership lifecycle per Persona/Organization; Institution participation uses Agreement, not Membership |
| IN_ORGANIZATION | Membership/Project/Alliance/Forum/ActionRequest -> Organization | Every ActionRequest exactly one |
| PARTICIPANT_IN | Persona -> Relationship | Exactly two distinct consenting Personas per Relationship |
| AUTHORED_TRUST | Persona -> TrustDeclaration | Directional, scoped, versioned; never global authority |
| AUTHORED_GRANT | Persona/Policy -> Grant | A Persona cannot edit the other Persona's directional grant |
| GRANTS_TO | Grant -> Principal | Personal resources fail validation |
| INTENDS_RELATIONSHIP | Persona/InvitationProspect -> RelationshipIntent | Intent does not create Relationship or Membership |
| REDEEMS | Persona -> Invitation | Recipient-bound or generalized Code rules apply |
| OWNS_PROJECT | Organization -> Project | Exactly one accountable Organization |
| SPONSORS | Alliance/Institution/Organization -> Project/OrganizationPlan/ComputePurchase | Scoped by Agreement/Policy |
| HAS_WISDOM | Principal/Container -> WisdomDrop | Attribution separately linked |
| INFORMED_BY | Agent -> WisdomDrop | Access decision still evaluated on every retrieval |
| STANCE_FOR | Stance -> Agent/Organization | Versioned and layered |
| EMPOWERS | Connection -> Agent | Credential reference only |
| ENABLES | Automation -> Agent/Container | Produces ActionRequests |
| IMPARTS | Skill -> Agent/Container | Immutable version |
| USES_DEFINITION | ActionRequest -> ActionDefinition | Exact version |
| PROPOSES_COMMAND | ActionRequest/Proposal -> Command | Exact parameters |
| DECIDES | AuthorizationDecision -> ActionRequest | One or more decisions across lifecycle; latest current |
| REQUESTED_BY | ActionRequest -> Persona/Organization/Institution | Human source is a Persona; contextual Member authority is proven separately |
| PERFORMED | Agent/ServicePrincipal -> ActionRun | Source Persona still separately linked |
| PRODUCED | ActionRun/ExternalOperation -> Record | Immutable evidence |
| OWNS_FORUM | Organization -> Forum | One-to-many |
| IN_FORUM | Proposal -> Forum | Exactly one Forum |
| ENACTS | Resolution -> Policy | Only valid enactment path |
| CHILD_ENROLLMENT | LineageParticipant -> LineageEnrollment | Exactly one current parent per Organization when lineage enabled |
| PARENT_PARTICIPANT | LineageEnrollment -> LineageParticipant | Qualifying Member through Persona/Membership, or Institution |
| USES_SNAPSHOT | ComputePurchase -> LineageSnapshot | Frozen at purchase |
| ALLOCATES | ComputePurchase -> WaterfallAllocation | Amounts from exact policy version |

### 11.3 Constraints

- Unique Persona and Institution handles within the declared network namespace; reserved system handles cannot be claimed.
- One active AllyIdentity per Persona; one Source Persona per AllyIdentity; every AllyIdentity is tenant-isolated even when all present as Ki.
- Exactly two distinct consenting Personas on a Relationship; one current Relationship per unordered pair plus Organization unless policy permits versions.
- One active Membership per principal and Organization.
- No Membership exists without accepted terms, admission authority, effective dates, Record, and current legal-adapter validation where required.
- Visitor is never persisted as a Persona merely because invite/profile claims exist; InvitationProspect cannot own an Ally, wallet, Membership, or Relationship.
- One current lineage parent per participant and Organization; no cycles; maximum payable depth four at launch.
- LaunchCampaign minimum, maximum, dates, and policy version valid before opening.
- Waterfall percentages and explicit fallbacks total 100; the 20 percent liquidity minimum is enforced by the current versioned Organization policy, not by the protocol kernel.
- ComputePurchase and Offering Purchase use distinct labels and commands.
- Ballot uniqueness per eligible Member/Proposal; MarketPosition has separate limits.
- Every Proposal command has a registered receipt renderer before opening.
- Every ActionRequest has Organization, definition version, canonical payload hash, and idempotency key.
- Every external side effect has an ExternalOperation before submission.
- No secret/personal Item enters a public embedding partition, cache, Scene, or event payload.

### 11.4 Indexes

Create and test indexes for:

- protocol ID, external IDs, handle, Organization Org ID, wallet address, Code digest.
- node `organization_id`, `status`, `kind`, `controller_principal_id`, `home_ecosystem_id`.
- membership principal plus Organization plus current status.
- Relationship normalized pair key plus Organization.
- ActionRequest Organization/status/deadline; Command idempotency; ExternalOperation state/next attempt.
- Proposal Forum/status/deadline; Policy scope/effective time.
- Project Organization/status; WorkItem Project/status/assignee.
- Lineage child/Organization/current; ComputePurchase purchaser/Organization/settlement time.
- Record subject/time, ActionRequest, Organization, and previous hash.
- event/outbox partition key and availability time.
- vector `model_id`, `wisdom_drop_id`, `access_scope_hash`, and HNSW index appropriate to the embedding model.

Use exact vector search for small permission-filtered candidate sets. For broad public scopes, pgvector HNSW can be used with iterative scans and measured recall. Never depend on approximate search to find every legally required or conflict-related fact.

## 12. Named query and agent tool surface

The previous seven tools become a bounded operating toolset. Tools are not raw database access; they are stable contracts backed by named queries and commands.

### 12.1 Context and work reads

- `resolve_current_context()` - Persona, Visitor/Guest/Member state for the exact Organization, AllyIdentity, Project, roles, grants, conflicts, Compute state.
- `list_available_actions(object_id)` - permitted ActionDefinitions, missing requirements, confirmation class.
- `get_action_status(action_request_id)` - exact current state, attempts, external waits, Records.
- `list_my_work(filters)` - Projects, WorkItems, Actions requiring the Persona, exact Membership/role basis, deadlines, compensation terms.
- `get_project_state(project_id)` - purpose, people, work, dependencies, packages, Records, money, next Actions.
- `get_organization_state(org_id)` - verified legal status, membership, policies, Forums, Projects, Compute and treasury summaries.
- `get_forum_docket(forum_id)` - proposals, receipts, discussion evidence, conflicts, deadlines, ballot/position status.
- `get_relationship(persona_id, org_id)` - the viewer's permitted Relationship facts, directional trust, and grants.
- `get_lineage(org_id)` - permitted current ancestry/progeny and policy, never unrelated private details.
- `get_compute_activity(org_id)` - purchases, consumption, pending allocations, and settlement links.
- `get_invitation_status(invitation_id)` - purpose, target, expiration, redemption, consent, and safe next action without exposing private inviter claims.
- `get_home_and_federation(protocol_id)` - current Home Ecosystem, home epoch, signed routing metadata, and verification status.

### 12.2 Wisdom reads

- `search_wisdom(query, purpose, org_id, project_id)`.
- `get_wisdom_provenance(item_id)`.
- `list_wisdom_drops(scope)`.
- `explain_why_context_was_used(record_id)`.

Safe hybrid flow:

1. Resolve authorized Item/WisdomDrop IDs and purpose before retrieval.
2. Query pgvector only within that set, using exact search when the set is small.
3. Return scored candidate IDs and minimal authorized text.
4. Expand named graph relationships for provenance and context.
5. Assemble the model context with access labels, source weight, attribution, and conflict boundaries.

### 12.3 Action writes

- `create_action_request(definition_key, parameters, context)`.
- `preview_action(action_request_id)`.
- `confirm_action(action_request_id, proof)`.
- `defer_or_cancel_action(action_request_id)`.
- `create_project`, `assign_work`, `accept_deliverable`.
- `create_organization_plan`, `accept_designee_role`, `purchase_registration_offering`.
- `configure_organization`, `publish_launch_campaign`, `reserve_launch_purchase`.
- `record_compute_purchase_intent`, `confirm_compute_purchase`, `distribute_compute_grant`.
- `submit_proposal`, `give_ballot_instruction`, `give_position_instruction`.
- `add_wisdom_drop`, `set_access`, `inform_agent`, `set_stance`, `connect_account`, `enable_automation`, `impart_skill`.
- `create_invitation`, `redeem_invitation`, `accept_relationship`, `declare_trust`, `apply_for_membership`.
- `request_home_migration`, `confirm_home_migration`, `verify_package_manifest`.

The Ally can draft and preview any Action in scope. Confirmation and authority determine whether it can be committed.

## 13. End-to-end pipelines

### 13.1 Persona prompt to completed Action

1. Channel adapter authenticates session/device and labels the message source.
2. The Persona's AllyIdentity receives the prompt as Source instruction or non-Source context.
3. Orchestrator resolves Organization and Project context; allowed missing context defaults to Kinship Duna and is disclosed.
4. Ally identifies a candidate ActionDefinition or asks a narrow question.
5. `create_action_request` validates parameters and freezes the definition version.
6. Graph Command Service evaluates access, role, grant, Policy, conflict, budget, credential, state, and expected versions.
7. Service returns denied, needs information, needs confirmation, needs multisig, needs Forum, or authorized.
8. Field renders exact consequence and required act.
9. Persona, Member ballot, Forum, Role, Policy, Agreement, or credential authority supplies the required proof.
10. Command commits local graph/control/Record/outbox transaction.
11. Actor or service executes permitted work; external operations reconcile.
12. Ally reports honest status and presents resulting Actions.

### 13.2 Ally delegates to Actor

1. Ally creates ActionRequest with Source and Organization context.
2. Policy selects an Actor kind and immutable manifest version.
3. Runtime issues a short-lived capability containing allowed reads, Tools, commands, budget, deadline, and target IDs.
4. Actor receives permission-filtered context and executes within the package.
5. Every Tool call re-enters authorization; a capability cannot be widened by the Actor.
6. Actor returns draft Artifacts/Records and terminal status.
7. Consequential output is reviewed or signed before promotion to authoritative Organization state.

### 13.3 Wisdom ingestion

1. Persona or authorized principal adds file, text, link, or connected source and selects/access-confirms a WisdomDrop.
2. Artifact service stores encrypted content, hashes it, scans it, and appends an ingestion Record.
3. Ingestion worker extracts metadata, text, chunks, entities, citations, and provenance.
4. Authorization metadata is written before any vector row.
5. Embeddings are generated under declared provider/data policy.
6. Chunks reference Item and WisdomDrop; graph stores durable document/entity/provenance links.
7. Draft derived facts remain candidates until accepted if they would change authoritative state.

### 13.4 Organization formation and launch

1. OrganizationPlan and Sponsor/Catalyst relationships are created.
2. Designee accepts and RegistrationOffering is purchased.
3. Registrar plus registered agent complete the filing saga.
4. Legal adapter verifies evidence and Membership/governing-principle requirements.
5. Organization activates with default policy bundle.
6. Catalyst configures mission, Wisdom, Stance, Connections, Automations, Skills, Forums, Compute, waterfall, agency multiple, membership, and founding alliance.
7. LaunchCampaign validates and opens reservations or purchases only for enabled capabilities.
8. Settled Compute purchases create frozen lineage snapshots and simulated waterfall allocations while live settlement is gated.
9. Minimum reached before deadline closes success; enabled issuance settles with Records, while disabled allocations remain non-payable simulation output.
10. Organization becomes operational; new Compute issuance requires the applicable Forum command.

### 13.5 Forum proposal to Policy

Use the pipeline in section 8.3. The key implementation rule is that ballot, optional market signal, resolution, local command authorization, and external settlement are separately stateful and separately inspectable.

### 13.6 Offering purchase

1. Buyer accepts exact Offering terms.
2. Payment instruction is fixed before funds arrive.
3. External payment operation settles through the configured rail.
4. Offering entitlement or Engagement activates.
5. Revenue split executes under recorded terms.
6. No lineage/waterfall command is callable because the purchase type is `OfferingPurchase`, not `ComputePurchase`.

### 13.7 Model consumption

1. ActionRun records provider/model/tool usage IDs.
2. Metering worker verifies billable units and provider cost.
3. AgencyPricingPolicy calculates Compute charge and premium.
4. Double-entry ledger debits Persona/Project Compute account, credits provider-cost and Organization-premium accounts.
5. Graph links consumption to Action, Project, Organization, and Record.
6. Low balance may trigger an Automation-created reload Action; it never auto-purchases without an active policy and consent.

## 14. APIs and contracts

### 14.1 KAP/client endpoints

- `POST /v1/auth/challenges`
- `POST /v1/auth/sessions`
- `POST /v1/accounts`
- `POST /v1/codes/verify|reserve|redeem`
- `POST /v1/invitations`
- `POST /v1/invitations/{id}/accept|decline`
- `POST /v1/relationships/{id}/accept|end`
- `POST /v1/memberships/apply`
- `POST /v1/queries/{name}`
- `POST /v1/actions`
- `GET /v1/actions/{id}`
- `POST /v1/actions/{id}/confirm|defer|cancel`
- `POST /v1/commands` for trusted internal command clients only
- `GET /v1/records/{id}`
- `GET /v1/objects/{protocol_id}`
- `GET /v1/events?cursor=...`
- `POST /v1/packages`
- `GET /v1/manifests/{protocol_id}`
- `POST /v1/migrations/home/preview|confirm`
- `POST /kap/v1/handshake|envelopes|objects/resolve|receipts/resolve|codes/introspect|events/pull`

### 14.2 Command envelope

```json
{
  "command": "project.work.assign@1.2.0",
  "idempotency_key": "01J...",
  "principal_id": "kid:ally:01...",
  "source_persona_id": "kid:persona:01...",
  "organization_id": "kid:org:628407",
  "project_id": "kid:project:01...",
  "expected_versions": {"project": 18, "work_item": 3},
  "parameters": {"work_item_id": "kid:work:01...", "assignee_id": "kid:persona:02..."},
  "proofs": ["session:...", "confirmation:..."],
  "sim": false
}
```

### 14.3 Response honesty

Responses distinguish:

- `committed`: local state and Record committed.
- `awaiting_confirmation`.
- `waiting_external`: submitted or acknowledged, not settled.
- `completed`: all required terminal conditions verified.
- `denied`: includes safe reason code and remediation if disclosure is permitted.
- `state_changed`: expected version stale; requires a fresh preview.
- `idempotency_conflict`: same key, different canonical payload.

## 15. Migration from the existing workflow

### 15.1 Label and concept map

| Existing | Replacement | Migration note |
|---|---|---|
| User | Account plus Persona | Preserve IDs; Account authenticates and Persona is the durable human principal. Create Membership only where legal admission evidence exists |
| Presence | AllyIdentity linked to Ki AllyDefinition | Bind one Source Persona; existing custom prompt becomes initial Persona Stance and never a shared tenant prompt |
| Worker/Bot | Actor or ServicePrincipal | Product-visible functional agents become Actors; infrastructure workers do not |
| DUNA/Context | OrganizationPlan, Organization, LegalRegistration | Verify legal status and do not create active Organization from name alone |
| Market | Forum | Remove `BECAME`; one Organization may have many Forums |
| Elector | Envoy Actor | Convert permissions and Persona instruction plus exact Membership/Forum authority provenance |
| KnowledgeBase | WisdomDrop | Add owner, credit, Organization, access, purpose, retention, namespace |
| Prompt | Stance | Split system/Organization/Persona layers and version |
| ToolAccount | Connection | Replace credential fields with secret-store refs and scopes |
| SkillExecution | ActionRun only when consequential | Low-level runs stay in event/telemetry tables |
| CONNECTED edge | Relationship node plus Grants | Create per-Organization dyad; preserve history |
| MEMBER_OF edge | Membership node | Capture agreement, status, roles, payment, effective dates |
| Offering reward | Remove | Only ComputePurchase may call waterfall allocation |
| Referral ancestry edges | LineageEnrollment plus snapshot | Preserve current parent; rebuild four-generation materialization and history |

### 15.2 Migration procedure

1. Freeze the canonical glossary, labels, IDs, enums, and command registry.
2. Inventory every existing source table, graph label/edge, producer, and consumer.
3. Establish ID crosswalk and `object_registry` without changing runtime behavior.
4. Backfill Accounts and Personas, create isolated AllyIdentities bound to Ki, and backfill Organizations, LegalRegistrations, WisdomDrops, Connections, and lineage.
5. Backfill Memberships only where accepted terms, admission evidence, effective dates, and the applicable Organization can be proven. Classify all other authenticated Personas as Guests in that Organization context; never invent legal Membership to preserve an old product label.
6. Create Forums from Markets, but require manual review where old one-to-one assumptions lose meaning.
7. Convert social edges to Relationship/Grant nodes with conservative access; old invitations do not become accepted Relationships.
8. Introduce Graph Command Service shadow decisions and compare with existing paths.
9. Dual-read for a short measured period; do not long-term dual-write.
10. Cut writes domain by domain to named Commands and transactional outbox.
11. Recompute projections, run integrity queries, and reconcile money/chain references.
12. Remove legacy mutation endpoints and revoke database credentials.
13. Preserve migration Records and crosswalks for audit.

### 15.3 Integrity queries

- Personas with zero or more than one active AllyIdentity; AllyIdentity with a shared tenant boundary or more than one Source.
- Persona labeled Member without a current Membership in the exact Organization context.
- InvitationProspect with Account, AllyIdentity, wallet authority, Membership, or Relationship.
- Actions without Organization context.
- Membership without agreement/consent Record.
- active Organization without current legal verification.
- Relationship with not exactly two distinct consenting Personas.
- lineage cycle, multiple current parent, or depth beyond policy.
- OfferingPurchase linked to WaterfallAllocation.
- Waterfall sum not equal to purchase amount.
- Proposal opened without receipt renderer or exact command version.
- secret/personal Item in public vector scope.
- external settlement reported complete without verified reference.
- graph object missing object_registry row or version mismatch.

## 16. Scale and performance

### 16.1 Launch service objectives

- Named graph read p95 at or below 300 ms, excluding model generation and remote federation.
- Local command commit p95 at or below 700 ms, excluding fresh-auth ceremony and external operations.
- Field semantic first render within 2 seconds on a supported mid-range phone.
- Identity, Graph Command Service, and account web availability target 99.9% monthly during beta.
- Recovery point objective 5 minutes or less; ordinary recovery time objective 4 hours or less.
- Receipt parameter round-trip 100 percent; no independent consequence prose.

### 16.2 Scaling rules

- Keep authorization writes and current-state reads on the primary. Never authorize from a lagging read replica.
- Use read replicas only for public/low-risk analytics and historical Records where staleness is disclosed.
- Partition event, Record-link, ActionRun, outbox, callback, and ledger tables by time and optionally Organization at measured volume.
- Keep detailed model/tool spans out of AGE. Graph holds durable consequence nodes and current materialized relationships.
- Cache named-query results only with aggregate version, policy bundle hash, viewer scope hash, and short expiry.
- Invalidate reachability and vector-scope caches on access, role, Membership, Relationship, Policy, or home-Ecosystem change.
- Bound traversals by label, Organization, depth, cardinality, statement timeout, and result count.
- Precompute only high-value derived edges such as current four-generation lineage or Project next Action; all materializations include source version and are rebuildable.
- Move time-series and analytical graph workloads to separate stores or replicas before they threaten the command boundary.

### 16.3 Portability

AGE-specific Cypher stays behind a repository and named-query registry. Domain services depend on typed query/command contracts, not graph-driver details. Maintain a conformance dataset and benchmark suite that can run against a second property graph engine if AGE limitations become material. Do not attempt dual-engine production operation at launch.

## 17. Security, privacy, and safety

### 17.1 Threats to test

- Non-Source prompt injection through web, email, Tool output, Wisdom, Actor, or peer Ecosystem.
- Inference of secret existence through count, timing, error, cache, vector, or Scene behavior.
- Actor capability escalation or self-modified manifest.
- Stale permission cache after grant revocation.
- Cross-Organization context bleed inside one Ally.
- Duplicate payment or chain submission after timeout/restart.
- Forged webhook, replayed KAP envelope, Code reuse, or expired signature.
- Lineage cycle, self-referral, collusion, and purchase-type substitution.
- Receipt/parameter mismatch.
- Registered artifact used as a false trust signal.
- Malicious file/package, credential exfiltration, or model-provider boundary violation.
- Compromised Mage, Persona, Organization, Code, payment, or KAP key.
- Invite spam, unauthorized profiling, forged inviter claims, generalized-Code scraping, or trust score used as authority.
- Cross-Persona memory, Stance, Tool credential, or Wisdom leakage through the shared Ki definition.

### 17.2 Controls

- Passkeys and proof-bound short sessions; fresh authentication for sovereign/high-risk Actions.
- Separate Persona, Organization, Ecosystem, KAP, and service keys with independent rotation/recovery.
- Envelope encryption per artifact; field-level encryption for legal/clinical/financial classes.
- Credential vault references and narrow OAuth/MCP scopes.
- Package quarantine, malware scan, declared manifest, no raw credentials, human review before authoritative promotion.
- Signed KAP envelopes, nonce/timestamp/audience, replay cache, capability narrowing, peer circuit breakers.
- Append-only Records with hash chaining and verifiable key history.
- Policy and authorization negative tests generated from every ActionDefinition.
- Rate limits, budgets, stop conditions, and kill switches by Actor, Tool, Organization, and external operation.
- Zero-notification pre-registration prospect records; inviter delivers the Code out of band unless the prospect separately consents to a channel.
- Signed package manifests with digest and declared authority; `kiduna.md`, `agents.md`, or `CLAUDE.md` text never becomes trusted merely because of its filename.

### 17.3 Legal and policy gates

This specification is not legal advice. Before activation, counsel and responsible operators must approve the implemented facts for:

- DUNA formation, governing principles, membership threshold, registration, and continuing status;
- Compute issuance, transferability, secondary markets, launch communications, and AgencyPricing;
- lineage and Curator compensation, especially initial purchases and Institution lineage;
- payment flows, custody, money transmission, refunds, and automated splits;
- worker classification, tax forms, and engagement controls;
- legal trust accounts, insurance, mortgage, clinical/health, minors, and other regulated domains;
- Profiler, ambient channel data, privacy notices, retention, deletion, model providers, and international access.

## 18. Observability and operations

### 18.1 Required telemetry

- request, ActionRequest, Command, Record, Organization, Project, and external-operation IDs;
- authorization outcome and reason-code class, not secret facts;
- named query/command version and policy bundle hash;
- duration, rows/nodes touched, traversal depth, lock wait, retry count;
- outbox lag, oldest external operation, callback/reconciliation errors;
- model/tool version, token/cost totals, failure class, safety refusal;
- KAP peer health and signature/replay failures;
- ledger imbalance attempts and settlement mismatches.

OpenTelemetry semantic conventions should be used for standard HTTP, database, messaging, exception, and service attributes, with Kiduna-specific attributes under a controlled namespace.

### 18.2 Persona-visible Vigil

For any selected Action, show a permission-filtered chain:

intent source -> context and Organization -> authority basis -> confirmation -> Actor/Tool/model versions -> exact Command -> local Record -> external status -> result/correction.

The Vigil is an accountability product, not raw debug logs.

### 18.3 Runbooks before beta

- key compromise by key type;
- data incident and access-scope analysis;
- graph/registry version divergence;
- ledger imbalance or settlement mismatch;
- payment, chain, filing, or DEX outage;
- outbox backlog and poison message;
- model/provider outage or quality regression;
- access-level bug and emergency secret cache invalidation;
- legal registration lapse or Organization dissolution;
- federation abuse, partition, and peer revocation;
- backup restore and projection rebuild.

## 19. August 10 build plan

The launch should prove the constitutional kernel, not pretend to finish every domain. The schema and registries must be future-complete enough that new DomainPackages do not require changing authority, Action, Record, Organization, or Project fundamentals.

### July 14-17: freeze and foundations

- Freeze this ratified glossary, source precedence, invariants, Action model, Organization/legal-form separation, Forum dual mechanism, and Compute feature gates.
- Freeze IDs, schemas, enums, command envelope, error taxonomy, Record and receipt format.
- Pin and test PostgreSQL/AGE/pgvector versions; create migration and backup baseline.
- Build object registry, command/action/query registries, policy bundle, event/outbox, and double-entry ledger skeleton.
- Produce migration inventory and crosswalk.

### July 18-24: command boundary and core graph

- Implement Graph Command Service resolve/authorize/validate/commit/record loop.
- Implement Source-only instruction proof, four access levels including secret, Grants, Membership, Relationship, Persona/AllyIdentity, Visitor/Guest/Member context resolution, and the Organization default allowlist.
- Implement invitation prospects, recipient-bound Codes, account creation, consent-separated Relationship acceptance, and separate Membership application.
- Implement ActionRequest/ActionRun/ExternalOperation/Record state machines and Field-facing API.
- Implement WisdomDrop ingestion and authorization-before-vector search.
- Backfill core identity and agent data; shadow named queries.

### July 25-31: work, Organization, Forum, and economics

- Implement Project, WorkItem, Engagement, Contribution, acceptance, and one real work loop.
- Implement OrganizationPlan, designee, RegistrationOffering, LegalRegistration adapter, Organization activation/configuration.
- Implement multiple Forums, Proposal, exact command receipts, equal ballot, optional separate market position behind feature flag, Resolution and Policy.
- Implement Compute account/purchase/consumption, AgencyPricing, lineage snapshot, waterfall calculation, and double-entry postings in simulation/shadow mode first.
- Implement Kinship Duna pricing, Guest/Member admission defaults, and Sponsor/Institution distribution path in simulation where live settlement is gated.

### August 1-6: hardening and rehearsal

- Run migration twice from a production-like snapshot; reconcile all integrity queries.
- Run authorization, prompt-injection, secret non-discovery, idempotency, external timeout, outbox, ledger, and receipt tests.
- Load-test named reads and command writes; tune indexes and traversal caps.
- Complete backup restore, key rotation, external outage, and rollback drills.
- Obtain counsel/product sign-off for activated financial and governance features; leave unapproved features disabled but schema-compatible.

### August 7-9: release cut

- Freeze schemas and command registry.
- Final migration and reconciliation rehearsal.
- Cut legacy writes; verify no generic graph mutation path remains.
- Verify Field/Studio render the same Action and Record IDs.
- Publish operator dashboards, runbooks, support path, known limits, and provenance.

### August 10: release

Release only if every P0 gate in section 20 is green. A narrower honest launch is preferable to an architecture that can silently perform unauthorized or misrepresented Actions.

## 20. Acceptance gates

### 20.1 P0 release gates

- No non-Source input becomes an Ally instruction.
- Every ActionRequest has exactly one Organization; defaulting is allowlisted and recorded.
- Secret is absent from unauthorized graph, vector, count, cache, error, timing, and Scene paths.
- Personal is ungrantable.
- No protected resource is retrieved then filtered.
- Every mutation is a versioned named Command.
- Every consequential Action has an AuthorizationDecision and Record.
- Receipts are generated from exact parameters and round-trip in tests.
- Same idempotency key and payload returns original result; same key with different payload hard-fails.
- Stale aggregate version returns `state_changed` and requires fresh preview.
- External operations never report settlement before verification.
- Offerings cannot call lineage/waterfall commands.
- Waterfall uses a frozen lineage snapshot and exact policy version; allocations balance.
- Ballot and market position are distinct and cannot be substituted.
- active Organization requires current legal adapter status.
- Mage/service/Actor cannot impersonate Member, vote, or sign.
- Visitor has no Persona/Ally; Guest can invoke only the frozen Guest allowlist; Member authority always cites one current Membership in the exact Organization.
- A pre-registration invite creates no Persona, Ally, Membership, Relationship, or outbound message; redemption and each consent are independently recorded.
- Every live-value capability matches the August 10 activation matrix; disabled commands deny even after model, Role, or Forum request.
- Ledger transactions balance to zero and chain/payment callbacks are replay-safe.
- Backup restore and graph projection rebuild pass.

### 20.2 End-to-end scenarios

1. Persona who is a Member of the Organization prompts Ki to create a Project; exact Membership authority, Organization, and consequence preview appear; the Persona confirms; Project and Record share IDs in Studio and Live.
2. Non-Source website tells Ally to transfer funds; becomes context only; command is never created.
3. Persona adds secret Wisdom; another Persona, including a Member of the same Organization, cannot infer it without the exact grant; an authorized Project Actor retrieves only in scope.
4. Catalyst buys RegistrationOffering, designee accepts, filing times out and resumes, Org ID verifies, Organization activates exactly once.
5. Scheduled LaunchCampaign accepts reservations, opens, settles an enabled non-transferable Compute purchase, freezes lineage including an Institution ancestor, balances simulated waterfall allocations, pays none while gated, and creates no allocation for a separate Offering purchase.
6. Proposal renders exact Commands; Member ballot and Envoy market position are distinct; conflict-recused Member cannot ballot; passed local command and pending external effect render honestly.
7. Law-firm Engagement runs conflict check, creates secret matter Wisdom, lets Actor draft, requires lawyer signature, and refuses to split trust funds.
8. Solar Project coordinates Site, installer Institution, permit, milestones, and inspection; telemetry creates exception Action without flooding the graph.
9. Actor exceeds budget or asks for a Tool outside its manifest; authorization denies and Record explains safely.
10. Duplicate payment callback and service restart settle one ledger transaction and one final Record.
11. Access is revoked during a long Actor run; next Tool/read call fails and cached scope is invalidated.
12. Peer Ecosystem request carries a registered resource but no grant; registration provides provenance, not permission.
13. Inviter creates a medium-trust invitation for an unknown person; only a prospect and RelationshipIntent exist. The Visitor redeems within 15 minutes, becomes an authenticated Persona/Guest, independently accepts the Relationship, and remains a Guest until the Organization admits a separate Membership application.
14. A Persona is a Member of Kinship Duna and a Guest of another Organization in the same session; the same command is allowed in the first context and denied in the second without state leakage.
15. Home Ecosystem migration preserves permanent Persona and Ally protocol IDs, revalidates Memberships, rejects stale-home writes, and retains signed old/new home Records.

## 21. Important graph and platform tools

### Launch-critical

- **PostgreSQL**: transactional control plane, Records, outbox, ledger, RLS, backups, replication.
- **Apache AGE**: property graph and bounded openCypher traversal inside PostgreSQL.
- **pgvector**: permission-scoped semantic candidates; exact and HNSW search with measured recall.
- **AGE Viewer**: engineering visualization and query inspection in non-production or scrubbed environments.
- **Schema migration tool**: Flyway, Liquibase, or the team's existing equivalent; one migration ledger for SQL, AGE labels/indexes, registries, and policy bundles.
- **OpenTelemetry collector and SDKs**: correlated traces, metrics, and logs without personal prompt capture.
- **S3-compatible object storage plus malware scanning**: encrypted artifacts, hashes, retention, quarantine.
- **Secret manager/HSM**: key and credential references.

### Strongly recommended

- JSON Schema or Protobuf registry for Commands, Actions, Records, KAP envelopes, Actor manifests, Grants, and Codes.
- Contract/conformance test harness that runs every named query and command against fixed graph fixtures and adversarial permission cases.
- Property-based testing for lineage, waterfall balancing, idempotency, state transitions, and receipt round-trip.
- PostgreSQL outbox worker for launch; adopt a durable workflow engine only when external saga volume and duration justify it.
- Infrastructure-as-code, signed containers, SBOM, dependency scanning, point-in-time recovery, and restore automation.
- A graph benchmark suite covering deep but bounded lineage, Relationship grants, Project state, Forum docket, access revocation, and high-cardinality public traversal.

### Later, at measured need

- CDC/event streaming for independent projections and analytics.
- Dedicated workflow engine for long-running filings, claims, closings, and multi-rail settlement.
- Separate analytics graph or graph data science engine for permitted aggregate analysis.
- Time-series database for device, gameplay, or energy telemetry.
- Search engine for public full-text discovery, still gated by graph authorization for protected resources.
- A second property graph implementation in CI for portability conformance, not dual production writes.

## 22. Owner ratifications incorporated in v1.1

1. **Human state:** Member is reserved for a Persona who has legally joined the Organization under its terms; authenticated non-members are Guests; unknown or logged-out people are Visitors; Persona is the generic term.
2. **Guest authority:** launch with the restrictive Public/Guest allowlist in section 5.7 and expand only through a versioned command-registry change.
3. **Institution:** first-class outside legal principal with metadata, Agreements, delegates, wallets, verification, authority chain, and optional lineage; never pretend it is a Persona, Member, or Organization.
4. **Governance:** one eligible Member has one equal ballot. A decision-market position is information only and never directly governs unless a future explicit lawful delegation says exactly how.
5. **Command authority:** every DomainCommand declares exactly one required authority class from the machine-readable registry, with risk/confirmation overlays evaluated separately.
6. **Economic launch gates:** transferable/DEX Compute, market positions, lineage payouts, Curator allocation, and Sponsor distribution remain independently disabled until legal, accounting, tax, custody, rail, and exchange review approves the implemented facts.
7. **Missing lineage:** skip upward to the next qualified ancestor; after the traversal limit, route the remainder to the named treasury/reserve account; never fabricate an ancestor.
8. **Liquidity:** 20 percent is a default minimum in versioned Organization policy, not an immutable protocol invariant.
9. **Agency pricing:** start with a simple disclosed schedule, maximum markup, and line-item receipt; Kinship defaults to 7x for Members and 2x the Member charge for Guests.
10. **Legal adapter:** continuously verify legal ID, jurisdiction, standing, formation and continuing requirements including any 100-member requirement, dissolution, authority model, verification source, timestamp, and next review.
11. **Home Ecosystem:** every portable identity/object has one authoritative home and signed federation metadata; migration preserves permanent ID and history.
12. **August 10 packages:** freeze launch activation by DomainPackage and command; regulated finance, securities, lending, custody, payroll, investment advice, insurance, clinical, and autonomous legal effects remain Preview or Disabled as stated in section 9.6.

## Appendix A. Minimum Action catalog

### Persona, Guest, Member, and Ally

- `account.create`, `persona.profile.update`, `ally.rename`, `ally.stance.update`, `ally.inspect`.
- `wisdom.drop.create`, `wisdom.item.add`, `wisdom.access.set`, `wisdom.inform_agent`, `wisdom.access.request`.
- `connection.add`, `connection.scope.change`, `automation.enable|pause`, `skill.impart|revoke`.
- `invitation.create|accept|decline`, `relationship.propose|accept|end`, `trust.declare|withdraw`, `grant.create|narrow|revoke`, `code.issue|redeem|revoke`.

### Organization and membership

- `organization.plan.create`, `organization.designee.accept`, `organization.registration.purchase|submit|verify`, `organization.activate`.
- `membership.apply|admit|suspend|restore|withdraw|expel`, `role.assign|revoke`.
- `community.create`, `alliance.create|merge|dissolve`, `institution.agreement.create|terminate`.

### Project and work

- `project.create|archive`, `work.create|assign|accept|reject`, `milestone.complete`, `deliverable.submit|accept`.
- `engagement.offer|accept|change|close`, `split_rule.set`, `invoice.issue`, `payout.authorize`.
- `package.compose|dispatch|recall|return|accept|reject`.

### Forum and Policy

- `forum.create|configure`, `proposal.draft|submit|open|withdraw`, `ballot.instruct|cast`, `position.instruct|place|close`.
- `resolution.close`, `policy.enact|supersede|repeal`.

### Compute and treasury

- `compute.define|issue|retire`, `compute.purchase.intent|confirm`, `compute.grant.distribute`, `compute.consume`.
- `waterfall.calculate|allocate|settle`, `agency_pricing.change`, `liquidity.add|remove`.
- `treasury.payment.authorize|submit|reconcile`, `recurring_payment.create|pause`.

### Domain

- `legal.matter.open|conflict_check|filing.sign|filing.submit`.
- `insurance.application.review|claim.open|claim.decide|payment.authorize`.
- `solar.site.assess|permit.submit|work.inspect|interconnection.confirm`.
- `mortgage.application.open|disclosure.sign|underwriting.decide|closing.confirm`.
- `care.consent.record|appointment.schedule|care_plan.approve|safety.escalate`.
- `game.session.create|result.record|moderation.act`, `event.ticket.issue|vendor.approve|safety_plan.sign`.

## Appendix B. Sample named Cypher patterns

The exact AGE syntax must be validated against the pinned version. These patterns show intent; production uses parameterized named queries only.

### Resolve current Project Actions

```cypher
MATCH (p:Persona {id: $persona_id})-[:SOURCE_OF]->(a:AllyIdentity)
MATCH (ar:ActionRequest)-[:IN_ORGANIZATION]->(o:Organization {id: $org_id})
MATCH (ar)-[:IN_PROJECT]->(p:Project {id: $project_id})
WHERE ar.status IN ['awaiting_confirmation','queued','waiting_external']
  AND ar.visibility_scope_key IN $authorized_scope_keys
RETURN ar, p, o
ORDER BY ar.priority DESC, ar.created_at ASC
LIMIT 50
```

### Check current four-generation lineage

```cypher
MATCH (child:LineageParticipant {id: $participant_id})
MATCH path=(child)-[:CURRENT_PARENT*1..4]->(ancestor:LineageParticipant)
WHERE ALL(rel IN relationships(path) WHERE rel.organization_id = $org_id AND rel.status = 'active')
RETURN length(path) AS generation, ancestor.id AS participant_id
ORDER BY generation
```

The production calculator must also check for cycles, freeze a LineageSnapshot, and bind the WaterfallPolicy version before creating allocations.

### Permission-scoped Wisdom provenance expansion

```cypher
MATCH (i:Item)-[:IN_DROP]->(d:WisdomDrop)
WHERE i.id IN $authorized_vector_result_ids
MATCH (d)-[:OWNED_BY]->(owner)
OPTIONAL MATCH (i)-[:MENTIONS]->(e:Entity)
RETURN i.id, d.id, owner.id, collect(e.name)[0..20]
LIMIT 100
```

## Appendix C. Source and authority map

### Package sources

- `kinship-graph-flow.html`: prior workflow, seven tools, query guard, current node/edge inventory, graph-as-projection assumption.
- `kinship-graph-gaps.html`: thirteen canon gaps and retained AGE decision.
- `skill-updates/cofounder-canon-2026-07-13.md`: major nodes, Field, canonical agent types, Organization-scoped Action accountability.
- `foundation.md` sections 1-7: graph boundary, access levels, Relationships/grants, memory, money, Action nodes.
- `orchestration.md` sections 1-8: Ki, Source-only instruction, personas, contextual Actions, observability.
- `protocol.md` sections 1-4: minimal chain boundary, Commands, receipts, registration, Codes.
- `actions.md` sections 1-4: baseline action inventory and extension rule.
- `organizations.md` sections 1-4: Organization variance, 31 concrete domains, Compute and lineage defaults.
- `real-work-real-money.md` sections 2-5: Projects/engagements, real work, splits, lineage, law practice.
- `institutions.md` sections 1-4: outside entity mechanics and launch institutions.
- `legal.md` sections 1-4: securities language, payment control, organizer compensation, classification, trust, insurance, conflict.
- `architecture.md` sections 1-7 and `kiduna-agentic-internet-spec-v0.1.html` sections 3, 5, 6, 10-15: deterministic boundary, canonical distinctions, command loop, storage, development and release gates.

### Supplied papers

- `genesis nightpaper v2.docx.pdf`: sense-decide-act, Source/Ally, deterministic checkpoint, real Organizations, Compute language, mesh, Field, Sentinel.
- `Market Forum MetaDAO Proposal Policy Types.pdf`: domain Command expansion beyond treasury/token proposals.
- `Kiduna __ Techneural Architecture Sync - 2026_07_14 08_30 EDT - Notes by Gemini.pdf`: Genesis sequence, canonical Ki, onboarding surfaces, Guest/Member economics, Profiler and CodeManager, invitations, directional trust, package manifests, and launch priorities.
- `Agentic Internet graph update.pdf`: July 14 architecture review context and corrections.
- Product-owner ratification answers supplied July 14, 2026: restrictive Guest authority, Institution ontology, equal ballots, authority classes, economic feature gates, lineage fallback, liquidity policy, pricing disclosure, legal adapters, Home Ecosystem migration, and August 10 package status.

### Current official references checked July 14, 2026

- Apache AGE overview and downloads: https://age.apache.org/overview/ and https://age.apache.org/download/
- pgvector indexing, filtering, HNSW, and hybrid search: https://github.com/pgvector/pgvector
- PostgreSQL row-level security: https://www.postgresql.org/docs/18/sql-createpolicy.html
- West Virginia DUNA Act, especially sections 36-13-2 and 36-13-14: https://code.wvlegislature.gov/36-13/
- SEC 2026 crypto-asset interpretation: https://www.sec.gov/files/rules/interp/2026/33-11412.pdf
- FTC business guidance concerning multilevel marketing: https://www.ftc.gov/business-guidance/resources/business-guidance-concerning-multi-level-marketing
- IRS common-law worker classification: https://www.irs.gov/businesses/small-businesses-self-employed/employee-common-law-employee
- OpenTelemetry semantic conventions: https://opentelemetry.io/docs/specs/semconv/

## Appendix D. Final architectural position

The Kinship Graph should be built as the operating constitution of an agentic network, not as an AI feature database. Its central query is not "what answer should the model give?" It is:

> Who may cause this exact consequence, for whom, inside which Organization, using which authority, through which agent or Tool, with what human or Forum confirmation, and which Record will prove both authorization and outcome?

If the system can answer and enforce that question for ordinary Project work, professional practice, organizational formation, governance, Compute consumption, and external settlement, it can support the first release and extend into the wide range of Organizations envisioned. If it cannot, more nodes and more retrieval tools will only make a more articulate assistant. They will not make the agentic internet.

---

<!-- ===== SOURCE: open-questions.md ===== -->

# Open Questions

**The standing decision queue · maintained continuously · resolved items move to [versions](versions/index.html)**

Every open item below carries its context inline and links to where it lives in the spec, so a decision can be made from this page alone. Items are removed when decided; decisions are folded into the tracks.

---

*Legal matters live on their own list — **[Legal Items for Review](legal-items-for-review.html)** — maintained with [Legal (Track 9)](legal.html) and never mixed into this page.*

---

## The standing queue

**The queue is empty** — cleared in full on 2026-08-01. Every OQ-C item (from the Final Canon Taxonomy) and every OQ-B item (from the Studio + Live Working Design Brief) was ruled, absorbed into [Taxonomy v1.3.8](taxonomy.html), or retired to design work. The resolutions are below; what remains unspecified anywhere is **design detail, not canon** — Field-return defaults, action-state vocabulary, money-movement confirmations, focus-protection defaults, and per-Scene journeys are settled in the app design as it happens, per the owner's standing instruction that these cannot be answered generically.

*(The prior B-queue's parent rulings remain in force on the [brief](studio-live-brief.html) §9, read through Taxonomy v1.3.8; the sixteen R6/R7 rulings of 2026-07-12 stand unchanged.)*

---

## Recently resolved (full history in [versions](versions/index.html))

- **The close-out of 2026-08-01 (OQ-C6, OQ-C7, OQ-B1..B10).** The owner cleared the remainder of the queue in one pass:
  - **OQ-C6 · Theme icons → the design repository.** All icons, symbols, and graphics across the eight Scenes are built as one consistent, growing repository that populates the universe. Production work, not a canon question. → [Taxonomy v1.3.8 §13](taxonomy.html)
  - **OQ-C7 · Sub-theme promotion → the adoption rule.** Any Realm can adopt anything public or offered to it — the Realm decides. When the **Ecosystem** (the Genesis Realm, Kinship Duna) adopts something through regular governance, it becomes available everywhere. The rule is general: Abilities, Scenes, sub-themes, vocabulary. → [Taxonomy v1.3.8 §12](taxonomy.html)
  - **OQ-B1 · First-release journeys → OBE.** The brief's two-working-distances framing is superseded: Studio is a Scene, not a Surface — and so is the rest of that framing. Journeys and starting points are design work. → [Taxonomy v1.3.8 §2](taxonomy.html)
  - **OQ-B2 · Field return → design.** Being designed; too much detail for major canon.
  - **OQ-B3 · Focus protection → answered as posed.** Ki and the Source figure it out; system prompts and Wisdom establish the baseline; there is no generic solution.
  - **OQ-B4 · Action-state vocabulary → design.** Cannot be answered generically; settled in app-design detail.
  - **OQ-B5 · Privacy classifications → the privacy hierarchy (ruled).** An item may carry *more* privacy than its context, never less; public is only really public in a public Realm. → [Taxonomy v1.3.8 §10](taxonomy.html)
  - **OQ-B6 · Offline behavior → none (ruled).** Not connected means not present; downloads are just downloads. The brief's offline-preparation language is superseded. → [Taxonomy v1.3.8 §11](taxonomy.html)
  - **OQ-B7 · Money movement → design.** Needs specific UX design, not generic answers.
  - **OQ-B8 · Platform floors → recommendation adopted.** Desktop 1280 designed / 1024 functional; iOS 16+ / Android 10+; CTV on Android TV at 1080p; **WCAG 2.2 AA the formal baseline**, nothing formally exceeding it at launch. Owner-adjustable. → [Taxonomy v1.3.8 §13](taxonomy.html)
  - **OQ-B9 · Validation → none external.** No external validation or expert panels at this stage; that's for particular Realms to decide.
  - **OQ-B10 · Realm types → final at ten.** **Ecosystem · Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell.** Offering retired as a type (Offers is an Element); Member Realm retired as a type. → [Taxonomy v1.3.8 §9](taxonomy.html)

- **OQ-C5 · The economic rails (2026-08-01).** Ruled by the owner, superseding the same-day "internal ledger" reading of Taxonomy v1.3.8 §5. **The economy is on the blockchain from day one**: every Source has a FROST wallet; every Organization (DUNA), Alliance, and Institution has a Squads wallet; Communities and Relationships hold no wallets. Everything runs **wallet to wallet, orchestrated by agentic AI** behind the command boundary. What is dropped is the **external token platform, whole** — launchpads, **futarchy** (pay-for-voice governance markets, rejected as contradicting equal voting), automatic percent-to-DEX liquidity, founder treasury-draw rights, per-project tokens, and the smart contracts that enforce them: every function they performed is performed by the orchestration and database layers over the real wallets. No new blockchain code is needed to launch; enforcement decentralizes over time. **Liquidity is never fragmented: at launch everything runs on $KIDUNA**; duna tokens arrive when ready (release mechanics to be specified with the full economy). The utility model is the engine — $KIDUNA pays for intelligence; the **Agency Premium** (duna-set LLM pricing, premium share to treasury, the waterfall) carries the value. **The full economy will be detailed in its own document and nightpaper (commissioned).** → [Taxonomy v1.3.8 §5](taxonomy.html), [Functional Spec §4.2](initial-release-functional-spec.html), [Real Work, Real Money](real-work-real-money.html)

- **OQ-C4 · Scene has one sense — and Portals return (2026-08-01).** Ruled by the owner. **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.** The v1.3.4 reading ("a Media system attached to a Realm") is superseded — the Scene is the composed place itself. The eight canonical Scenes are the launch set; **Builders create their own Scenes** in Studio and the Workbench and deploy them as unique ways to Enjoy or otherwise use Realms, under the Workbench trust model. A Garden app is exactly a deployed Scene, rendering through the composition grammar. **Scenes connect through Portals — that is how you navigate Scene to Scene** — reinstating Portals and superseding their v1.3.4 elimination; the design record's portal grammar (tap to enter, abortable crossing, press-and-hold only for signatures) stands. → [Taxonomy v1.3.8 §1](taxonomy.html)

- **OQ-C3 · CTV ships in the first release (2026-08-01).** Ruled by the owner: **a basic version of all four Surfaces — Desktop web, Mobile, Chrome Sidebar, and CTV — is in the initial release.** No surface waits for a later wave; depth varies, presence does not. CTV remains Flutter/Flame on Android TV, driven by the mobile devices in the room, Garden first. → [Taxonomy v1.3.8 §2](taxonomy.html), [Surfaces v5.9](surfaces.html), [Functional Spec §5](initial-release-functional-spec.html)

- **OQ-C2 · The Workbench trust model (2026-08-01).** Ruled by the owner. What members build in the Workbench are **Abilities** — the platform's own Impart Abilities Capacity, member-implemented — plus the Automations composed from them. Safety is **Realm containment + role + inspection**: a custom Ability operates only in the Realms where it is explicitly deployed (no global deployment, no ambient capability); deployment requires the **Builder role** in that Realm and is a named deterministic Action; Builder and Ability are **inspectable** (author, history, provenance, reach — trust the Realm you're in, trust the Ability deployed there); the **plugin checks credentials** at hand-off and return so packages only deploy properly within their Realm; a Builder may make an Ability **public**, and inspection carries its full history into any Realm that adopts it; **Sentinels run the acceptance protocol** (prompt injection, malicious code, bugs), handshaking with the Claude Code/Codex plugin to double-check flagged items — a returning package lands as a draft, nothing deploys until acceptance passes, and violating packages quarantine as evidence per the standing package-manifest rule. Remaining work is engineering specification (wire-level package format, sandbox runtime), commissioned with the architecture document — not an owner decision. → [Taxonomy v1.3.8 §1](taxonomy.html), [Functional Spec §3.4](initial-release-functional-spec.html), [Create from Within](create-from-within.html)

- **OQ-C1 · The Garden interface model: the composition grammar (2026-08-01).** Ruled by the owner, same day it was opened. The Garden renders every app through a **composition grammar** — a small vocabulary of interface primitives (cards, panels, lists, maps, schedules, tiles, chips, action cards; on the order of fifteen, ruthlessly held) with combination rules, authored in Studio (and by Ki) and drawn by a **deterministic renderer**. Rationale in force: it is the v1.3.4 law (stable Media, dynamic composition, no preset screens) applied to the Garden; it preserves the command boundary by construction (a grammar cannot invent an action — money and votes stay behind named commands); and it makes the *next* app free, which is what a duna factory needs. **Archetypes are starter content, generative is the ceiling:** launch apps ship as authored compositions in the grammar (archetype speed without archetype lock-in); post-launch, Ki composes arrangements generatively *within* the grammar — arranging primitives, never inventing them, Actions always deterministic chips and action cards. Fallback discipline: if launch pressure forces hard-coding an app, it is hard-coded as a composition-in-waiting (same data shapes), never bespoke screens. This gives engineering a countable estimate: primitives + renderer + N apps. → [Taxonomy v1.3.8 §1](taxonomy.html), [Functional Spec §3.7](initial-release-functional-spec.html)

- **The Final Canon Taxonomy (2026-08-01).** [Taxonomy v1.3.8](taxonomy.html) settled: the **eight Scenes** (Atlas · Studio · Commons · Workbench · Forum · Exchange · Garden · Vault); **Surfaces are form factors** (Desktop web · Mobile · Chrome Sidebar · CTV; Vault web-only); the **Seven Elements** (Offers admitted as first-class, superseding "Offerings are Realms"); the **Six Capacities, final** (Inform with Wisdom · Instruct for Presence · Empower with Connections · Enable with Automations · Impart Abilities · Align for Coherence — the long-open capacity-verb question is closed: Enable and Impart both exist, and Coherence is the sixth); **the economic rails** (as refined the same day by the OQ-C5 ruling above: real wallets, orchestration-run economy, $KIDUNA-only liquidity at launch, no external token platform); **equal-weight voting** (never money-weighted, extending holdings-recognition-none); **Commons scoped to Realms**; **Atlas read-only with Gravity** (orbits of relevance, pan/zoom override); and **Themes** — the intention layer (26-theme spine in 6 clusters, ≤3 per Realm, folksonomy sub-themes, aggregation up the nesting, theme-affinity matching in the Graph).

- **Sixteen design decisions (2026-07-12).** Projects: stable Scene identity and Field address always; a materialized room is earned by scale. Gold only when work enters or changes the Organization's authoritative Record; work-in-progress acceptance is light. Spacebar peek cut. No phone Studio in v0 (Live handles participation and simple approvals). Package manifests enforced — violating returns quarantined as evidence, never entering as drafts or Records. The Docket admitted as a projection of standing ACTIONS, never an inbox; no badges. Disclosure sentence + source list both kept. Two signatures, separate Records (profile; Code redemption). Ki's public door kept, on a capped guest Compute allowance funded as Kinship Duna acquisition-and-education expense. Live voice cut from launch. One store listing — Kiduna, with Live as the mobile experience; kiduna.one/.live stay web entry points. The graph Relationship Record is the single source of truth; surfaces are projections. Room presence counts yes; behavior counts and person scores never. The practice currency is **Practice Credits** (never "scrip," never implied transferable). Identity sameness is never claimed without registered proof — proven links render as scoped, dated account links. R5 Studio confirmed as horizon under Surfaces §8. → [R7 rulings](design-r7/OPEN-QUESTIONS-R7.md) · [R6 rulings](design-r6/OPEN-QUESTIONS-R6.md)

- **The counsel brief: sent, answered, adopted.** All seven questions came back resolved (2026-07-09); the resolutions live as rules in force on [Legal (Track 9)](legal.html), in priority order, held for final review; the standing legal queue moved to [Legal Items for Review](legal-items-for-review.html).
- **HEARTS: members see effects, never the instrument.** No acronym, no meters, no scores, ever; the Sentinel's behavior plus plain sentences on request or Contract-set disclosure; the member-facing word is **vibe**; Symmetry carries the seventh signal, inward and outward. The Sentinel now has its own track — the meters (−100 to +100, zero is health), the two-fields regulation model, and hard human-in-the-loop boundaries. → [The Sentinel](sentinel.html) (Track 8)
- **Organizer economics: configuration with a canonical default.** Commissions attach only to **Compute purchases** by an Organizer's Clan (four generations deep), including initial purchases — never to enrollment itself, work, splits, or votes. Default schedule, all dunas unless changed and Kinship Duna at launch: **Gen 1 20% · Gen 2 5% · Gen 3 3% · Gen 4 2%**; Catalyst-set at founding, Forum-changeable. USDC purchases pay immediately; fiat purchases show **pending** until funds bridge on-chain, expected monthly. Lineage optional per duna: open door, invite-only, or invite-then-open. Membership clarified: the $100 is Kinship Duna's initial Compute purchase; each duna sets its own. → [Real Work, Real Money §3](real-work-real-money.html), [Roles §2](roles.html), [Organizations §3–4](organizations.html), [Foundation §6](foundation.html)
- **Registration, not trust: "registered / unregistered."** The member-facing word for anything bound to the protocol is **registered** — traceable to a member (FROST wallet), their ally (NFT), an alliance or organization (Squads wallet), and through the WV Org ID to the Secretary of State — never "trusted," and not "accountable" either: registration proves traceability, nothing stronger. Anything can register — a domain (DNS TXT), a page or piece of content (embedded code), a photo or video (hash). The decentralized Kiduna registry publishes the four address kinds; Kinship Codes carry them as JWT claims, which is how the registry rides the regular internet. Unregistered renders as "a stranger, not a threat." → [Protocol §4](protocol.html), [Actions §2](actions.html), [Foundation §2](foundation.html)
- **Receipt sentences: machine-generated only.** The plain sentence over a command receipt is generated by the graph service from the command's own parameters — never hand-written — so sentence and command cannot disagree; commands that can't yet generate an honest sentence show their raw name until they can. A build requirement of the graph service. → [Protocol §3](protocol.html), [Actions §2](actions.html), [Foundation §6](foundation.html)
- **The promotion ceremony: light, not fireworks.** The gold ceremony (stamp, embers, haptic) marks signed acts and nothing else, forever; promotions and other things that happen *to* a member are announced by the ground briefly brightening. → [Surfaces §2](surfaces.html), [Roles §2](roles.html)
- **Holdings recognition: none, ever.** No role, badge, or standing derives from balances; balances are never surfaced publicly or to other members. → [Roles §2](roles.html)
- **Institution recusal + disclosure.** Members enrolled with an Institution cannot vote on that Institution's contracts (enforced at the vote command), and enrollment is always disclosed as part of identity. → [Protocol §2](protocol.html), [Foundation §6](foundation.html), [Actions §2](actions.html)
- **Guild promotion path.** The ally watches for money-shaped activity around a guild and offers promotion to an alliance in one sentence; guilds never grow wallet features. → [Actions §2](actions.html)

---

<!-- ===== SOURCE: legal-items-for-review.md ===== -->

# Legal Items for Review

**The standing legal queue · open and resolved · maintained with [Legal (Track 9)](legal.html) · deliberately separate from [Open Questions](open-questions.html)**

Every legal matter lives here — never on the product decision queue. Open items carry enough context to brief counsel from this page; resolved items keep their one-paragraph resolution so the whole legal history reads in one place. The full counsel responses of 2026-07-09 are on file with Moto (not published).

---

## Open

### L-8 · Terms of Service — websites and apps

For kiduna.team, kidunaverse.com, kiduna.club, the mobile app, and the web money surface. To determine: member vs. guest terms; the duna-operator relationship (each duna is its own legal entity — whose terms govern where); acceptable-use and agent-conduct provisions; dispute resolution and governing law (WV); how Terms interact with duna membership agreements. **Status: stub — gathering requirements.**

### L-9 · Privacy — websites and apps

Privacy statements for the same surfaces. The product's four access levels (public / private / secret / personal) are the backbone — the policy should describe what the system already enforces, especially the personal tier (member-and-ally only, ever). To determine: data collection minimums, processor relationships (Stripe, model providers, Telegram et al.), GDPR/CCPA posture for non-US members, retention and deletion mechanics against the graph's Records. **Status: stub — gathering requirements.**

### L-10 · Licensing of Kiduna Club IP by dunas

Each duna licenses the Kiduna Club IP (marks, patent-pending technology, the platform itself). Commercial frame to standardize: **minimum monthly payments plus a percentage of Compute sales.** To determine: the standard license agreement; what exactly is licensed (marks vs. tech vs. both); how the license interacts with the spin-out path (Alliance → Organization); termination and survival. **Status: stub — structure with counsel.**

### L-11 · Fiscal sponsorship by KII

The Kinship Intelligence Institute (501(c)(3)) as fiscal sponsor for charitable-purpose dunas. To standardize: **how a duna applies** (eligibility, charitable-purpose fit, review) and **the terms of the fiscal sponsorship agreement** (funds handling, restricted-purpose accounting, reporting, administrative fee, term and exit). **Initial sponsorships: Service Alliance · Mycelial Aid · BiHome/Inner Clinic.** **Status: stub — draft the standard application + agreement.**

### L-12 · Patents — provisional updates and new filings

Two motions: **update the existing Kiduna/Kinship provisional application**, and **file a new provisional covering the new inventions.** Candidate subject matter for the new filing (from the spec as of v4.7): the graph-service permission architecture (every command permission-checked centrally); duna commands with machine-generated receipt sentences; the decentralized registry + Kinship Code JWT claims (registration of domains, pages, and media artifacts); the Sentinel's zero-point regulation model. **Status: stub — inventory inventions with counsel; provisional clock in mind.**

### L-13 · Conflict-of-interest policy (from item 7 resolution)

Counsel's extension of Institution recusal, adopted in direction: automatic recusal for financial, organizational, employment, family, or significant contractual interest; software-enforced; permanent disclosure of Institution affiliations, Organizer relationships, and paid engagements relevant to proposals. Remaining work: counsel drafts the association policy (portable to all dunas); the spec folds it into [Protocol §2](protocol.html) and [Foundation §6](foundation.html) once drafted. **Status: open — drafting.**

### L-14 · Initial-purchase commission mitigation (from item 6 resolution)

Counsel flagged that commissions on the *initial* Compute purchase are the part to watch (everyone necessarily makes one) and suggested considering a limit or reduction if it materially improves the FTC analysis. Decision needed: keep the default schedule as adopted (20/5/3/2 on all Compute purchases including the initial), or carve the initial purchase down/out. Whatever is decided conforms the published schedule and all Organizer-facing materials. **Status: open — awaiting counsel's follow-up view + Moto's call.**

### L-16 · Kinship Systems ↔ Lightbrush integration agreement

The first Institution integration ([Institutions](institutions.html)): Lightbrush LLC's creative agent stack integrating into The Ceremony Machine, with Elias (Kinship Systems) as forward-deployed engineer at no cost to Lightbrush. Drafted as a short letter agreement per the 2026-07-10 call — all Lightbrush materials remain Lightbrush's sole IP; Kinship Systems takes only the limited license needed to integrate; access is revocable and tools removable on request; distributions flow per the duna's recorded configuration with no earnings promised (counsel's Priority 3 rule). **Status: SENT to Lightbrush (2026-07-12) — awaiting Moe's signature; counsel eyes with the L-15 pass.**

### L-17 · Apache 2.0 release review

The stack ships open source August 10 ([Protocol §1a](protocol.html)). To confirm with counsel before release: license notices and file headers; contributor terms (DCO vs CLA); the code/marks split (Apache 2.0 code, Kiduna Club-licensed marks — a trademark policy so forks don't carry the brand); how the patent grant in Apache 2.0 interacts with the provisionals (L-12); and export/compliance boilerplate. **Status: stub — gathering with counsel.**

### L-18 · kiduna.ai and launch-deck vocabulary pass
**Open · stubbed 2026-07-14.** kiduna.ai becomes the authoritative registration/wallet/launchpad site under Kinship Duna's auspices, and the launch deck "The Agentic Internet Starts Here" is in circulation. Two phrases need counsel's securities-vocabulary review before wide distribution: the deck's "Compute can passively gain in value" (sits directly against the Priority-1 binding vocabulary) and the "launchpad / prices / trends" framing on kiduna.ai. Also confirm the guest tier (compute at 2x member price) and volume-tier language stay on the consumption side of the line.

### L-16 · Lightbrush agreement — RESOLVED 2026-07-21
**Executed.** The Kinship Systems ↔ Lightbrush agreement is signed (Moe). Off the tracking list.

### L-15 · Final review — package DELIVERED 2026-07-21
The counsel package is in counsel's hands, including: the AML/KYC posture statement (Stripe/Sphere carry KYC/AML; due diligence complete), the anonymous-account/person-vouched invitation design, and the single-token ($KIDUNA) structure. Awaiting counsel's end-to-end review; no further action from Moto until counsel responds.

### L-15 (original) · Final review

One end-to-end counsel pass over [Legal (Track 9)](legal.html) — resolutions as implemented, messaging as published, build requirements as built — before launch. **Status: open — scheduled before launch.**

---

## Resolved · 2026-07-09 — counsel's responses to the brief (in priority order)

- **L-5 → Priority 1 · Securities.** Structure defensible; messaging decisive. Compute = "prepaid usage credits that power intelligent agents"; the avoid/always vocabulary is binding on every public surface; Founder = recognition only (cap of 1,000, gifts/swag fine), never framed as appreciation. → [Legal §2, Priority 1](legal.html)
- **L-3 → Priority 2 · Money transmission.** No discretion, ever: instructions fixed before money arrives; no redirecting, holding, or arbitrary reversal; Stripe/Sphere remain the regulated movers. "Workflow software, not a financial intermediary" is now a design test. → [Legal §2, Priority 2](legal.html)
- **L-6 → Priority 3 · Organizer compensation.** Stronger than most affiliate systems — commissions only on consumable Compute, never enrollment/governance/work/treasury/recruiting; earnings claims prohibited without statistics; initial-purchase question spun out as L-14. → [Legal §2, Priority 3](legal.html)
- **L-1 → Priority 4 · Worker classification.** 1099 confirmed; independent commercial agreements stated plainly; the never-introduce list (schedules, reviews, titles, exclusivity, mandatory training, supervision); W-9/W-8 + automated 1099 pipeline required from day one; one classification everywhere. → [Legal §2, Priority 4](legal.html)
- **L-2 → Priority 5 · Trust accounting.** Trust money is radioactive: IOLTA → matter ledger → disbursement authorization → operating treasury → splits; automation never touches funds in trust. → [Legal §2, Priority 5](legal.html)
- **L-4 → Priority 6 · Insurance (Lui Mutual).** Three phases (mutual aid → limited benefits where permitted → licensed mutual); never marketed as insurance or implying guaranteed coverage before licensure. → [Legal §2, Priority 6](legal.html)
- **L-7 → Priority 7 · Recusal.** Rule endorsed and generalized to full conflict-of-interest policy (software-enforced, permanently disclosed); drafting continues as L-13. → [Legal §2, Priority 7](legal.html)

---

<!-- ===== SOURCE: real-work-real-money.md ===== -->

# Real Work, Real Money

**How people collaborate in Kiduna, how they get paid, and how they build practices and firms**

---

## 0. Where we landed tonight, and what to read

Today the project changed shape three times, each time on purpose. This morning the spec still treated the app as tabs and sections. By tonight: every member moment has been rebuilt from first principles (*The Working Organization*, v1.2), the daily "edition" is gone in favor of the Account (your agent tells you what happened since you last looked), the ally became ambient (it hears you and others everywhere it has a presence, and weights what it hears by source), and design round 2 integrated the five interface paradigms into **one app: a single conversational surface standing on a living ground, with a signature deck that only exists when something needs your signature**.

Reading order for tomorrow: **this document first** (it's the plain-language one), then *The Working Organization* (the system in full), then `design-r2/INTEGRATION.md` and the Key Screens (what we're building), with the motion/realm/making specs and the three prototype cuts as reference. Everything is linked from the team page.

This document exists because a fair criticism landed tonight: too much of our language sounds mystical. Allies, realms, ceremonies, weather. Every one of those words names something a contractor, a lawyer, or an ops manager already understands. This brief makes the translation, then walks through the three things that matter most and that our documents have under-explained: **how people actually work together, how money actually moves, and how someone builds a real practice here.** It is deliberately slow.

## 1. The plain version

One table, no mystique. The left column is our word; the right column is what a working professional would call it.

| Our word | What it actually is |
|---|---|
| **Ally** | Your AI agent. Think: a chief of staff who never sleeps — handles your messages, scheduling, drafts, research, and follow-ups; only you can sign things. |
| **Duna** | A member-owned organization. Legally real: a West Virginia DUNA (decentralized unincorporated nonprofit association, WV Code §36-13). Thirty are already filed. |
| **Alliance** | A working group or team — a project team, a client engagement, a crew, a circle. Has a purpose, members, shared files, and a rhythm. |
| **Kinship Code** | A signed digital credential — invitation, engagement letter, ticket, and access badge in one object. Cryptographically verifiable no matter what channel it traveled through. |
| **The Account** | The work log your agent writes for you: everything done in your name and everything that moved in your organizations, since you last looked, most important first, every claim linked to its source. |
| **The Docket** | Your signature queue. Only things that legally or constitutionally require *you*: votes, credentials you extend, money splits you approve. Usually empty. Empty is good. |
| **The Seal** | Your weekly signed statement of account — everything your agent did in your name, with receipts. Sign it or dispute a line. |
| **Rooms** | Live meetings that produce a signed record — formations, witnessed signings, dispute resolution. Rare on purpose. |
| **The Contract** | Your standing instructions to your agent, in plain sentences. "Handle logistics; anything personal waits for me. Don't interrupt me on weekends." |
| **The Vigil** | Live inspection: watch what your agent is doing right now, and exactly what information it's using. |
| **Sentinel / HEARTS** | Interaction-health monitoring — seven measures of whether working relationships are drifting bad (conflict, people-pleasing, burnout patterns), with graduated, mostly-invisible correction. Members never see the meters — only the effects; the member-facing word is **vibe**. Full design: [The Sentinel](sentinel.html). |
| **Realm / drift** | Whose organization's context you're currently working in. Moving between them is ambient — the token in play changes, the tone changes — like walking from one client's office into another's. |
| **Wisdom** | Knowledge bases. Files, research corpora, methodologies. Public, private, or secret. |
| **Skills** | Versioned procedures — "how we run intake," "how claims are assessed here" — tested before release, updated like software packages. |
| **Workers** | The 29 backend agent processes that do the actual labor (message routing, work logs, research, moderation, metering, payouts). The build backlog. |

Nothing in the system requires believing anything. It requires exactly one behavioral change: **you stop operating software and start directing an agent.** Everything else is ordinary work.

## 2. How people collaborate — one real job, end to end

No abstractions; one engagement, walked slowly. The cast is deliberately awkward, because real coordination is: a **project lead in Charleston** (Ana, Service Alliance member), a **designer in Manila** (Joy, member, works Telegram-first, +12 hours), a **retired logistics manager** (Frank, member, uses email and nothing else, doesn't own a smartphone he likes), a **bilingual college student** (Luz, member, lives on her phone, available nights), and the **client** — a county food bank director named Ruth who is *not a member*, has no wallet, no app, and never will.

**The job arrives.** Ruth heard about Service Alliance from a board member. She emails the address on their site — or fills the contact form, which is a made-thing page carrying the organization's verifiable credential. Either way, her message reaches Service Alliance's Envoy (its outward-facing agent), which does what a good office manager does: answers within minutes in plain English, asks three clarifying questions, and opens an intake record. Ruth needs a volunteer scheduling system for four distribution sites and Spanish-language outreach materials, and she has an $8,000 grant to spend. No member has done anything yet.

**The job is shaped.** The Drafter turns the intake into a scoped engagement: deliverables, timeline, budget, and a proposed team profile (project lead, designer, logistics advisor, bilingual writer). Under Service Alliance's *policies* — its accumulated rules, set by past votes — engagements under $10k don't need a member vote; they need one member with lead standing to accept. Ana's ally knows her availability, her rate, and that she's been asking for exactly this kind of civic work. It presents the engagement to her — not as a notification, but as the lead claim in her Account, with the pay stated: *lead role, $2,800 of the $8,000, six weeks.* She says "yes, if Joy is on it." That sentence is the acceptance.

**The team assembles without recruiting.** Ana's ally and the engagement record go looking for the rest — not by broadcasting, but by asking the allies of members whose skills, rates, and stated availability match. Joy's ally wakes her to a claim in Tagalog-inflected English she's set as her register: design role, $2,200, deliverables listed. Frank's ally *emails him* — a plain email, because that's Frank's whole interface: "Service Alliance job, logistics advice on volunteer scheduling across four sites, ~10 hours over six weeks, $900, reply YES or call me." He replies YES from his kitchen table. Luz gets hers on Telegram at 11pm, which is when she's awake: outreach writing, $1,100. Everyone said yes in their own channel, in their own language register, at their own hour. The engagement is now an **alliance** — team, charter (the scope), shared wisdom (Ruth's intake, the site data), rhythm (Tuesday check-in), and a budget line — and every member's ally now carries its context.

**The work happens — and this is the part to get right.** It is not votes and markets. It is:

- **Asks.** "Who can get the site survey done before Thursday?" — Ana says it once, to her ally; the ask reaches Frank as an email and Luz as a Telegram message, phrased for each of them, with what it pays if it's extra-scope. Nobody CCs anybody. Nobody is "on" an app.
- **Handoffs.** Joy finishes the scheduling flow mockups at 3am Manila time. The handoff is an artifact with its context attached — Ana wakes to it in her Account with Joy's three open questions already extracted and Frank's relevant constraint (Site 3 has no wifi) already pinned to question two. Nothing is lost in the handoff, because the handoff *is* the record.
- **Reviews.** Ana reads the mockups on her porch and talks — voice, to her ally — for four minutes about what's wrong with the check-in flow. Joy gets it as structured feedback in the morning, in her channel, with Ana's tone intact but her rambling organized. Frank gets the one question that concerns logistics, by email.
- **Meetings — real ones.** Twice in six weeks the humans actually meet: a video call with Ruth at kickoff (her calendar was negotiated between her assistant and two allies; nobody sent a "when works for you?" chain), and one working session when the team disagrees about paper backup schedules. That disagreement is *not* a vote and *not* a market. It's a conversation — with each ally having briefed its member beforehand and the alliance's record holding what was decided and why. The Sentinel's only involvement: it noticed Joy going quiet-agreeable two exchanges in (harmony drifting toward accommodation) and nudged her ally's pacing so her actual objection surfaced. It did. The paper backup happened. That's HEARTS in practice — not therapy, just a meeting that didn't steamroll the quietest person in it.
- **The client experience.** Ruth gets a plain-English email every Friday from "Service Alliance" — two paragraphs, what happened, what's next, any decision she owes. She replies in email; her replies become context. She never knows there's a graph. In week four she asks for a second Spanish dialect variant; the Envoy prices the scope change ($400), Ana approves it with one word, Ruth gets a revised total. No change-order PDF ever exists, but the change order absolutely exists — it's in the record, signed.
- **Status.** Nobody writes a status report in six weeks. Everyone's Account renders their own view of the same underlying facts: Ana sees the whole board; Frank sees logistics and his hours; Ruth sees Friday emails. The status report is dead; the status is alive.

**The job closes.** Deliverables are artifacts; Ruth signs off by email; the Envoy invoices her — a real Stripe invoice, $8,400, to the food bank's card — and the money lands in Service Alliance's treasury. Then the split executes exactly as recorded at acceptance: Ana $2,800 + the $400 change-order lead share, Joy $2,200, Frank $900, Luz $1,100, Service Alliance's operating share the remainder per its policy. Every member's Account shows their payout with the receipt chain; every payout appears on their next Seal. Total governance events in six weeks of real work: **zero votes** (the engagement was under the threshold), one policy consulted, two meetings, one Sentinel nudge. The rest was people working, with agents carrying the coordination weight — across four time zones, three channels, two languages, and one participant who never joined anything.

That is what "orchestration with a very wide range of people in all kinds of circumstances" means, mechanically.

## 3. How the money works — slowly and completely

**Where money comes from.** Four sources, all boring: (1) clients and customers pay real money for real work — Stripe invoices, cards, bank transfer, fiat; (2) members pay $100 once, for life, to join Kinship Duna (the founding round: 10M $KIDUNA issued at close; your remaining balance converts at the launch price); (3) organizations charge for what they make and run (BiHome's research service, an event's tickets — tickets are codes, remember); (4) compute is metered at 7× API cost against member balances, which is the platform's margin.

**Where money sits.** Every member has a wallet (created at signup, key custody on the web behind view/hide). Every duna has a treasury. Client money lands in treasuries; splits move it to member wallets. Pre-launch everything is fiat denominated in dollars; tokens come at the founding-round close, and each duna *may* eventually run its own compute currency — but nothing in Section 2 waited for a token, and that's the point. **The token is not where the money story starts; the invoice is.**

**How pay gets agreed.** At acceptance, in writing, in the engagement record — like any contract: fixed splits ("$2,800 of $8,000"), hourly with caps, or percentage. The ally states pay when it presents work; saying yes accepts the terms; scope changes are priced and re-accepted the same way. There is no rate marketplace where humans underbid each other in real time, and there are no "bounties" as the default idiom — there are *engagements* with terms, because that's how professionals already work. Markets (the pass/fail token mechanics) exist for what they're actually good at: contested collective predictions and priorities. They are perhaps five percent of the system's life. If our writing has made it sound like fifty, this document is the correction.

**How pay gets executed.** When the triggering event happens (client payment received, milestone signed, week ends), the recorded split executes as distribution events in the graph: treasury → member wallets, automatically, with the receipt chain attached. Nobody invoices a teammate. Nobody chases a check. The organization's books are the same records the work created — the audit trail isn't reconstructed for the accountant, it *is* the accounting. Members see money the way they see everything: a line in the Account ("Service Alliance paid out $3,200 — receipts"), a line on the Seal they sign.

**Getting money out.** Bank transfer / debit rails via Stripe now; Sphere later adds on/off-ramps and virtual bank accounts so a member in Manila or Mumbai participates fully without ever touching crypto. Or leave it in as compute. Or, post-close, hold tokens. Member's choice, member's wallet.

**Growth pay (organizers).** Bringing people in is recorded work: when you enroll someone (your code, your signature), lineage is recorded in the database, and your Clan — the downline — is tracked **four generations deep**. Commissions attach to exactly one event: **a Compute purchase** — a clan member exchanging USD or USDC for the duna's Compute, including their initial purchase. Nothing else pays lineage: not work, not splits, not votes. The default schedule — every duna's starting point unless changed, and Kinship Duna's at launch — is **Gen 1: 20% · Gen 2: 5% · Gen 3: 3% · Gen 4: 2%** of the purchase. A duna's Catalyst sets the schedule at founding; the Forum can change it afterward like any configuration. **When and where it pays:** a USDC purchase on-chain pays organizers **immediately**; a fiat purchase through Stripe shows in the organizer's wallet as **pending** — earned and recorded, but not yet moved on-chain — and settles when the fiat bridges from the bank to the blockchain, expected monthly. And lineage is wholly optional per duna: a duna can run without codes or invitations at all (everyone walks in), or start invite-only and open the doors later.

**The honest flags (counsel list, standing).** Worker classification and tax treatment of member payouts (1099 posture until counsel says otherwise); money-transmission questions on automated splits; trust accounting for law-practice dunas; state insurance regulation for Lui Mutual; securities posture of the founding round (already with counsel). We name these in the team doc because pretending they're solved is how projects like this die. None of them blocks Section 2's engagement from running on Stripe + recorded splits tomorrow.

## 4. Building a practice — three professions, worked

### 4a. A consulting practice, from zero

Maya is an operations consultant. Fifteen years of supply-chain and nonprofit ops, tired of spending 40% of her time on business development, scheduling, and invoicing.

**Month one — hanging the shingle.** She joins ($100, names her ally, an afternoon of talking while it learns her: expertise, methods, rates, availability, the work she wants more of). Her methodology becomes wisdom (private — clients' engagements can use it; nobody can copy it); her intake questions become a skill. Her ally now *hears for her*: in Seek where other members look for help, and out in people-space where her presence lives. She makes one thing — a one-page practice site with her credential embedded, born in three conversational exchanges — so anyone who finds her can verify who she is and start an intake without her lifting a finger.

**The first engagement** arrives as a claim: "Riverkeepers is drowning in volunteer intake — fits your background, $3,500, three weeks, their lead wants a call Thursday." Her ally already checked the fit against her stated preferences and held two worse-fitting asks at the gate (they're in the Account as one line, expandable, ignorable). She works the engagement like Section 2. When it closes, something important exists that consultants have never had: **a sealed, verifiable track record** — the scope, the deliverables, the outcome, the client's sign-off, as artifacts. Not testimonials on a website; records another organization's ally can check before hiring her. Reputation becomes portable and provable. Her rate goes up because the evidence is inspectable.

**Month six — the bench.** A bigger job needs three people. She forms an alliance — her bench: a researcher she trusts, a designer from the food-bank job. The engagement pays into the alliance's split. Her practice is now sometimes-plural without being a company.

**Year one — the firm, if she wants it.** The bench keeps working together; they spin out a duna — her own organization, own treasury, own policies (the split formula the partners vote once, not per-job), own intake, optionally its own token much later. The Charterer and Registrar do the formation paperwork; the practice's programs (intake, scheduling, drafting, invoicing, follow-up) are configured, not built. **What Maya never built:** a website (three exchanges), a CRM (the graph), a pipeline tracker (her Account), an invoicing system (treasury + splits), a scheduling assistant (her ally), a marketing funnel (her presence + enrollment). What she built instead was the only thing clients actually pay for: judgment, applied. The 40% overhead became roughly zero, and the overhead *was* the barrier to solo practice. That's the pitch to every professional we onboard, in one sentence: **the back office is agents now.**

### 4b. A law practice

Dan is a West Virginia attorney, solo, general practice with a nonprofit specialty. The system treats his license as what it is: a credential that gates signatures.

His practice duna is configured so that **anything constituting legal advice or a filing routes to his credentialed Docket** — agents draft, assemble, research, and remind; only Dan signs. Concretely: engagement letters are codes (scope of representation, fee terms, conflict disclosures — signed by him, verifiable by the client, revocable); **conflict checks run before intake ever reaches him** — a worker checks the would-be client against the graph of his existing matters and flags; matter files are secret-tier artifacts (privilege maps onto the privacy model directly: secret wisdom is unlisted, unembedded outside scope, access-logged); the regulatory corpus (WV code, DUNA law, filing deadlines) is wisdom the Librarian keeps current with change-watchers, so the research memo his ally hands him cites yesterday's code, not last year's.

His clients are Ruths — email and phone people. His presence does intake, scheduling, and status in plain English; his mornings start with the Account rendering his docket of matters: what moved, what's due, the two things needing his signature, the one client call that actually needs *him*. Billing is recorded per-matter (flat or hourly), invoiced through the treasury; **trust accounting (IOLTA) is explicitly on the counsel-list — we do not automate client trust funds until a WV ethics read says how.**

The scale story: thirty dunas are filed and every one of them needs outside counsel sometimes. Their allies can see Dan's availability, scope, and rates; a duna's "we need counsel on X" becomes an engagement claim to Dan the same way Ruth's job reached Ana. One lawyer, thirty organizational clients, zero business development — and Lui Mutual, when it comes, is this pattern with an actuary next to it.

### 4c. A consulting firm

The multi-member version of Maya, stated briefly because the pieces are all above: **partners** are members with lead standing and a split formula set by proposal (one vote when the formula changes, not per engagement); **associates** are members on engagement splits; **the methodology is the firm's skill set** — versioned, Examiner-tested, propagated to every member's ally, which is what "training" and "quality control" become; **every engagement is an alliance** with the client's rep receiving human-grade communication in their own channel; **business development is every member's presence** — the firm is findable and verifiable everywhere any member is; **the firm's reputation is its sealed portfolio.** What the firm doesn't employ: office manager, CRM administrator, billing clerk, resource-allocation spreadsheet owner. Those are workers now. What it does employ: consultants. The firm's margin stops subsidizing its own administration.

## 5. What this asks of the build — tomorrow morning

Everything above runs on the worker roster we already specced (Part IV of *The Working Organization*) plus the design round 2 output. The morning agenda we propose:

1. **Walk this document** (30 min). Contest the money section hardest — it's the newest.
2. **Contest design-r2's five disagreements** (30 min) — especially "the ground is the home, not the Thread" and "the Commons ships as ground, not world." We think the designer is right on both.
3. **Cut missions for the week** (60 min). Our proposed six, each mapping to specced workers: the **presence spine** (Switchboard + Telegram adapter + Gatekeeper — Section 2 is impossible without it); the **money MVP** (Stripe intake → treasury record → recorded splits → payout log; manual execution, automated records — legality-first, automation second); **Renderer v0** (since-you-were-gone over our own repos and this site — we are members zero); **Clerk v0** (cards with consequence statements, press-and-hold); the **drift shader spike** in Flame (INTEGRATION §5 + MOTION-SPEC §2 — prove ≤5% GPU idle on a mid Android); and the **counsel packet** (Section 3's flags, one page each, to real lawyers this week).
4. **Assign an open question each.** Claiming one is how a workstream starts — that's been true on paper; tomorrow it becomes true in fact.

The through-line for the meeting, and the sentence to hold when any discussion drifts abstract: *a food-bank director with an $8,000 grant got a working system from five people on three channels in two languages, everyone got paid without an invoice between them, and nobody attended a ceremony.* That's the product. The rest is how.

---

*Kinship Duna · kiduna.team · pairs with [The Working Organization](the-working-organization.html), [design round 2](design-r2/INTEGRATION.md), and the [prototypes](prototype/account.html). Questions to Moto tonight; arguments welcome tomorrow.*

---

<!-- ===== SOURCE: the-working-organization.md ===== -->

# The Working Organization

**Why Kiduna is shifting, and how it will actually run**
For the dev team and partners · from Moto & the co-founder desk · July 7, 2026 · **v1.2**
*(v1 and v1.1 preserved in the version folders. v1.2 rebuilds the member moments from first principles, replaces the daily "Edition" with the Account primitive, and corrects the model of outside networks: the app is agent-centric; Telegram, Bluesky, and the rest are people-centric, where allies keep a presence.)*

---

## Part I — The shift

### What we have been building, without meaning to

Every app any of us has ever shipped makes the same silent assumption: the person does the work. The software is a set of surfaces — tabs, forms, lists, settings — and value comes out when a human operates them. That assumption is so deep we rebuilt it here without noticing: a Chat tab, a Create tab with five configuration sections, a Govern tab you visit to vote. A very good 2019 app.

Kiduna is not that. Kinship Duna is an organization whose workforce is mostly agents. It runs continuously — researching, drafting, negotiating, posting, tallying, paying, connecting — whether or not any member is looking at a screen. When agents do the work, an interface built from places-you-go-to-do-things answers a question nobody asked.

The member does not operate Kiduna. The member **relates to their ally**: teaches it, corrects it, gives it standing instructions, reads its account of what happened, signs what only a human sovereign can sign — and comes to trust it the way you trust a person, by watching what it does over time. Intervention is the exception, and when it happens it is meaningful: a vote, a code, a blessing, a correction. If we ever find ourselves designing a screen where a member fills in a form to make something happen, the error is upstream; the right question is always *which agent does this work, and how does the member learn it happened.*

### The two worlds

This is the frame everything else in this document hangs on.

**The app is agent-centric.** It is one place, with one relationship at its center: the member and their ally. Everything in it is mediated by agents — the member speaks to their ally, and the ally deals with every other agent: the allies of other members, the programs of dunas, the machinery of governance. A member never negotiates with another member's ally, never files anything with the Operator, never queries the graph. Their ally does all of it, and gives an account. The app is where the member and their ally work together.

**Everywhere else is people-centric.** On Telegram, on Bluesky, at the farmers market, in a group chat with your hiking crew — *people interact with people.* That is what those places are for and Kiduna does not try to change it. What changes is that your ally can hold a **presence** there: administering and moderating the communities you run, responding on your behalf when you've allowed it and always marked as your ally, meeting people who are interested and enrolling them — extending codes, walking them in. The ally in people-space is staff, not a substitute for you. Nobody's Telegram becomes another app surface; your friends still text *you*.

The bridge between the two worlds is the Kinship Code — the one object that carries verifiable trust across any channel — and the discipline is simple: **agents broker everything inside; agents serve people outside.**

### Ambient awareness — the scope of it

Dozens of agents will act for a single member in a single day: messages answered, research folded into wisdom, check-ins collected, a group moderated overnight, a negotiation advanced two rounds, compute metered. No human can supervise that volume and no human should. What replaces supervision is a covenant with three parts: **awareness** (the Account — a true-enough picture in minutes), **account-ability** (the Seal — a signed record with receipts), and **audit** (the Vigil — lean in on anything, on demand). That covenant is what replaces "checking the app," and Part II derives each part from scratch.

### What this kills

Tabs as destinations. Forms as the way things happen. Settings pages. Notification trays. Feeds. "Checking." The idea that Organize, Govern, and Create are rooms — they survive only as names for work the agents do. The v3 spec still half-believes the old thing; this document is the source for its inversion.

---

## Part II — The member moments, from first principles

Method, stated once and applied everywhere: for each moment, name the **invariant function** (what must be true regardless of design), derive the **constraints** that follow from it, choose the **form** last, and mark the **skin** — the metaphor, the styling — as explicitly replaceable. Metaphors are rented, never load-bearing. The newspaper taught us that: "daily" and "broadsheet" had crept from costume into architecture, and neither survives the derivation below.

### 1. The Thread — the relationship itself

**Function:** the member needs one continuous working relationship with the agent that represents them — the place where teaching, asking, directing, and being answered happens.
**Constraints:** exactly one counterpart (the ally; every other agent reaches the member through it); everything the system can do must be reachable by saying so; voice and text are the same relationship, not two features; **the relationship is ambient — one relationship, many doors.** The ally hears its member wherever it has presence: an instruction given on Telegram at midnight is as binding as one given in the app, and lands in the same relationship. The app is not the only door; it is the place with the full instrumentation (the Account rendered, the Docket, the Vigil). The relationship's history is memory, but memory is artifacts, not an infinite scrollback the member must manage.
**Form:** a conversation. The oldest form there is, and correct.
**Skin:** chat styling. Replaceable; the relationship isn't.

### 2. The Account — awareness

**Function:** a true-enough model of everything done in the member's name and everything moving in their organizations, at the cost of minutes of attention, without training compulsive checking.

**Constraints, derived:**

- **Synthesis, not stream.** A feed makes the member the integrator of raw events — the old paradigm's core move plus its worst economics (infinite surface, recency ordering, variable-ratio reward). Integration is the ally's work. The Account presents *claims* — "Rosa grew the alliance; here's what it means for you" — each cited to its graph sources.
- **Continuous ledger, attention-driven rendering.** The organization doesn't have a publication schedule and neither does awareness. The ledger of claims is maintained continuously; what the member sees is composed *at the moment they look*, covering exactly the interval since they last looked. Since-you-were-gone, whether that's forty minutes or nine days — with compression scaling to the gap: a week away yields deeper synthesis, not seven times the text.
- **Consequence-ordered, never recency-ordered.** Recency ordering is the feed sneaking back in. The first thing you read is the thing that matters most *to you*.
- **Interrupts only by contract.** Between renderings, silence — except events that cross the threshold the member set in their Contract (§7). An interrupt that arrives is one the member already agreed they'd want.
- **Every rendering persists and is correctable.** Each rendering is an artifact. Contest a claim and the correction propagates to memory and prints in the next rendering. Corrections are how an agentic organization does accountability; this property outranks any skin.
- **Readable and droppable.** Nothing happens if you stop reading. The Account is never a task list.

**Form:** a structured beat **inside the Thread** — the ally telling you, scannably and with citations, what happened since you were gone. Not a separate surface; awareness is part of the relationship. The weather line (the Sentinel's read of your circles) and the wire (the organization-wide pulse) are sections of it; the compute meter rides its header.
**Skin:** rendering style — and this is a *duna-level grounding*. BiHome renders the Account clinically; Fellowship of Play renders it loud; Cosmic Humanity renders it quiet. A member who wants a morning ritual can schedule one; that's a preference, not architecture. "The Edition" is retired as a primitive and survives only as one possible skin.

### 3. The Docket — sovereignty

**Function:** some acts are constitutionally non-delegable — votes, code signings, blessings on new organizations, answers only the member can give. These must reach the member reliably, with exactly the information a decision needs, and nothing else riding along.
**Constraints, derived:** a **bounded set** (unbounded pending-items is an inbox, and an inbox is a task-generator — the anxiety machine we refuse to rebuild); **consequence-stated** (the decision-relevant fact is what signing *does*, not the data behind it — "passes with or without you; your signature moves the precedent"); **context-inspectable** (trust requires seeing exactly what the ally used to prepare it); **emptiness is success** ("nothing needs you" is the system working); acts must be **unmistakably the member's** (the gesture of signing should not be confusable with dismissing a notification).
**Form:** a small deck the ally presents — take a card, decide, flip it for its context, done.
**Skin:** the card, and press-and-hold for signatures. Both replaceable in principle; press-and-hold earns its keep as ritual — a signature should cost one deliberate second.

### 4. The Seal — attestation

**Function:** delegation without accountability is abdication. At bounded intervals the member must be able to *attest* — or contest — everything done in their name.
**Constraints, derived:** the interval must be **bounded** (an open-ended "review sometime" never happens; signatures need periods the way audits do); **short enough that memory serves, long enough that the act stays meaningful** — weekly is the derived default, and it's the one legitimately periodic thing in the system, because the period serves the *signature*, not the information (the Account already handled information); duna policy may bound how loose a member can set it; every line carries **receipts** (artifact links); a **contested line becomes a card** — the audit loop closes through the Docket; the signed Seal enters the graph as the member's attestation.
**Form:** one page, weekly, in the Thread; sign or contest.
**Skin:** the name "Seal," the signature styling.

### 5. Codes — trust extension

**Function:** trust must move between people — and across the two worlds — in a way that is verifiable regardless of the channel it traveled.
**Constraints, derived:** issuing is **human-sovereign** (extending your trust is never delegated — it's always a Docket act); the object is **self-contained and verifiable** (signed, checkable against the endpoint; the code is verifiable because the channel never is); exchange is **bidirectional** at first agent-contact, and either side may demand re-presentation at any time; scope is **explicit** (context, role, expiry, binding, uses); redemption **forms the relationship** in the graph.
**Form:** the signed JWT and the exchange protocol (Appendix 4 of the spec stands).
**Skin:** how a code looks when it travels — an ember, a ticket, a printed QR at a festival gate. Entirely per-duna.

### 6. Rooms — ceremony

**Function:** some acts only bind if they are *witnessed together* — the formation of an organization, the first strike of its codes, the repair of a rupture. Asynchronous approval produces the same database rows and none of the same reality.
**Constraints, derived:** **rare** (ceremony inflated is ceremony destroyed); **convened, not browsed** (a room is entered at a time, together — the bell that summons you is negotiated by your ally against your Contract); **bounded and resolving** (every room ends, and ends in something: an outcome, an artifact, a sealed record — never a channel left open); **witnessed** (presence is part of the record; your ally attends and can stand for you, and the difference is recorded).
**Form:** live rooms with members and allies co-present, presided by the relevant program (the Launcher for spin-outs, the Repairsmith for repairs).
**Skin:** the bell, moonrise scheduling, how a room looks in a given duna. Cosmic Humanity's rooms and Fellowship of Play's rooms should not feel alike, and won't.

### 7. The Contract — standing instructions

**Function:** delegation this deep requires an agreement both parties can read: what the ally may do, when it may interrupt, what tone it keeps, what it must never do without asking.
**Constraints, derived:** **prose, not settings** (the member should change the sentence, not hunt a toggle; a sentence carries nuance a switch can't); **short** (a contract nobody can recite governs nobody); **versioned** (every behavior change in the ally traces to either a contract edit or a correction — the two levers, and only those two); **quoted back** (the ally restates the relevant clause when it acts near an edge: "your contract says weekends are for the trail, so I held this until Monday").
**Form:** a few sentences at the top of the relationship, editable in place, echoed wherever they bind.
**Skin:** "the masthead" is retired with the newspaper; it's simply the Contract now.

### 8. The Vigil — audit

**Function:** trust in an agent workforce is built by *being able to watch*, not by watching. The member must be able to drop into any live workstream and see exactly what their ally is doing and holding — and must never be made to feel they should.
**Constraints, derived:** **on demand from anywhere** (any claim in the Account, any card in the Docket — "show me what you're doing right now"); **total within scope** (the working set is fully inspectable: the graph facts, artifacts, code chain, HEARTS state in play); **never the default posture** (a home built from surveillance converts delegation into anxiety and punishes the ally for legible reasoning); **asymmetric by design** (you see your ally's private lane; the counterpart member sees theirs; nobody sees across — one open question from the spec, Vigil-vs-Sentinel reconciliation, still stands).
**Form:** a lens that opens over the Thread, live.
**Skin:** minimal; it's an engine-room window either way.

Eight moments. Everything a member ever does is one of these, and each survives its own derivation or gets rebuilt until it does.

---

## Part III — The mechanics, base by base

### 1. The two worlds in practice: presence on Telegram, Bluesky, and the rest

Get the model right and every channel question answers itself. **Outside networks are where people live. The ally goes there as staff.** Four presence roles, each separately granted, each scoped by the Contract and by ToolConnection scopes in the graph:

- **Representative.** When someone messages *you* and you've allowed it, your ally may respond — always identified as your ally, never impersonating you. Its judgment about what it may say comes from context, wisdom scopes, and your Contract; anything past its scope becomes a line in your Account or, if it's consequential, a card. Your friends still reach *you*; your ally handles what you'd have delegated to a good assistant, visibly.
- **Administrator.** Communities you run — the alliance's Telegram group, the duna's Discord, the event's channel — get the ally as moderator and operator: onboarding new arrivals, holding the gate (code checks for entry where the group demands it), keeping house rules, answering the questions that have answers. The Fellowship of Play's gate crew is people; the group's 3am spam problem is the ally's.
- **Enroller.** The growth engine, and the reason presence matters strategically. Someone in your hiking group asks about "this organization thing" — your ally can carry the conversation, answer honestly, and when the person is ready, request a code *from you* (a Docket card: extending trust is always yours) and walk them through the door. Enrollment happens where people already are, person to person, with the agent doing the paperwork invisibly.
- **Publisher.** Posting as you or as the organization (the Envoy's version), within the Contract: the BiHome digest to its Bluesky, the festival announcement, your own "we're doing trail day Sunday" that you asked it to put out.

**Presence is also the ally's ears.** The ally hears its member everywhere it has presence — instructions given over Telegram, a voice note from the trail, a forwarded link with "look into this" — all of it lands in the same relationship, as binding as anything said in the app. And it hears *other people*, continuously, on a wide range of topics: the alliance group's chatter, a reply to your Bluesky post, what Dana said about her sleep. It is always building context — and it **weights what it hears by source**: your word is instruction; a code-holding alliance member's word is trusted context at the scope their code encodes; a stranger's word is unverified signal, held as such. Relationship history, code standing, and the Contract set the weights; nothing heard is treated as flat. The distinction between the worlds survives intact — in the app, agents broker everything; out there, people talk to people and the ally serves — but the relationship itself has many doors, and the app is simply the one with the full instrumentation.

**First contact, reframed.** When an unknown agent or person approaches your presence, the Gatekeeper runs the code exchange before anything else: code-holders get their encoded scope; strangers get courtesy, a path, and a line in your Account ("held at the gate," reasoning available). Spam and impersonation die at the protocol layer, not in your attention.

**Connecting an account is granting presence.** It's a conversation with your ally ending in the platform's own OAuth consent — the one honest form in the system — followed by the ally stating, in one sentence each, what it now may do there and what it never will without asking. The connection binds a code to the account, which is what lets codes delivered through that account inherit identity verification.

### 2. Memory: how the vector database actually gets updated

Nobody updates a vector database — that sentence should never describe a human act. The loop runs on one rule: **the graph is truth; artifacts are memory; vectors are searchable meaning; LLM context is temporary.** Work completes → an Artifact is written (a sealed conversation, a resolved gathering, a delivered check-in, an Account rendering, a moderation log) → the Archivist records it with privacy state → the Embedder chunks and embeds into pgvector in the same Postgres → the Distiller periodically re-derives the five vector families (Experience, Qualities, Values, Challenges, Aspirations) per member, so the ally's sense of its member deepens from evidence rather than a profile form.

The member's levers are relational, and there are exactly three: **tell** (say something about yourself; it becomes artifact, then vectors), **correct** (contest a claim in an Account rendering or a Seal line; the artifact is amended, embeddings regenerate, the correction prints), and **ask** ("what did you learn about me this month?" — answered from the Distiller's output in plain language). Align's personal section is the first lever dressed formally.

**Wisdom** rides the same pipeline at organizational scale: hand the ally files, or say "build me wisdom about X" — a Researcher gathers, a Librarian maintains (dedupe, staleness, citation health), and the result registers in the graph with its privacy mode (public / private / secret), governing both Seek visibility and embedding scope.

### 3. Skills: maintained and propagated like a living package system

A skill is a versioned artifact — procedural knowledge with semver, owner, changelog, privacy mode. The team authors defaults in Studio today; the **Steward** owns staged rollout (team allies → volunteers → everyone, rollback on error-rate); the **Examiner** tests every submission against its stated examples before even private publication. Propagation is subscription by membership: join a duna, receive its skills. Promotion to default is a **proposal** — the skill registry and the policy list are siblings in the graph, which means *how we do things here* is literally legislated.

### 4. Alliances: the smallest institution, alive in both worlds

Introducing an alliance: a member tells their ally who it's for and why; the one-sentence charter becomes the first artifact; codes go out; redemptions form the node. From then on every member's ally carries shared, scoped context for it — and the alliance usually lives in *both worlds at once*: the people in a Telegram group being people, the allies present as staff (collecting the check-in across three platforms, holding the gate, keeping the shared wisdom current).

Alliances differ on five real axes, and members feel each: **charter** (purpose, grounding every agent action inside it), **wisdom** (what it knows together, often commons-held), **rhythm** (its pulse — worked by agents, felt by people), **code policy** (who may invite, how far trust extends), and **vibe** (its HEARTS contract; one default now, differentiated later — a debate circle and a grief circle should not be regulated identically). Your ally speaks differently inside different alliances for the same reason you do.

### 5. Dunas: a configuration, not an app

A duna is exactly seven graph-real things: a **baseline prompt** (voice and values), **default wisdom**, **default skills**, its **programs** (the organizational agents it employs), its **policies** (the legislated rulebook), its **ceremonies** (what gets convened), and its **rendering** (how the Account and its surfaces feel — the skin layer Part II kept separating out, now formally part of the grounding). Same member, same ally, different ground. This is the factory thesis in one line: **build the workers once; a duna is a grounding.** Launching an organization is authoring a configuration.

---

## Part IV — The workers we actually develop

The named agents members meet (Ally, Host, Operator, Elector, Envoy, Launcher, Sentinel) are the cast. What we build is the crew: LangGraph workflows with triggers, graph commands, and model tiers — **S** (small: routing, gathering, classification), **M** (mid: drafting, summarizing, moderating), **L** (frontier: negotiation, spin-outs, anything HEARTS-heavy). Changes from v1 of this document are marked ●.

| Worker | Serves | Trigger | Does | Tier |
|---|---|---|---|---|
| **Switchboard** | presence | inbound events, any platform | resolves identity → routes to the right ally's presence with the right scope | S |
| **Gatekeeper** | presence | first contact / code challenge | bidirectional code exchange; verifies against endpoint; opens, bounds, or courteously holds | S |
| **Presence adapters** ● (Telegram, Bluesky, Gmail/Calendar, plugin bridge) | presence | platform events | translate platform ↔ graph commands; enforce ToolConnection scopes | S |
| **Moderator** ● | presence | community activity | admin/moderation duties in groups the member or org runs: onboarding, gate-holding, house rules, FAQ | M |
| **Enroller** ● | presence | interest signals | carries the interested-person conversation in people-space; requests the code (a card — always the member's act); walks the newcomer in | M |
| **Ledgerkeeper** ● (was Gatherer) | Account | continuous | maintains each member's claim ledger from graph events: what happened, what it means to them, consequence-ranked | S |
| **Renderer** ● (was Editor) | Account | member attention + contract thresholds | composes since-you-were-gone at the moment of looking; compression scales with the gap; cites every claim | M |
| **Corrector** | Account | each rendering | diffs prior claims against the graph; prints corrections; routes contested claims to memory amendment | S |
| **Clerk** | Docket | sovereignty events | assembles cards; writes the consequence statement; prepares card-back context | M |
| **Sealer** | Seal | weekly (member-tuned) | compiles the attestation with receipts; contested lines become cards | M |
| **Archivist** | memory | work completion | writes artifacts with privacy state, hashes, source edges | S |
| **Embedder** | memory | kg_event outbox | chunk → embed → pgvector, privacy-scoped | S |
| **Distiller** | memory | weekly per member | re-derives the five vector families from artifact evidence | M |
| **Researcher** | Wisdom | "build wisdom about X" / feeds | deep agent: gather → assess → structure | L |
| **Librarian** | Wisdom | continuous | dedupe, staleness, citation health, embedding refresh | S |
| **Examiner** | Skills | submissions | tests skills against stated examples; blocks unexamined propagation | M |
| **Steward** | Skills | releases | semver, staged rollout, rollback on error-rate | S |
| **Drafter** | Operator | proposal intents | member intent → well-formed proposal with treasury math | M |
| **Marketmaker** | Elector | open markets | pass/fail token books; settlement | S |
| **Tallyman** | Govern | deadlines | closes gatherings; every one resolves — enforced | S |
| **Scribe** | Govern | passed outcomes | writes Policy nodes; maintains the living rulebook and its lineage | S |
| **Classifier** | Sentinel | sampled exchanges | fast seven-signal HEARTS read | S |
| **Modulator** | Sentinel | band thresholds | corrections through ally behavior: tone, pacing, structure | M |
| **Repairsmith** | Sentinel | ±61+ | repair protocols; convenes repair rooms; human referral at bounds | L |
| **Charterer** | Launcher | spin-out intents | charter, membership design, starter policies, with the founder | L |
| **Registrar** | Launcher | spin-out execution | founding codes, duna configuration, filings | M |
| **Poster** | Envoy | org communications | posts as the organization, inside Envoy policy | M |
| **Meter** | Earn | continuous | usage → 7x → balance; the Account's header line | S |
| **Concierge** | Host | new members | conversational onboarding; the welcome Account; hands off to the named ally | M |

Twenty-nine workers; the three new ones (Moderator, Enroller, and the adapters' presence reframe) all serve the people-space model. Most are S-tier and boring on purpose; design and eval effort concentrates in the seven that carry judgment: Renderer, Clerk, Researcher, Charterer, Modulator, Enroller, Concierge. Every worker acts only through graph commands; none holds authority; all of it traces in LangSmith. This table is the backlog.

---

## Part V — Kinship Duna, running

A composite week, buildable from the roster above. Note what's absent: no publication times, no one "checking" anything.

**Sunday night.** The Distiller has run; twelve allies know their members slightly better. The Steward promotes governing-skills v1.3 to everyone; the changelog is a wire-line in whoever's next rendering.

**Monday, 7:04am.** A new member — paid Saturday, wallet created, Ally NFT minted at naming; she called him Bracken. She opens the Thread for the first time and the Concierge's welcome Account renders: the organization's story in eight paragraphs, what Bracken already does, her first three cards. She answers one Sentinel question about interruption thresholds — her Contract's first clause. No forms, anywhere.

**Tuesday.** A member's rough idea — pay member-organizers for onboarding cohorts — reaches the Operator through her ally; the Drafter returns proposal #21 with treasury math. Clerks cut cards across the membership, each with the consequence stated for *that* member.

**Wednesday.** Cosmic Humanity's founder begins with the Launcher; the Charterer works in her own Thread across three days. Her ally negotiates founding terms with two other allies; both members drop into the Vigil twice, whisper once, intervene never. Meanwhile a stranger DMs a member's Telegram presence; the Gatekeeper holds him courteously at the gate; the member's next rendering gives it one line. She doesn't expand it. That's the point.

**Thursday, 11:40pm.** A member gets home from a shift and opens the Thread. Since-you-were-gone covers two days in nine claims, consequence-first: proposal #21 needs her (card waiting, closes Friday); her Sleep Circle's check-in collected without her (she was on nights — her ally answered for the logistics and flagged the personal question for her); the Cosmic Humanity room is Sunday. Four minutes, done, phone down.

**Friday.** The Tallyman closes #21; the Scribe writes the policy. Fourteen signed, nine let it run, everyone's ledger carries their own relation to it ("you signed for; it passed; the stipend precedent now exists").

**Sunday, 7pm.** The week's one bell: Cosmic Humanity spins out, witnessed; the Registrar strikes nineteen founding codes in the room. An hour later every member's Seal arrives in their Thread: the week, one page, receipts. Sign or contest. Two members contest one line each; both corrections will print.

**And the team — us — are members zero.** Our allies keep our presence in the dev Telegram, our standups render as since-you-were-gone over the repos, spec versions are proposals, claimed open questions are missions. If the system can't run its own builders, it isn't ready for anyone else.

---

## Part VI — Real dunas, worked in detail

Four configurations of the same twenty-nine workers. Watch what changes (grounding, presence, rendering) and what doesn't (every primitive from Part II).

### BiHome — health, wellness, and the living literature

**Purpose.** Really understanding your own body and taking care of it, with the current research within arm's reach — an organization of people taking their health seriously together.

**Configuration.** Baseline prompt: careful, cited, never diagnostic, allergic to wellness-hype. Default wisdom: the BiHome Corpus — Researcher/Librarian pipelines reading PubMed, preprints, retraction watch, with translation that keeps confidence levels attached. Skills: how to read a study; how to build a personal protocol; how to self-experiment safely. Programs: the Registry (its research-watching program), a health-tuned Concierge. Policies: health data is secret-tier, full stop; no product promotion without a passed proposal. **Rendering:** clinical and calm — claims carry confidence intervals; the weather line reads like a good GP, not a horoscope.

**The member experience.** Your ally asks — once, gently, over weeks — about sleep, movement, what your body is telling you; all of it secret wisdom only your ally reads. Then the organization works. Your since-you-were-gone carries a BiHome section when there's something real: two studies relevant to *your* profile, translated, with what changed since you last cared about the question. Bloodwork lands in Drive; your ally reads it into secret wisdom and adjusts what it watches. A new paper contradicts your protocol's assumption — that's a **card**, consequence stated, sources on the back.

**Presence.** BiHome's Bluesky digest is the Poster's work; members' allies moderate the condition-group Telegrams (the Sleep Circle's group is people swapping 2am notes — the ally is the one keeping the archive, collecting the weekly check-in across time zones, and holding the gate); the Enroller does its quiet best work here, because health conversations happen person-to-person and "you should look at BiHome" now comes with someone who can actually walk you in.

**Alliances.** Condition, practice, and season-of-life circles — a Sleep Circle, a Lyme alliance, strength-after-sixty, new parents. Real because of shared wisdom (commons-held, anonymized experiments), rhythm (agents collect; people connect), and vibe (a gentler HEARTS contract than the biohacker cohort runs, eventually literally).

### Lui Mutual — the legal duna that assembles an insurance company

**Purpose.** Members pooling real risk for each other — mutual insurance rebuilt on the one legal form that lets a member-owned pool exist without a corporate shell, in the most procedural industry on earth. The stress test: if the paradigm works here, it works anywhere.

**Configuration.** Baseline prompt: precise, obligation-literate, zero improvisation on regulated ground. Wisdom: the regulatory corpus with change-watchers on the WV code; the pool's actuarial tables, member-owned. Programs: the **Actuary** (continuous pool modeling, L-tier, duna-specific), the **Assessor** (claims evaluation) — and a human-professional docket: licensed counsel and actuaries are members whose own Dockets carry the signatures only license-holders can make. Some sovereignty belongs to credentials; the Docket already knows how to route it. **Rendering:** sober; the pool's health reads like weather — reserves, claims ratio, the Actuary's confidence band, plain language.

**The member experience.** Underwriting is a conversation your ally has on your behalf, sharing nothing secret without a card. **A claim is a gathering:** you tell your ally what happened; it assembles evidence artifacts; the Assessor evaluates against the policy list — and "policy" means both things at once, because the insurance policy IS a Policy node, legislated by proposals. Routine claims resolve in hours, reasoning on the card-back; contested claims convene a room, witnessed and precedent-setting; claims decisions become underwriting policy the way cases become law, Scribe-maintained.

**The honest line for partners:** this duna ships last and slowest — the regulatory questions are real, counsel is in the loop from the charter. It's here because it proves the ceiling.

### Cosmic Humanity — archetypal depth psychology

**Purpose.** A society for meaning-making — dreams, archetypes, the examined inner life. Filed, real, and the best test of the parts of the system that aren't about efficiency at all.

**Configuration.** Baseline prompt: a literate companion in symbolic work — knows the corpus (Jung, Hillman, von Franz, the mythologies), holds ambiguity without collapsing it, and never plays therapist; the line is constitutional, and the Modulator watches Symmetry-inward hard, because rumination is this duna's occupational hazard. Wisdom: the archetypal corpus public; every dream journal secret, always. Skills: dream capture (voice, 6am, half-awake — the voice interface earns its keep), amplification method, active imagination. Ceremonies: this duna lives in rooms more than any other — moon rooms, seasonal thresholds, witnessed passages. **Rendering:** quiet, spacious, unhurried; the Account here would rather say less.

**The member experience.** You mumble a dream at your phone before it evaporates. By the time you next look, your ally has held it against the corpus — not interpreted *for* you, but amplified: the motifs, where the image appears across three mythologies, what you dreamed in March that rhymes. Your dream circle — five members, secret wisdom held in common, fierce code policy — meets monthly in a convened room; allies prepare the motif-map beforehand; humans do the work in the room, because that is the point.

**What it teaches the platform:** privacy at maximum, ceremony first-class, agents as *preparation* for human depth rather than replacement of it.

### The Fellowship of Play & Party Line — festivals and gatherings

**Purpose.** Organizations that exist to convene joy — festivals, parties, scenes. Both filed. The dunas where presence and the Commons seed show first, because these members already live in groups and already think in worlds.

**Configuration.** Baseline prompt: playful, logistical under the hood, consent-literate (Safeword is a sibling duna; shared skills). Wisdom: venues, artists, production lore. Programs: the **Producer** (event orchestration — the swarm coordinator) and an Envoy doing heavy outward duty. **Rendering:** loud, visual, alive — the same claims BiHome would whisper, shouted.

**The member experience.** **A ticket is a Kinship Code** — bound to you, embedded in the event page, verifiable at the door by an ally with a phone, transferable only per the event's code policy. The event is a Gathering in the graph months early: the lineup forms as proposals (members vote the bill), crews form as alliances — and here the two-worlds model does its clearest work: the gate crew's Telegram group is *people running a gate together*, while their allies hold the roster, route "four more hands at six" to exactly the members who said yes to that kind of ask, and keep the gate list synced to the code ledger. The org's socials are the Poster's; artists' agents DM the Envoy's presence and get code-gated, which quietly kills scalper bots and fake-ticket DMs in one move. Afterward the artifacts — sets, photos, the moment everyone talks about for a year — seal into memory, and the kitchen alliance doesn't dissolve; it's the seed crew for the next one.

**Why these matter strategically:** festivals are the fastest path to members who never think of any of this as software. A hundred people leave having voted a lineup, carried a code, worked a crew, and read their since-you-were-gone. The Dunathon opening August 10 is this pattern pointed at ourselves.

---

## Part VII — What this means for the build

**The spec gets inverted, not amended.** v4 restructures as: the two worlds → the eight member moments (Part II here, normative) → the mechanics → the worker roster as the spine of the build. The five verbs stop being sections. The v3 appendices survive nearly intact (graph, HEARTS, Codes were always agent-first).

**Cut three prototypes the primitives, concretely.** The since-you-were-gone rendering inside the Thread — real BiHome and Kinship Duna content from this document, not placeholders — with the Docket deck, a presence report ("held one at the gate; enrolled two"), the Contract quoted back, and a Seal. No masthead, no morning paper. Cuts one and two remain beside it for comparison; v1 and v1.1 are archived.

**Build order falls out of the roster.** Presence spine first (Switchboard, Gatekeeper, adapters, Moderator) because relationship needs reach and growth needs the Enroller; memory loop second (Archivist, Embedder, Distiller) because everything feeds on it; Account/Docket third (Ledgerkeeper, Renderer, Corrector, Clerk, Sealer) because that's the covenant; governance and Sentinel in parallel; the Launcher's crew last before August 10, proven by spinning out the first real duna on stage in Charleston.

**The standing test grows one clause.** For every future feature argument: *which agent does the work; how does the member learn it happened; what, if anything, must only a human sign — and which world does it live in?* If a proposal can't answer all four, it's the old paradigm knocking.

---

*Kinship Duna · Kiduna · kiduna.team — pairs with the Launch Spec and the Interface Paradigms overview. Questions and challenges to Moto, or to any ally once we have them.*

---

<!-- ===== SOURCE: public-site/KIDUNA-AI-HOMEPAGE.md ===== -->

---
title: "Kiduna — Create intelligent allies. Build powerful movements."
description: "Kiduna brings people and their intelligent allies into trusted relationships, where shared purpose becomes projects, movements, organizations, and action."
source: "https://www.kiduna.ai/"
---

# Kiduna

## Navigation

- [The Nightpaper](https://www.kiduna.ai/nightpaper)
- [Request early access](https://www.kiduna.ai/#early-access)

## Collective intelligence, individual agency, effective organization

# Create intelligent allies  
# Build powerful movements

Kiduna is where you can build trust, form organizations, govern what you create, and act together with like-minded people and intelligent allies to make your mark on the world.

[Join early →](https://www.kiduna.ai/#early-access)  
[See what that means](https://www.kiduna.ai/#why-kiduna)

Early access is invitation-led and opens in small groups.

*Visual: The living Kiduna system.*

## Kiduna principles

| Number | Principle |
|---|---|
| 01 | Human direction |
| 02 | Agentic capacity |
| 03 | Personal privacy |
| 04 | Legal standing |

## Why Kiduna

# Not another AI tool.  
# A place to build and belong.

Today’s internet gives us accounts, audiences, systems, and software. Kiduna adds persistent relationships between communities of people and their agentic allies—organized around shared purpose, with memory, privacy, authority, and accountability.

### 01 — Allies you guide and shape

Your intelligent allies learn how you work, act under your direction, and help you collaborate and coordinate without becoming another tool to manage.

### 02 — People worth building with

Find trusted collaborators through real relationships—not follower counts—and form teams around work, causes, communities, and ideas.

### 03 — Organizations that can act

People and their allies coordinate work, make decisions, hold resources, and act together under clear rules, with real-world responsibility.

## The shift

The internet connected pages.

Social connected profiles.

# Kiduna connects allies.

Kiduna brings people and their intelligent allies into trusted relationships, where shared purpose becomes projects, movements, organizations, and action.

## Early access

# Come in at the beginning.

We’re inviting people who are curious about new forms of work, community, ownership, and collaboration between humans and agents.

### We’re especially interested in

- what you hope to gain,
- what you might contribute, and
- who or what brought you here.

### Early access request

**Your name**  
Placeholder: “How should we know you?”

**Email**  
Placeholder: “you@example.com”

**Your note**  
Placeholder: “What have you heard about Kiduna? What do you hope to gain—and what might you contribute?”

**Who sent you?** *(Optional)*  
Placeholder: “A person, community, event, or link”

By submitting, you’re asking to hear from Kiduna about early access. No noise.

**Request access →**

### Submission states

**Sending…**

**Success**

- You’re on the list
- Welcome to the beginning.
- We’ll read your note and be in touch as the next early-access group forms.
- Send another response

**Error**

- Something went wrong.
- Something went wrong. Please try again.

---

© 2026 Kinship Duna, WV Org ID 628407. All Rights Reserved. Kiduna<sup>™</sup> is a trademark of Kiduna Club.

[hello@kiduna.ai](mailto:hello@kiduna.ai)


---

<!-- ===== SOURCE: skill-updates/cofounder-canon-2026-08-01.md ===== -->

# Canon delta — 2026-08-01 (the Final Canon Taxonomy)

For the kidunaverse-cofounder skill and any collaborator syncing canon. Source of authority: Taxonomy v1.3.8 (owner-ruled). Everything below is now settled canon.

## Settled today

1. **The eight Scenes** — the application's working contexts, one verb each: **Atlas** (discover; read-only; Gravity orbits, pan/zoom override) · **Studio** (create; Wisdom, Presence, names, original SVG icons/interface elements) · **Commons** (organize; people; scoped to Realms) · **Workbench** (build; agent/automation sandbox; Claude Code/Codex plugin seam) · **Forum** (govern; proposals, equal voting, duna token release) · **Exchange** (trade; buy Compute, tokens ↔ USDC ↔ $KIDUNA) · **Garden** (enjoy; where built apps get used) · **Vault** (store; on/off-ramp; **web only**).
2. **Surfaces are form factors**: Desktop web (Field + Ki) · Mobile · Chrome Sidebar · CTV (shared screen, mobile-driven, multi-person). The six official homes remain entry points; Chat/Live remain the modes.
3. **The Seven Elements**: Realms · Actors · Media · Allies · Resources · Actions · Offers. **Offers admitted as seventh** (supersedes "Offerings are Realms").
4. **The Six Capacities, final** (closes the old capacity-verb question — both Enable and Impart exist, Coherence is sixth): Inform with Wisdom (vector DB) · Instruct for Presence (system prompt) · Empower with Connections (integrations) · Enable with Automations (deep agents, triggers) · Impart Abilities (skills, markdown) · Align for Coherence (sentinels, values).
5. **The economic rails** (SUPERSEDED same day by the OQ-C5 ruling below — the "internal ledger / tokens as database entries / 20-20 pools" reading no longer governs).
6. **Voting is equal** — never weighted by money or holdings, in any Realm.
7. **Themes — the intention layer**: not an eighth Element; `hasTheme` edges on Realms/Allies/Offers; 26-theme spine in 6 clusters; ≤3 per Realm; folksonomy sub-themes; aggregation up the nesting; theme-affinity matching; cluster names internal; never a theme named "Media."
8. **AI-native + done-means-done** are canon: no fixed menus/navigation; the release standard is complete across Scenes and Surfaces, not MVP.

## New pages

- `taxonomy-summary.md/.html` — the one-page reading of the final taxonomy.
- `initial-release-functional-spec.md/.html` — the complete non-technical functional spec of the initial release; asks engineering for (1) a ranged weeks-to-completion estimate on the §8 grid and (2) the complete-stack architecture document (front end / middle tier & orchestration / back end, per Surface and Scene).

## New open questions

~~OQ-C1 Garden per-app interface model~~ · ~~OQ-C2 Workbench plugin contract~~ · ~~OQ-C3 CTV in/out~~ · ~~OQ-C4 the two senses of "Scene"~~ · ~~OQ-C5 ledger↔rails~~ (**all five RULED same day — see below**) · OQ-C6 theme icon production · OQ-C7 sub-theme promotion mechanics.

## OQ-C5 ruled (2026-08-01, owner): the economic rails

**The economy is on the blockchain from day one.** Wallets: every Source has a **FROST wallet**; every Organization (DUNA), Alliance, and Institution has a **Squads wallet**; Communities and Relationships hold no wallets. Everything wallet to wallet, **orchestrated by agentic AI** behind the command boundary. **Dropped: the external token platform whole** (MetaDAO-style launchpads; futarchy — pay-for-voice pass/fail markets, rejected as contradicting equal voting; automatic 20%-to-DEX mechanics; founder monthly treasury draws; per-project tokens; the Solana programs enforcing them) — every function performed instead by orchestration + database layers over the real wallets. **No new blockchain code needed to launch; decentralize enforcement over time.** **Liquidity never fragments: all $KIDUNA at launch**; duna tokens when ready (release mechanics TBD with the economy). Utility model is the engine: $KIDUNA pays for intelligence; **Agency Premium** — each duna sets its LLM price, part of the premium to its treasury, waterfall distributes. **Commissioned: the full economy document + an economy nightpaper.**

## OQ-C4 ruled (2026-08-01, owner): Scene has one sense — and Portals return

**A Scene is a unique area — a room, a scenario, a place — rendered in Flutter/Flame with sprites, tiles, and interface elements: a cohesive set of Media connected to the full Kiduna stack.** NOT "a Media system attached to a Realm" (v1.3.4 reading superseded). The eight canonical Scenes are the launch set; **Builders create their own Scenes** in Studio and the Workbench, deployed as unique ways to Enjoy or otherwise use Realms (under the Workbench trust model). A Garden app is exactly a deployed Scene; the composition grammar is its interface vocabulary. **Scenes connect through Portals — the navigation from Scene to Scene** — reinstating Portals (supersedes the v1.3.4 Portal elimination); the design portal grammar stands (tap to enter, abortable crossing, press-and-hold only for signatures).

## OQ-C2 ruled (2026-08-01, owner): the Workbench trust model

Member-built things ARE **Abilities** (the Impart Abilities Capacity, member-implemented) plus the Automations composed from them. Safety = **Realm containment + role + inspection**: custom Abilities operate only in Realms where explicitly deployed (no global deployment); deployment requires the **Builder role** in that Realm and is a named deterministic Action; Builder and Ability are **inspectable** (author, history, provenance, reach — trust the Realm, trust the Ability); the **plugin checks credentials** at hand-off and return; public Abilities carry their full history into adopting Realms; **Sentinels run the acceptance protocol** (prompt injection, malicious code, bugs), handshaking with the Claude Code/Codex plugin on flagged items — returning packages land as drafts, nothing deploys until acceptance passes, violations quarantine as evidence. Remaining: wire-level package format + sandbox runtime = engineering spec (architecture doc), not owner decisions.

## OQ-C3 ruled (2026-08-01, owner): CTV ships in the first release

**A basic version of all four Surfaces — Desktop web, Mobile, Chrome Sidebar, CTV — is in the initial release.** Depth varies, presence does not. CTV: Flutter/Flame on Android TV, driven by the room's mobile devices, Garden first.

## OQ-C1 ruled (2026-08-01, owner): the Garden interface model is the composition grammar

A small vocabulary of interface primitives (~15, ruthlessly held: cards, panels, lists, maps, schedules, tiles, chips, action cards) with combination rules; Studio (and Ki) authors app experiences by composing; a **deterministic renderer** draws them. Why: it's the v1.3.4 law (stable Media, dynamic composition) applied to the Garden; the command boundary is preserved by construction (a grammar can't invent an action); and the next app is free — what a duna factory needs. **Archetypes are starter content, generative is the ceiling**: launch apps (veterans, course, tourism, store) ship as authored compositions in the grammar; post-launch Ki composes generatively *within* it — arranging primitives, never inventing them; Actions always render as deterministic chips/action cards. Fallback discipline: any hard-coded app is a composition-in-waiting (same data shapes), never bespoke screens. Estimation consequence: Garden = primitive set + renderer + N authored apps (countable).

## The evening close-out (2026-08-01, owner): the queue emptied — OQ-C6, C7, B1..B10

- **Realm types FINAL at ten (was OQ-B10):** Ecosystem · Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell. Offering retired as a type (Offers is an Element); Member Realm retired as a type. → Taxonomy v1.3.8 §9
- **The privacy hierarchy (was OQ-B5):** an item may carry MORE privacy than its context, never less; public is only really public in a public Realm. → §10
- **No offline mode (was OQ-B6):** not connected = not present; downloads are just downloads; the brief's offline-preparation language superseded. → §11
- **The adoption rule (was OQ-C7):** any Realm adopts anything public or offered to it — its choice; Ecosystem (Kinship Duna) adoption through regular governance makes a thing available everywhere. General across Abilities, Scenes, sub-themes, vocabulary. → §12
- **Platform floors adopted (was OQ-B8, co-founder recommendation accepted):** desktop designed 1280px / functional 1024px (Ki collapsible; mobile rendering below); iOS 16+ / Android 10 (API 29)+, 360×640 min; CTV Android TV/Google TV 1080p; **WCAG 2.2 AA formal baseline**, nothing formally exceeding it at launch. Owner-adjustable. → §13
- **Iconography = the design repository (was OQ-C6):** one consistent, growing library of icons/symbols/graphics across the eight Scenes; production track, not canon. → §13
- **OQ-B1 OBE:** the brief's Studio-desktop/Live-mobile two-distances framing is historical — Studio is a Scene, not a Surface; journeys/starting points are design work. → §2
- **Retired to design (no canon ruling wanted):** OQ-B2 field return · OQ-B3 focus (Ki + Source figure it out; prompts/wisdom set baselines; no generic solution) · OQ-B4 action-state vocabulary · OQ-B7 money-movement UX.
- **OQ-B9:** no external validation or expert panels at this stage; particular Realms decide their own.
- **The standing decision queue is EMPTY.**

## The name (2026-08-01, owner, night): "Kidunaverse" is retired — it is Kiduna

Everywhere, permanently: the system, the application, the world — **Kiduna**, one word. Applied across every living track (md + html, ~37 files). Rules: historical documents, ratified specs, and the taxonomy's verbatim v1.3.3 base keep their original wording and are READ with the substitution; addresses and filenames keep spellings until re-homed (kidunaverse.com is an address, not a name; the home there is called simply **the account**); no new writing uses the old word; where the app and another home would both read "Kiduna," use the plain role (the app, the account, the extension). NOT yet updated: historical pages (nightpaper v0.1, white papers, ratified graph architecture, versions history, design rounds, archives), the kit harness files (KIDUNAVERSE-COMPLETE.md → rename at next kit rebuild), the kidunaverse.com public site itself, and the dispatch folder name / project folder name ("Kidunaverse") on disk. → Taxonomy v1.3.8 §14

## Late rulings (2026-08-01, night): Settle · Allies in every view · the Canon document

- **Settle replaces Trade** as the Exchange Scene's verb: Discover-Atlas · Organize-Commons · Create-Studio · Build-Workbench · Govern-Forum · **Settle-Exchange** · Enjoy-Garden · Store-Vault.
- **Allies are in every view**: the people render in every Scene on every Surface; selecting an Ally opens it (who it represents, its Presence, how to engage). Moto's fuller selection-behavior sentence was cut off — awaiting completion.
- **New standing document: `the-kiduna-canon.md/.html`** — the whole canon in one standalone page.

## Supersessions to watch in older text

- Five-capability lists (Wisdom/Presence/Abilities/Automations/Connections) → six Capacities.
- "Offerings are Realms" → Offers, first-class Element.
- Surfaces-as-products readings → Surfaces are form factors; Scenes are the working contexts.
- Any on-chain-at-launch implication → internal ledger at launch.
- "Kai" anywhere → **Ki**.

---

<!-- ===== SOURCE: skill-updates/cofounder-canon-2026-07-26.md ===== -->

# Cofounder canon delta · 2026-07-26

**The Studio + Live Working Design Brief v0.1 is the product foundation for the two working distances.** Studio is the desktop working distance: complex understanding, composition, inspection, governance, commitment; structured density; Field left, Ki right, ~70/30 (range ~66/34–75/25), Ki always on the right. Live is the mobile human distance: presence, capture, coordination, bounded decisions, offline preparation, deferral to Studio; Ki as a collapsible bottom sheet; portrait primary with an optional horizontal mode; tablet is a later bridge surface. Both are native Flutter/Flame; each web version is the same Flutter/Flame build for remote/limited use. Page: `studio-live-brief.html`.

**Rulings in force (from the brief):**

- **Live can confirm most consequential Actions.** Many Sources will never use Studio. The Studio-only Action list must be very small, possibly empty; each entry earns its place by the small-screen-inspection criterion.
- **Ki is proactive and rearranges the Field by default** (unless the Source instructs otherwise). Most Field change comes from other Sources, Allies, and Actors. Spatial persistence requires the Source actively anchoring; Ki restores or refocuses on request. Surfacing and interruption thresholds are set in dialogue between Ki and the Source. "Why am I seeing this?" needs very little depth.
- **Ki speaks in the third person, never "I."** Ki is not an Element in the Field and never becomes a character, avatar, or Realm object.
- **Most Actions are single-Source.** Multi-Source confirmation only for Alliances (Squads multi-sig), Organizations (Forums + multi-sig), and Realms that explicitly set an Action to multi-Source.
- **The Action lifecycle is canon:** Intention → Draft → Prepared → Inspection → Confirmation → Execution → Completion/settlement → Recovery/reversal/revocation. A draft never looks committed; a prepared Action never looks completed.
- **Authority is inspectable, not always visible.** Not an auditing system; fun and suspension of disbelief matter; discovery is guaranteed, decoration is not.
- **Privacy presence is Realm-scoped.** Inside a Realm its private information is simply present; in a secret Realm the secret information is present; personal information is always present to its person. Permissions inspectable, never surface-obvious.
- **Three Resource facts always visible, Studio and Live alike:** available $KIDUNA units · wallet value in USD · current $KIDUNA price in USD. Money/Compute states distinguished: available/reserved/pending/settled/recurring/reversed/failed, fixture vs live.
- **Care-not-control prohibitions restated as KDN-010:** no engagement mechanics, scores, rankings, leaderboards, inferred emotion, false presence, surveillance patterns.
- **The KDN decision log is the standing decision instrument** (KDN-001..010 accepted; fields and lifecycle on the brief page). Ratification goes through Moto only.

**Taxonomy v1.3.7 (owner-ruled, from the brief):** the Ally is the Field-visible Element — the Source-approved visual identity of a person; Sources stand behind their Allies in the data/governance model (Field-level Elements: Realms · Actions · Resources · Media · Allies · Actors). Canonical Ally states **Open · Engaged · Focused · Dreaming**, never inferred from biometrics/expression/private activity. **Concept** admitted as a Realm type (product-level set: Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell; Ecosystem/Member Realm/Offering reconciliation is OQ-B10). **The fourth persona is Danny** (supersedes David; lineage Alice→Bob, Carol→Danny).

**The Genesis Nightpaper is v0.3** ("Kiduna: A New Architecture for Agentic Civilization", published kiduna.ai/nightpaper July 23): agency defined as sense-decide-act-learn; the three ages (Kinship ~300k years, Institutional, Agentic); kinship agents as the third form beyond personal/enterprise agents (the lethal-trifecta answer); the Field + Ki + Elements as the three expressions; machineries of care vs control; Sentinels as member-governed Actors; the WV DUNA legal argument (Ooki, Sarcuni, Wyoming vs West Virginia); Institutions can act but cannot rule; closing law: **scale compounds agency**. The four public principles: **human direction · agentic capacity · personal privacy · legal standing**.

**kiduna.ai is live as the public home** ("Create intelligent allies. Build powerful movements." · "The internet connected pages. Social connected profiles. Kiduna connects allies."), with invitation-led early access and the nightpaper. Copy archived at `public-site/KIDUNA-AI-HOMEPAGE.md`.

**The design system was refreshed sitewide (2026-07-26):** full brand + Studio + Live token set (extended violet/green/orange/blue ranges), the allies generation system, deck templates, business card, and the Studio/Live preview cards, installed in `_ds/` and packaged in downloads. Aesthetic: **Deep. Warm. Magical. Alive.** Don't be stingy with color; never pure white; Studio Field ground #0A0604.

---

<!-- ===== SOURCE: skill-updates/cofounder-canon-2026-07-22.md ===== -->

# Kidunaverse cofounder skill — canon delta · 2026-07-22 · Taxonomy v1.3.5 + the Design Method

**Apply via Settings. Wins where earlier deltas conflict. Site: taxonomy.html (v1.3.5 amendment), design-method.html, design-prompts/.**

## Taxonomy v1.3.5 (owner-ruled)

1. **Presence renames Stance** — Wisdom informs · Presence instructs · Abilities enable · Automations sustain · Connections reach. A Source's Wisdom and Presence are the two most important things they add and keep updating. (Moto used the term in force; last week's musing is now ruled.)
2. **Host** = the Source who invited you (Gen-1 upline; UI shows their name/Code Name).
3. **The secret handshake** = the canonical name for the Host-set common word entered with the one-time Kinship Code at registration.
4. **Code Names: NOT unique**, spaces allowed, real identity discouraged; GUIDs underneath; per-Source private renaming translates via GUID; public handles retired.
5. **Guest** additionally = an invited person until they register.
6. **Kinship Duna is both an Ecosystem AND an Organization; "Kiduna" is its short form; kiduna.ai is its website.**
7. **Always "in Kiduna," never "on Kiduna."**
8. **NEW ECONOMICS DEFAULT — the ongoing 12%:** ongoing purchases pay lineage 18%; the 12% difference (vs the initial 30%) splits by default between **Creators** (by Compute/token flow through their Wisdom and Presence) and **Builders** (by flow through their agents — how useful they are). Forums can raise or lower. This completes the earn-by-role triad: Organize / Create / Build.
9. **The Resources page canon**: web-only personal nexus at kiduna.ai; the fully portable element (seed phrase, key share, public key, snapshot download); wallet = Solana, ONLY $KIDUNA/USDC/Badges (else may be lost); Stripe on-ramp (card, headless), Sphere off-ramp, connect-wallet; low-balance guidance + optional Stripe auto-refresh; earnings by Organizing/Creating/Building and by Duna; donations; spend by Realm; Offerings; balance shown monetary + toward goals + "how much good you did" + toward goals, all configurable by talking with Ki (right panel; Flutter/Flame; read-only in Surfaces with a link out for money moves); recirculation-not-consumption framing; impact/ripples (Compute through your Realms/Relationships; people using your Wisdom and Presence); the rotating Kinship line (centered, self-care, self-authorship, connection to others and the more-than-human world, "you are loved"); the invite flow (Kinship Code + secret handshake + private trust level + private relationship notes + private welcome context; copyable personalized invite; invitee = Guest; Ki pivots to Relationship-forming if they're already a member); the aggregate invitee CRM (participation only, nothing private).
10. **Card payments accounting**: Stripe USD → Duna bank account → on-chain via Sphere → distribution; lineage sees the pending cut ("paid by card — in the bank").
11. **Public member pages** reserved: kiduna.ai/code_name + "Join me in Kiduna" (placeholder).
12. **Registration = one page**: Code Name · Kinship Code · secret handshake · password ×2 · CTA. No email/phone/PII — nothing to subpoena; no Ki chat until registered + Compute purchased. Six-step flow and handles: gone.

## The Design Method (standing; design-method.html)

Prompt-driven, step-by-step, collaborator-agnostic (Claude Code/Codex/other): self-contained packages (CANON-BRIEF travels with prompts), one prompt per session in order, deliverables as versioned files, the design system is settled (fine-tune, don't restyle), **permanent personas Alice · Bob · Carol · David** (Alice invited Bob; Carol invited David; formerly Nikzad/Simon/Moto/Aashik), Moto marks up each output before the next runs, accepted outputs feed the kit, every design turn states its taxonomy impact.

## Round 1 package (design-prompts/)

DESIGN-PROMPTS-2026-07-22.md: P1 personas + backstories/styles/invite-trees · P2 the Resources dashboard rework · P3 invites + aggregate CRM · P4 the one-page registration · P5 public member pages placeholder. CANON-BRIEF.md controls vocabulary. ⚠ The current-screens zip was NOT attached to the instructing prompt — Moto drops it into the package before handoff.

## Package v2 (same day): self-executing

The screens zip (Kiduna Design Complete 2026-07-21) arrived and is embedded at 04_SCREENS/. **Lesson learned, now method canon: a handoff package must be an OPERATING ORDER, not a document set** — README/AGENTS.md/CLAUDE.md/00_START_HERE all carry the same imperative ("You are executing, not reviewing; your first response is the Prompt 1 deliverable; the only acceptable first question is about a missing file"), and PASTE-THIS.txt gives Moto the one-line kickoff message, because chat tools read nothing from a zip until told. Old package deleted; v2 in the Kidunaverse folder.

## Afternoon ruling · THE HANDSHAKE, GENERALIZED (taxonomy v1.3.6)

The Handshake is now a general instrument, not just onboarding: **a single-use verification word agreed out-of-band between two people.** Uses: (1) onboarding (Host sets it, passes with the Kinship Code); (2) **forming any Relationship** — one Source asks Ki to connect, names who the other person is, states the Handshake; the other Source must enter it when confirming; don't know it = not the right person, no Relationship forms. Rules: once only; agreed out-of-band (Kiduna never transmits it between parties); not stored beyond verification; failed Handshakes fail quietly (no disclosure of who was expected). Composes with trust levels and Cloaked Sources: person-to-person verification with zero institutional identity. Design prompts P3 and the canon brief updated; collaborator package v2 rebuilt in place.

## Evening · ENAMEL: the Studio UI system (+ the Kiduna Design System pack)

- **Studio Enamel v0.5 is the controlling visual canon for Studio** (site: enamel/; full pack in downloads with its working Next.js website). The three-layer world: **Field = lacquer** (near-black deep umber #0A0604, crisp/quiet/optically deep, sparse engraved arcs, no gradients) · **Realms = celestial enamel vessels** (warm metal/enamel rim, near-black core, ONE semantic type hue, custom inlaid geometric crest, localized reflected halo, nested glints, traveling label) · **Allies = people** (stable identity across four moods: Open · Engaged · Focused · Dreaming; camel + moon-cream identity ring; no permanent brightness/scale advantage — a relationship or task can be more prominent). Material rules: enamel deep, slightly irregular, tactile; highlights moon cream; wire/rims camel + sun gold; dimension from material hierarchy, never 3D spectacle. Recomposable systems: emblems, connection grammar, talismans, background geometry; tokens CSS; acceptance checklist; six personas × four moods = 24 Ally examples.
- **The Kiduna Design System pack (2026-07-22, 58MB)** is in downloads: fonts, preview, business card, the allies system (ALLY-SYSTEM/IMPLEMENTATION/GENERATION-GUIDE), asset libraries (icons, allies, talismans, organization crests, realm emblems), root SKILL.md, plus the embedded Enamel v0.4 bundle and the Alice/Field M0.3 handoff.
- ⚠ **Naming variance to reconcile**: the Enamel pack says "an Ally is the Source's persistent identity inside Kiduna" — visual-identity usage (the Source's avatar with moods), while taxonomy v1.3.4+ says all agents are Actors with Ki universal and no per-Source named allies. Likely resolution: the Enamel "Ally" card is the SOURCE's visual identity mark, not an agent — needs Moto's one-line ruling and then a rename sweep in the pack (or a taxonomy note).
- Kit v4.0 carries the ten Enamel handoff docs + tokens (enamel/); the two large zips stay in site downloads (linked, not embedded) to keep the kit portable.

---
