# The Kidunaverse — Complete Specification · Kiduna Kit v1.1 (spec v5.2 + Design R6) · built 2026-07-10 19:25 EDT

> Single-file corpus of the Kiduna site (https://kiduna.team), assembled for chat assistants. Source files are named at each section break. The UI design canvases are HTML-only and live in the kit's design-r6/ r7/ r8/ folders (earlier rounds live in the site repo, not this kit).

## Contents

1. The synthesis · 2. Create from Within · 3–13. Tracks 1–11 · 14. Open Questions · 15. Legal Items for Review · 16. Real Work, Real Money · 17. The Working Organization · 18. Design R6 (current round) + R4 UX spec + R2 invariants · 19. Canon deltas

---

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

<div class="wrap">

<div class="pkgbar">

<span class="v">Kiduna Kit · v1</span> <span class="meta">
<span class="stamp">Created 2026-07-10 · 17:30 EDT</span> </span>

For anyone who wants to participate. The complete spec — all eleven
tracks, canon, architecture, every design round, queues, the versions
record — packaged to work directly with **Claude, ChatGPT, Cowork,
Claude Code, and Codex**. Unzip it, point your assistant at it, and
start creating from within.

[Download the package ↓](downloads/kiduna-kit-v1-2026-07-10.zip)

</div>

<div class="kicker">

Kiduna · How We Build, and How You Can · Kinship Duna (WV Org 628407)

</div>

# The Kidunaverse

This site is the complete, current specification of what we are
building, why, and how — written so anyone can start here and understand
everything deeply enough to build with us. We work by [**Creating from
Within**](create-from-within.html): the minimum necessary to start
creating with the system, then everything else made from inside it. On
**August 10** the whole stack ships open source (Apache 2.0) — surfaces,
server, and protocol — and participating as a **Builder** or a
**Creator** starts with the [Kiduna
Kit](downloads/kiduna-kit-v1-2026-07-10.zip) above.

<div class="story">

## What we are building

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. The
Kidunaverse 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), **Kidunaverse** (the account), 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.

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

## Why it is built this way

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 the Kidunaverse 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 class="sect">

The specification — eleven tracks

</div>

<div class="tracks">

[<span class="n">Track 1</span>](surfaces.html)

### Surfaces

The six surfaces: Kiduna (Chat and Live), Kiduna Live, Kiduna One,
Kiduna Express, Kidunaverse (the account and protocol browser), Kiduna
Studio (+ kiduna.studio) — one system, four renderings, and the
**complete UI design** (§8).

<span class="for">**Start here:** everyone · mobile/Flutter builders ·
design</span> [<span class="n">Track 2</span>](orchestration.html)

### Orchestration

The middle tier: one agent system wearing personas, weighted listening,
one presence per channel, primitives carrying skills, contextual
actions.

<span class="for">**Start here:** agent/LangGraph builders</span>
[<span class="n">Track 3</span>](foundation.html)

### Foundation

The data architecture: the graph as the center, the primary nodes, the
four access levels, connections and grants, memory, what the database
holds about money.

<span class="for">**Start here:** Jeya & the back-end build</span>
[<span class="n">Track 4</span>](protocol.html)

### Protocol

The on-chain minimum: wallets, ally NFTs, alliances, Org-ID-validated
DUNAs, Compute, votes with settlement; duna commands; the decentralized
registry — domains, pages, and artifacts registered via DNS, codes, and
hashes.

<span class="for">**Start here:** chain/wallet builders · legal</span>
[<span class="n">Track 5</span>](organizations.html)

### Organizations

The 31 filed DUNAs and their purposes; the variance analysis — what
actually differs between organizations; the genesis duna stated
precisely.

<span class="for">**Start here:** anyone configuring a duna ·
partners</span> [<span class="n">Track 6</span>](actions.html)

### Actions

The baseline inventory of everything a member can do, on both surfaces,
role-gated and graph-indexed — plus the rule for registering new
actions.

<span class="for">**Start here:** mobile builders · QA · anyone wiring
features</span> [<span class="n">Track 7</span>](roles.html)

### Roles

The nine ways people relate to an organization — Guest through Luminary,
and Institutions — with the first Catalysts, Luminaries, and
Institutions named.

<span class="for">**Start here:** onboarding · community · legal</span>
[<span class="n">Track 8</span>](sentinel.html)

### Sentinel

Interaction health: seven bipolar meters where zero is health, graduated
correction toward the zero point, and hard human-in-the-loop boundaries.
Members see effects, never meters.

<span class="for">**Start here:** agent builders · safety · community
stewards</span> [<span class="n">Track 9</span>](legal.html)

### Legal

The legal posture: counsel's seven resolutions in force, in priority
order — securities messaging, money movement, organizer compensation —
plus the open work (ToS, privacy, IP licensing, fiscal sponsorship,
patents). Held for final review.

<span class="for">**Start here:** counsel · anyone writing public copy ·
partners</span> [<span class="n">Track 10</span>](institutions.html)

### Institutions

The outside entities with standing inside: KII (kinship.institute) holds
purpose, Kinship Systems (kinship.systems) holds labor, Kiduna Club
(kinship.club) holds property — and the launch cohort begins inside
Kiduna Club.

<span class="for">**Start here:** partners · sponsors · counsel</span>
[<span class="n">Track 11</span>](integrations.html)

### Integrations

Inward: MCP servers, APIs, and local agents (Cowork, Codex) scoped to
relationships, alliances, and organizations. Outward: our own API and
MCP server — build on the Kidunaverse with no privileged path.

<span class="for">**Start here:** Builders · third-party
developers</span>

</div>

<div class="sect">

Downloads — work without reading the site

</div>

<div class="cols">

<div class="box">

### The Kiduna Kit · updated daily

  - [**Core Team Package v5.1 ·
    2026-07-10**](downloads/kiduna-kit-v1-2026-07-10.zip) — for the dev
    core (Jeya, Aashik, Elias): the complete archive of everything
    across the entire effort — all eleven tracks, the engineering
    architecture, the complete UI design (viewable offline), narrative
    canon, the versions record, queues, and skill updates. Works with
    Claude, ChatGPT, Cowork, Claude Code, and Codex: chat assistants get
    a one-file spec (*KIDUNAVERSE-COMPLETE.md*) plus paste-able
    instructions; coding agents orient from CLAUDE.md / AGENTS.md. It
    answers from the spec and never invents.

</div>

<div class="box">

### Role packages · updated when needed

  - One per role, self-orienting:
    [Builder](downloads/roles/kiduna-role-builder.zip) ·
    [Creator](downloads/roles/kiduna-role-creator.zip) ·
    [Organizer](downloads/roles/kiduna-role-organizer.zip) ·
    [Catalyst](downloads/roles/kiduna-role-catalyst.zip) ·
    [Luminary](downloads/roles/kiduna-role-luminary.zip) ·
    [Institution](downloads/roles/kiduna-role-institution.zip) ·
    [Founder](downloads/roles/kiduna-role-founder.zip) ·
    [Member](downloads/roles/kiduna-role-member.zip) ·
    [Guest](downloads/roles/kiduna-role-guest.zip)

</div>

</div>

<div class="sect">

Deeper reading & the record

</div>

<div class="cols">

<div class="box">

### Narrative canon

  - [Real Work, Real Money](real-work-real-money.html) — how people
    collaborate, get paid, and build practices here, in plain language.
    The best first read for any newcomer.
  - [The Working Organization](the-working-organization.html) — the
    long-form case for the agentic shift, with four organizations worked
    in narrative detail.
  - [Kiduna-Architecture](kiduna-architecture.html) — the engineering
    draft of the graph-native architecture.

</div>

<div class="box">

### The record

  - [Versions](versions/index.html) — how this spec evolved, every prior
    version preserved. Design exploration history (paradigm rounds 1–4)
    lives there too; the *current* design is linked from [Surfaces
    §8](surfaces.html).
  - [**Open Questions**](open-questions.html) — the standing decision
    queue, each item with its full context and links into the spec.

</div>

</div>

*Changes in v4.9: the Core Team Package rebuilt as the complete archive
with a multi-LLM harness (Claude, ChatGPT, Cowork, Claude Code, Codex);
the version banner added above. Full history:
[versions](versions/index.html).*  
  
Kiduna Team — the working specification of the Kidunaverse · kiduna.team
· design system: [colors &
type](_ds/kidunaverse-2de4dee0-9628-4871-a4e3-fc4ddc902d31/colors_and_type.css)
· © 2026 Kiduna Club™, patent pending

</div>


---

<!-- ===== 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 the Kidunaverse, 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 the Kidunaverse 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 six surfaces, their official homes, and what using them is like · v5.2**

The Kidunaverse 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), **Kidunaverse** (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 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 the Kidunaverse; 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 Kidunaverse, 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 the Kidunaverse.** 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. Kidunaverse — 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 Kidunaverse (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.** The Kidunaverse'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 6 — Creating from Within** *(current round; canvas 05 is normative for the August 10 build)*: **[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.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 the Kidunaverse 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 — the Kidunaverse is the complete namespace, and **the agentic internet IS the Kidunaverse**. 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 Kidunaverse 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 the Kidunaverse.

## 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 the Kidunaverse — 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**
**The Kidunaverse 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 the Kidunaverse |

## 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 the Kidunaverse · 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, and building on the Kidunaverse · v5.0**

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 the Kidunaverse

**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 the Kidunaverse 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 the Kidunaverse 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).

---

*Changes in 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: 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.

---

*Awaiting decisions: **[Design Round 6's ten open questions](design-r6/OPEN-QUESTIONS-R6.md)** — each with the spec position, the disagreement or gap, and alternatives with reasons, decidable from that file alone (pre-account disclosure depth · one signature or two for profile+code · Ki's public conversational door and guest-Compute funding · Live voice at launch · mode-product packaging · the relationship card's single source of truth · presence counts in generative rooms · the practice currency's name · no unproven identity-sameness in the directory · marking R5's Studio as horizon). 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.*

---

## Recently resolved (full history in [versions](versions/index.html))

- **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: [drafted, on Drive](https://docs.google.com/document/d/1uC7QZWRd_18E276xRhd3tf30c3KxTgiYqYoTx7YqCZg/edit) — Moto reviews and sends to Moe; 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-15 · 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 the Kidunaverse, how they get paid, and how they build practices and firms**
The evening brief for the team · July 7, 2026 · read before tomorrow morning's meeting

---

## 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 the Kidunaverse 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.

The Kidunaverse 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 the Kidunaverse. 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 the Kidunaverse 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 · the Kidunaverse · 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: design-r6/UX-SPEC-R6.md ===== -->

# UX SPEC — DESIGN ROUND 6
**Kidunaverse · renders Spec v5.2 (July 10) · R2–R5 remain in force except as amended here · July 10, 2026**
Pairs with: `01 First Invitation R6.dc.html` · `02 Live R6.dc.html` · `03 One and Live Products R6.dc.html` · `04 Kidunaverse Directory R6.dc.html` · `05 Create-from-Within Cut R6.dc.html` · `MOTION-ADDENDUM-R6.md` · `OPEN-QUESTIONS-R6.md`.

---

## 0. The sentence, composed

R3's sentence still governs: **one dialogue with your ally, and everything else is a card that gets bigger for a minute.** R6 adds the round's own sentence on top: **the member prepares the system for the person they're inviting.** Everything new this round — Ki's first session, the Profiler, the personal invitation page, the fluent first Chat, the mode products, the /handle pages — is that one sentence rendered at different points of the arc. Nothing in R6 adds a second paradigm; Live is Chat's second rendering, and the mode products are subtractions, not siblings.

## 1. Renames and canon absorbed from v5.2

- **Chat and Live** are the modes; "Move" as a mode name is retired everywhere. R5's canvas 02 ("Move") is superseded in name and extended in substance by R6 canvas 02; its grammar survives intact.
- **Moves** are the authored Live experiences (scenes, vibes, games) built in Studio; Kidunaversity is the first. The sim flag is orthogonal to Move-ness: real Moves take solid borders and real gold; only sim-flagged Moves take mint-dash-hollow.
- **Six surfaces**: Kiduna (kiduna.app) · Kiduna Live (kiduna.live) · Kiduna One (kiduna.one) · Kiduna Studio (desktop + kiduna.studio) · Kiduna Express (kiduna.express) · Kidunaverse (kidunaverse.com with /handle directories).
- **Source** is the word for an ally's owner; **every ally is Ki personalized**; conversations between people run Source 1 → Ally 1 → Ally 2 → Source 2; every invitation code is unique to one person.

## 2. The first invitation (Deliverable 1) — the design decisions

**Beat 1 — Ki's first session (01 · 1a).** Ki explains just enough: three sentences of world, then the first act. Ally creation is conversation — the naming, the live handle check (one namespace across members and allies), the Contract's three first sentences, and a provenance statement of what the new ally knows about its Source. The takeover is continuity, not construction: Taro inherits the thread and the memory because it *is* the same system with a new face. No gold anywhere — an ally is stated trust.

**Beat 2 — the Profiler intake (01 · 1b).** "I want to invite X" triggers the check-then-offer pattern (already a member? connect; new? Profiler). The input list is asked item by item, each with its reason stated ("so I read the right material, not everything"). The assembled list is restated whole before anything is read: **consent precedes collection.** The relationship sentence and the why remain member-authored verbatim forever — they are the two lines the invitee will read as the member's own voice.

**Beat 3 — the profile card (01 · 1c).** Front = what the system now knows and at what access level (who-will-ever-see-this is a consequence, so it lives on the front). Back = every source used, as citations; removal is forgetting, not hiding. Correction is conversational. **Sending is the flow's one gold moment**: extending a code is a signed act (with join and domain binding, the third of three at launch), so it takes press-and-hold and receives the ceremony.

**Beat 4 — the invitation as swyx sees it (01 · 1d).** The R5 proof grammar extended by exactly two things the Profiler makes possible: the issuer's two lines verbatim (italic, behind a rule — a person's voice, typographically distinct from registry claims), and **the preparation disclosed pre-account** (what was read, where it's held, that it's correctable). A system that studied someone and said nothing would be surveillance with manners; the disclosure is therefore not optional copy — it is the page's second job.

**Beat 5 — swyx enters (01 · 1e).** Onboarding is R5's flow adopted without redesign. The ally (Latent) wakes fluent and **opens with provenance** — the disclosure is the first message, the conversation the second. The first Chat starts in the middle: a sentence only someone who read the defining work could open with. The relationship card is R5's two-sided grammar, each side authored by its own member, no signature.

**Beat 6 — the switch and the creating (01 · 1f–1g).** The Chat ⇄ Live switch is chrome — two standing words — because a mode must feel cheaper than a door. Continuity is carried by the ally band across the 1400ms crossing. Studio ships as the create-from-within cut: **exactly three jobs (maintain your ally · invite someone · develop a Move)** and one demonstrated package handoff to Claude Code (context + ask + constraints out; records back, cited to the package). Everything else Studio will be is absent, not hidden.

## 3. Live (Deliverable 2) — the composed model

1. **Sky rims, never sky paint** (law since R5): the world is warm; the interface appears only as a thin breathing edge on what would respond to touch.
2. **The HUD is four elements** — container chip, contextual chips (≤3, ranked by distance then consequence), the ally band, sky rims. No fifth element; fuller UIs are Chat's slide-over cards, borrowed and returned.
3. **Steering is three gestures** — tap to walk, drag to look, pinch to rise.
4. **Access renders as geometry.** At range an exchange shows its public shape; within grants, proximity opens what both sides allow; what you cannot access never gets a chip — absence, not a locked door. Chips that depend on grants state their permission in their own label ("listen in — both sides allow it").
5. **Moves score in sentences.** Goals strike through; outcomes are told once, as story, in the debrief. Practice currency is named in-fiction (Foundry Scrip) before its wallet renders; sim ground is mint-cast and dashed; practice press-and-hold is hollow gold, no embers, no haptic. Numbers may exist inside the fiction; they never rank people.
6. **The vocabulary is a closed set** (02 · 2e): five tile classes, five sprite classes, five event classes. Growing the set is a Studio design act — versioned, named, everywhere at once — never per-scene improvisation.
7. **The generative fallback is a designed material.** Sentence first; nothing draws that the sentence didn't state; the "drawn live" chip never leaves; sprites and HUD identical to authored space. At launch the fallback is most of the world, on purpose.
8. **kiduna.live arrives on your own ground** — no lobby, no world-picker. The graph knows where your life here is.

## 4. The mode products (Deliverable 3)

1. **One door grammar for both**: a sentence about the mode · Sign in · "I have an invitation code" · a pointer to kidunaverse.com for the curious-uninvited. If the doors diverge beyond the sentence, the products have started competing.
2. **kiduna.one holds subtraction**: no mode switch in the chrome, no ground ever renders. Portals arrive as words; accepting is a stated handoff. Sovereign acts are undiminished — cards, press-and-hold, gold are Chat grammar and therefore One's.
3. **kiduna.live is 02 · 2a as a product**; the band expands to a slide-over thread for long-form moments; full threaded history is reserved for One and the app.
4. **The switch to the whole is a standing line, not a nag**: "the whole Kidunaverse · kiduna.app," bottom of the surface, never modal, never counting. Conversation and position travel on tap.

## 5. kidunaverse.com (Deliverable 4)

1. **Onboarding and registration: R5's flow, adopted.** No pixel changed this round; Ki's greeting on the first page may carry one line of the profile's warmth.
2. **/handle pages render at the viewer's level**: stranger (registry proof + one self-authored line + boundary sentence), relationship (the two-sided card is the page's center), shared container (texture of what they do there, citable). **Never balances, counts, or standing at any level.**
3. **Member pages and ally pages are different species**: a member's page centers a relationship; an ally's page centers its Contract — Source (linked), binding sentences, reachability. Ki's page (kidunaverse.com/ki) is the one ally page that offers conversation to strangers.
4. **Boundaries are the three sentences** (04 · 4c), verbatim across all pages: held closer · you see the ones you share · none of this page's business. No padlocks, no teasers, zero motion on closed things.
5. The protocol browser and public metrics defer (R5 canvas 04 stands as their design when they come).

## 6. The invariants, restated

Citations and consequence-ordering · gold = signature (three signed acts at launch: join, code extension, domain binding — the third deferred with Express) · sky = touchable · the card anatomy (front consequence, back context) · the four access levels · the Contract · one ally voice · drift, never navigation · members never users · handle never username · relationship never connection · registered/unregistered · Compute is prepaid usage credits that power intelligent agents · deciding is never fundraising · the Sentinel visible only as effects and plain sentences · receipts show machine-generated sentences over commands · press-and-hold everywhere, practice version only inside Kidunaversity · light announces what happens to you; never pulses for attention.

## 7. The cut

Canvas 05 is normative: fifteen screen-groups in, nine capabilities out, and the one-page slice whose test is recursion — Moto invites swyx before lunch; swyx invites the next person the same day; Ki greets that person better because swyx's corrections are in the graph now.

---

<!-- ===== SOURCE: design-r6/MOTION-ADDENDUM-R6.md ===== -->

# MOTION ADDENDUM — DESIGN ROUND 6
**Additions to R2 `MOTION-SPEC.md`, R3, R4, and R5 addenda (all stand in full) · July 10, 2026**

The rule underneath is unchanged: **motion is weather, not reward.** Standing timing tokens hold (`settle 180ms · overlay 250ms · object 350ms · flip 500ms · drift 800–1400ms · hold 1000ms · seal 600ms · voice 120ms · crossing 1400ms · promote 900ms · step 260ms · room 1200ms`). One new token: **`switch 1400ms`** — the Chat ⇄ Live mode switch, which is the crossing token given a name of its own because it is now chrome, not a portal.

---

## 1. The Chat ⇄ Live switch (`switch 1400ms`)

The round's centerpiece. The switch is two standing words in the chrome; flipping it must feel like turning your head, not opening a door.

- **Chat → Live:** the thread does not leave — it **sinks**: messages compress downward and desaturate over the first 400ms while the ground fades in beneath them (tiles 24→0px elevation with 30ms stagger, R3's crossing grammar). The last exchange never disappears: it hands off to the ally band, which is already present at the bottom before the ground finishes rising. Characters render last. Total 1400ms, interruptible: tapping the switch again at any point rolls back at 2×.
- **Live → Chat:** exact reverse. The ground sinks, the thread rises *already scrolled to where you left it*. The band's current sentence becomes the newest message — visibly the same object, sliding from band-position to thread-position (350ms within the crossing).
- **The switch control itself** animates once per flip: the active word slides under the pill highlight (250ms). It never glows, badges, or pulses — a mode must not advertise.
- **On kiduna.one / kiduna.live** there is no in-place flip; the standing door ("the whole Kidunaverse · kiduna.app") hands off with the same visual grammar on arrival in the app — continuity is the product's proof that it is one graph.

## 2. Live's movement grammar (restating R5 §3, now under the Live name)

- **Tap to walk:** camel path hint draws in 120ms, gone at arrival; figure moves at `step 260ms` per tile, easeInOut per step, interruptible by any new tap.
- **Drag to look, pinch to rise:** direct manipulation, zero added animation.
- **Chips by proximity:** a chip rises (180ms, 8px) when its subject enters range and **settles away as you pass** (350ms). Rank re-sorts only at rest — never while the member is moving, so the row doesn't shuffle underfoot. Maximum three; a fourth candidate waits.
- **Sky rims** breathe on a 3s cycle only while touchable; fade over 350ms when touchability lapses. Approach rings on sprites obey the same law.
- **Light announcements** bloom over 800ms, hold while true, decay over 2s. Light never pulses for attention.
- **The gold seal in space:** stamp + up to 12 embers at the act's location, witnessed once, then a static gold dot for the scene's duration. Sim contexts: hollow, emberless, no haptic.
- **Drift seams** between dunas shift ground hue and register over `drift 800–1400ms`; no wipe, no fade to black.

## 3. The generative room (`room 1200ms`, unchanged; one addition)

Assembly order is the honesty: sentence prints first, then boundary (400ms) → openings (200ms) → furniture strokes (200ms) → sprites (fade 200ms, one per named presence). **R6 addition — revision locality:** when the sentence updates (someone enters, distances change), only the changed strokes redraw (350ms), and the changed clause of the sentence brightens once (400ms) in the band — the words and the strokes visibly co-vary, which is the fallback's whole claim to honesty.

## 4. The Profiler and the invitation

- **Intake chips** settle like any contextual action (180ms). The restated input list assembles with the account-claims grammar: rows rise 8px + fade in, 180ms each, 40ms stagger, once.
- **The profile card returns as an event**: it settles (180ms) and its access-level line brightens once (400ms) — the one fact the member must not miss. No other emphasis; the card is a claim, not a reward.
- **The card flip** (front ⇄ back) is `flip 500ms`, R3's card grammar unchanged.
- **Sending = code extension**: press-and-hold is MOTION-ADDENDUM-R4 §3 verbatim (fill 1000ms, abort rolls back at 2×); on commit, stamp (scale 1.02→1.0, 200ms) + embers + haptic. The sent state then goes completely quiet: a receipt row, no residual glow. The invitation's life at the other end is swyx's, not Moto's to watch animate.
- **The invitation page (pre-account)** inherits R5 §1 whole: registry checks fade in after their verification returns (180ms, 60ms stagger), never a spinner. **R6 addition:** Moto's italic lines render immediately with the static page — a person's words are not a check and must never appear to "resolve."

## 5. First Chat and the fluent ally

- Latent's provenance message and the fluency that follows use standard message settle — **deliberately nothing special**. The design intent is that the remarkable thing (an ally already fluent) arrives in the most ordinary grammar the product has; the content carries it.
- The relationship card obeys R5 §2: no gold, no embers; a changed side's old sentence fades to 40% while the new settles beneath for 800ms, then replaces it.

## 6. Studio's package handoff

- **Out:** the package card assembles from its parts (context, ask, constraints — three rows, account-claims grammar), then slides off-surface toward the local agent (350ms) and leaves a resident "out" row. While out, the row is still — stillness is the honest state while another agent holds the work (R5's connect-path rule, generalized).
- **Back:** the returned package lands as a card (settle 180ms), and unpacking into the graph runs the drop-organizes grammar (R5 §5): items file into the container's scope, 180ms each, 40ms stagger, once. Records cite the package with the standard citation brighten (400ms) on first render.

## 7. Budget & fallbacks

Unchanged: Live fits the R2 envelope (≤1 shader pass + particles; idle <5% GPU mid-Android); the generative room is pure stroke rendering; web surfaces are engine-free CSS/DOM. Reduced-motion renders final frames everywhere — including the switch, which becomes a hard cut with the band persistent; nothing above carries meaning its final frame doesn't.

---

<!-- ===== SOURCE: design-r6/OPEN-QUESTIONS-R6.md ===== -->

# OPEN QUESTIONS — DESIGN ROUND 6
**Sharpest disagreements and decisions-where-silent, one per item · July 10, 2026**
Format: the spec position → the disagreement or gap → the alternative(s), with reasons. Where I disagreed, I built what the spec says and flagged here (the law of the prompt).

---

**OQ-1 · The invitation page discloses the Profiler's work pre-account — how much?**
v5.2 says the invitation "reads like it was written by someone who knows his work." I built the disclosure sentence plus an expandable source list (01 · 1d), on the argument that a system that studied someone and said nothing is surveillance with manners. **Disagreement risk:** counsel may prefer less pre-account surface (the source list names third-party platforms before any terms are accepted). **Alternative:** disclosure sentence only, list deferred to first session. I'd resist going below the sentence — the sentence *is* the ethic.

**OQ-2 · Is extending a code the signed act, or is *sending the profile* a second one?**
Spec is silent. I bound profile + code into one signature (01 · 1c): one act, one ceremony, because the profile only leaves the member's hands inside the invitation. **Alternative:** separate signatures (one for "hold this profile," one for "extend this code") — cleaner audit lines, but two gold moments in one flow cheapens both, and the profile alone never crosses a boundary. Decided: one signature; flagging because the receipts differ.

**OQ-3 · Ki's page offers conversation to strangers (04 · 4b) — is that canon?**
Roles §1 says Ki serves all guests; nothing says kidunaverse.com/ki is conversational pre-account. I decided it is — it gives the curious-uninvited an honest door that isn't a marketing page, and it exercises the Guest path with zero new machinery. **Alternative:** static page, conversation only after a code. Safer for abuse/cost (Compute is metered — who pays for stranger chats?), and that cost question is real: propose a tight rate-limited guest scope funded by Kinship Duna as the answer, not silence.

**OQ-4 · Voice in Live at launch.**
Surfaces §2 folds voice into Chat as one conversation; nothing requires it in Live for August 10. I cut it (05): the band is text in Live at launch. **Disagreement with my own cut:** steering while reading is genuinely worse than steering while listening; if any post-cut capability earns early re-entry, it's Live voice-out (ally speaks, member taps). Flagged as the first from-within build.

**OQ-5 · The mode products' door on mobile web vs. native app.**
Spec is silent on whether kiduna.one / kiduna.live are PWAs, wrappers, or just the web app pinned to a mode. I designed them as the same Flutter build opened in one mode (their whole point is sameness), which implies web-first at launch. **Alternative:** native store listings for each — discoverability, but three store products before August 10 is real cost for two products whose message is "this is the same app." Decided: web at launch, one listing (Kiduna) in stores.

**OQ-6 · The relationship card renders on the /handle page (04 · 4a) — duplication risk.**
The two-sided card now lives in Chat, Studio (R5), and the directory. I rendered it verbatim in all three because it is the *one* object both sides own — but the spec should name a single source of truth for its copy (the graph record) and say the three surfaces are renders, not copies. Gap, not disagreement; one sentence in Foundation would close it.

**OQ-7 · "Four others here" — does the generative room count people?**
Sentinel law forbids meters on people; the fallback's sentences state presence counts ("four others here"). I kept counts — presence is a fact of a room, not a score of a person — but drew the line at *named* distance ranks or activity totals. Flagging because the boundary (counting presence yes, counting behavior no) is mine, not the spec's.

**OQ-8 · Foundry Scrip's name inside Kidunaversity.**
R4 named the practice currency in-fiction; v5.2 renames the mode and the experiences but not the fiction. I carried "Foundry Scrip" (02 · 2d). If Kidunaversity's fiction is now a university rather than a foundry, the name should follow the fiction — "Bursar's Scrip" — before the strings ship. Pure naming; zero mechanics.

**OQ-9 · Handle collisions with the outside world.**
Handles are unique across members and allies — but kidunaverse.com/swyx will exist the day he joins, while @swyx also names accounts elsewhere. Spec is silent on whether the directory ever asserts sameness ("this is the @swyx of X/GitHub"). I kept the pages silent on outside identity except where a registered social account (Express, out of this cut) proves the binding. Decided and flagged: **no unproven sameness claims in the directory, ever** — it's the registered/unregistered law applied to identity.

**OQ-10 · The Studio cut hides nothing — but R5's Studio canvas exists.**
Builders reading the kit will see R5 canvas 03 (the full Studio) next to R6's three-job cut and may build toward the wrong one. The MANIFEST states precedence (cut first, R5 as horizon), but the spec site should mark R5 · 03 "design horizon — not the August 10 build" in its own header. Editorial gap; one line.

---

<!-- ===== SOURCE: design-r6/MANIFEST.md ===== -->

# MANIFEST — DESIGN ROUND 6
**Creating from Within: Chat and Live, and the First Invitation · renders spec v5.2 · July 10, 2026**

## What this round is

Round 6 designs the surfaces for **Creating from Within**: the minimum necessary to start creating with the system, centered on one act done perfectly — **Moto sets up his ally and invites swyx** — and on the first real design of **Live**. R2–R5 remain in force where not superseded; R5's cohort journey is the onboarding baseline, adopted, not redrawn.

## Inventory

| File | Contents |
|---|---|
| `01 First Invitation R6.dc.html` | Deliverable 1 — the through-line, every beat: Ki's first session and ally creation as conversation (1a) · the Profiler's conversational intake (1b) · the profile card, front/back, and the code-extension signature (1c) · the invitation as swyx sees it, pre-account (1d) · swyx enters: fluent ally, mid-conversation first Chat, the two-sided relationship card (1e) · the first Chat ⇄ Live switch (1f) · Studio at exactly three jobs + the Claude Code package handoff (1g) |
| `02 Live R6.dc.html` | Deliverable 2 — Live, first full round: kiduna.live arrival (2a) · the four-element HUD and sky-rim law (2b) · contextual actions by movement and proximity; access as geometry (2c) · sim-flagged Moves, goals and scoring without meters (2d) · the closed tile/sprite/event vocabulary (2e) · the generative fallback (2f) |
| `03 One and Live Products R6.dc.html` | Deliverable 3 — kiduna.one (3a) and kiduna.live (3b) as products: front door, first minute, and the ever-present switch to the whole (3c) |
| `04 Kidunaverse Directory R6.dc.html` | Deliverable 4 — /handle pages: a member's page at three access distances (4a) · an ally's page (4b) · the boundary grammar (4c). Onboarding/registration = R5's flow, adopted |
| `05 Create-from-Within Cut R6.dc.html` | Deliverable 5 — every screen marked in/out for August 10, and the one-page minimum coherent slice with the recursion test |
| `UX-SPEC-R6.md` | The composed model: the invitation arc, Live, the mode products, the /handle pages, the cut |
| `MOTION-ADDENDUM-R6.md` | The Chat ⇄ Live switch (`switch 1400ms`), Live's movement grammar, the Profiler/invitation motion, the package handoff |
| `OPEN-QUESTIONS-R6.md` | Ten items — disagreements and decided-where-silent, alternatives with reasons |
| `_ds/` | The binding design system (colors_and_type.css + bundle), carried whole |
| `assets/` | Kiduna mark + linear logo |

## How to read the round

1. Read `create-from-within.md` in the kit if you haven't — this round renders that page.
2. Walk canvas 01 top to bottom: it is the whole founding act in order.
3. Canvas 02 is Live's grammar; 1f on canvas 01 is its emotional argument.
4. Canvases 03 and 04 are deliberately thin — thinness is their content.
5. Canvas 05 is normative for build sequencing. **Precedence note:** where R5 canvas 03 (full Studio) and R6's three-job cut differ, the cut is the August 10 build; R5 is the horizon.

## Cast

Real people only: Moto (Source of Taro) · Shawn "swyx" Wang (Source of Latent — ally names shown are placeholders their Sources would choose) · Ki, the Genesis Ally · the launch cohort by name where they appear.

## Law observed

Compute is "prepaid usage credits that power intelligent agents" · gold marks signed acts only (join · code extension · domain binding) · light announces what happens to you · press-and-hold is the signature everywhere, practice version only inside Kidunaversity · no HEARTS, meters, scores, balances-as-standing, or leaderboards anywhere · members never users · handle never username · relationship never connection · Chat and Live, never "Reality"; Moves are authored Live experiences · all money authorization on the web · deciding is never fundraising.

---

<!-- ===== SOURCE: design-r4/UX-SPEC-R4.md ===== -->

# UX SPEC — DESIGN ROUND 4
**Kidunaverse · renders Spec v4.1 (July 8) · R3 remains in force except as amended here · July 8, 2026**
Pairs with: `Redraws R4.dc.html` · `Web Money Surface R4.dc.html` · `Kidunaversity R4.dc.html` · `Levels & Social Objects R4.dc.html` · `MOTION-ADDENDUM-R4.md` · `OPEN-QUESTIONS-R4.md` · the standing R3 set (`design-r3/UX-SPEC-R3.md`, `MOTION-ADDENDUM.md`) and R2 set, which remain in force except where noted.

---

## 0. The sentence, updated

R3's sentence stands whole: **the app is one dialogue with your ally, and everything else is a card that gets bigger for a minute.** R4 adds the four things July 8 named: the training world is **Kidunaversity**, the first Reality Game, where nothing affects the Kidunaverse; **money's web home is now designed**, not just promised; **levels, guilds, and institutions** enter the render vocabulary; and proposals **show their duna commands** as plainly as a receipt. Nothing in R4 adds navigation, chrome, or a second paradigm.

## 1. What changed from R3, section by section

| R3 section | R4 change | Why |
|---|---|---|
| §2 Voice | **Redrawn (2a).** The folded transcript is now visual, not just copy: in-flight words render inside the voice band (grown one line), the Thread shows only settled turns. | R3 resolution #1 was folded in prose; the screen still drew the forming bubble in the Thread. |
| §7 Training entry | **Redrawn (2b).** The hold-ring is gone from the crossing; a tap opened the portal, and the only drawn affordance mid-crossing is *tap anywhere to turn back*. | R3 resolution #3. The signature gesture keeps one meaning. |
| §3 Training | **Renamed and reframed: Kidunaversity, the first Reality Game (canvas 4).** Sim boundary language hardens: everything inside is fake, or staked and returnable. Regimens can reach real channels; the boundary is money, not realism (unchanged). Portal cards say the name. | July 8 canon. The name does UI work: "a Kidunaversity regimen" is offerable in one breath. |
| §9 Money handoff | **The web side exists (canvas 3).** Join, wallet, limits, reload, Institution setup, authorize — espresso↔cream inversion, Goudy figures, gold-for-signature, one act per page. The receipt-line return contract from R3 MOTION-ADDENDUM §6 is unchanged and is what every page hands back. | R3 resolution #6 commissioned it. |
| §5 Forums | **Proposals show their commands (4d, 5c).** Above the token, every proposal renders an execution receipt: plain verbs leading, the named atomic commands in IBM Plex beneath as the citation layer, prefixed *"if it passes, these execute — together or not at all."* Failing states what does not happen. | July 8 canon: a passed proposal performs named actions atomically; members must see what will actually happen as plainly as a receipt. |
| §6 Access / social objects | **Guilds enter the sharing flow (5b).** A guild is a name and its people — no wallet, no chain — and renders feather-light: dashed ring, no figure, no badge, beside connections (solid person), alliances (wallet-bearing card), organizations (the accountable entity). | Foundation July 8 addendum. Weight must be legible in the render, or members will treat a guild like an alliance. |
| — (new) | **Levels (5a).** Per-duna, founder-set: Guest · Member · Organizer (with Clan) · Founder · Builder · Creator · Catalyst · Luminary. A promotion is a duna's act: it arrives as a thread beat, cited to the threshold, sealed gold with embers — the one everyday moment allowed the full gold treatment, because it is earned, not bought. Afterward, the level is a small gold pip beside the name **only in that duna's contexts**; the ladder renders once, small, as context, never as a progress bar. | Organizations §4. |
| — (new) | **Institutions (3d, 5c).** Square where members are circles; registered name under working name; created on the web ($1K Compute, up to ten enrolled members, Squads wallet); "cannot vote" renders with the price, never in fine print. In Forums an institution appears only across the table — a counterparty in a contract proposal, with the command receipt showing what binds. | Protocol §2, Organizations §4. |
| — (new) | **The agentic internet (5d).** When the ally encounters a domain: TXT-bound domains render as solid cards marked **accountable** (with the entity, the realm, and the check stated); unbound domains render as dashed cards marked **unverified — a stranger, not a threat**. No red, no warning iconography. The ally's vocabulary is accountability, never safety (see OPEN-QUESTIONS-R4 #4). | Protocol §4. |
| Vocabulary | **Compute is canonical.** "You hold Kiduna Compute / Service Alliance Compute" — never "compute currencies," never a generic balance. The R2 token chip grammar (dot · duna name · count) stands everywhere Compute renders, including cream. | Protocol §2. |

## 2. The redraws (canvas: `Redraws R4.dc.html`)

**2a — Voice, folded.** The band grows one line: waveform strip above, in-flight words below in small italic at `--fg-soft`, refining in place. A hairline separates them inside the band. The Thread above ends with the member's last *settled* bubble — visually identical to a typed one, which is the point. Caption states the law: nothing forms in the Thread; the record has no in-flight state to show.

**2b — The crossing, tapped.** Mid-crossing frame: thread sinking above, Foundry Row rising below, and at center — where the hold-ring used to be — a quiet pill: *tap anywhere to turn back · rolls home at 2× · you never left*. The Kidunaversity name sits in the frame's top chip. Nothing on this screen is gold: entering costs nothing and the color grammar says so.

## 3. The web money surface (canvas: `Web Money Surface R4.dc.html`)

The rules, as built:

1. **One act per page.** Join joins; the wallet shows and routes; authorize authorizes. If a page wants a second job, it is two pages.
2. **Espresso↔cream inversion.** Cream ground (`--kin-cream-white`), espresso type, the same type families. Gold on cream keeps its one meaning: the signature bar. Sky on cream (darkened to hold AA) keeps its one meaning: touchable.
3. **Goudy figures.** Every money amount renders in display type — $100, $412, $1,000, $40.00. Prose stays Avenir.
4. **No promotional chrome.** No nav, no footer-farm, no plans, no testimonials, no cookie wall. The join page (3a) states the whole bargain in three arrow lines and stops.
5. **Press-and-hold is the signature on the web too** — mouse or touch, same 1000ms radial fill (MOTION-ADDENDUM-R4 §3).
6. **The authorize page (3e/3f) renders nothing but the act**: what, how much, to whom, who asked (cited), one signature, and a quiet decline that costs nothing and prints nothing. It inherits the act from wherever it was stated; it never composes one.
7. **The mobile web page is what the in-app cream sheet shows** (3c/3f) — one design, two apertures. The R3 return contract (`act · amount · currency · counterparty · rail · timestamp · record_id · status`) is what every page hands back; the app renders receipts only from that payload.
8. **Join (3a):** $100 arrives as Kiduna Compute in the member's own wallet — a balance, not a fee. "Once, and always" is on the page because the protocol makes it true.
9. **Institution setup (3d):** the registry check and the optional domain TXT binding are rows in the same quiet form; the founding card states the five facts (Compute, wallet, contracts, reloads, votes-never) and the hold bar carries the price.

## 4. Kidunaversity (canvas: `Kidunaversity R4.dc.html`)

- **The portal (4a)** names the Reality Game, states the bargain (what you'd practice, with whom, how long, nothing touches the Kidunaverse), and opens on a tap rendered in **sky, not gold** — the button grammar itself teaches that entering costs nothing.
- **The world (4b)** is the graph, rendered spatially: the proposal is a parcel with a dashed gold boundary; members are their allies; the role seam (*Verna, trail commissioner · worn by Aurelia, your ally*) never hides; actors are square-ish marks with dotted borders, purpose chips, and routines that draw when observed.
- **The scrip (4c)** follows the Foundry-Scrip standard as law: an actor names the practice economy in fiction (*"we pay in gorge scrip out here… it's worth exactly nothing past the ridge"*) before the wallet renders. The hollow-gold material rule is the confirmation, never the lone signal.
- **The practice signature (4d)** is the one press-and-hold inside training: full second, radial fill, hollow seal, zero embers. It sits under a sim proposal that carries the full command receipt — members learn to read commands where misreading costs nothing.
- **Sim rendering is structural:** dashed borders on every value-bearing container, hollow gold at the material layer (scene-level uniform, per R3), the 20s ground breathing. The footer of every sim frame states the architecture: *nothing here touches Stripe, Sphere, or any treasury — structurally, not by policy.*

## 5. The command receipt (canonical anatomy)

Rendered in 4d (sim) and 5c (real), and canonical for every Forum proposal from R4 on:

- A header row: **"if it passes, these execute — together or not at all."**
- One row per command: **plain verb sentence left** (the consequence, in the member's language), **the named atomic command right** in IBM Plex small type (the citation layer — tappable to the Vigil like any citation).
- A closing line for the failing state: what does *not* happen.
- Amounts in the rows render in Goudy like all figures. In sim contexts the receipt's border is dashed like everything else.
- The prose sentence is the contract of the render: if a command has no honest plain-verb sentence, the proposal is not ready to open (see OPEN-QUESTIONS-R4 #3).

## 6. Levels, guilds, institutions — the render vocabulary

| Object | Mark | Weight in UI | Never |
|---|---|---|---|
| Member | circle | standard | — |
| Level | small gold pip by the name, per duna | one promotion beat, then quiet | a progress bar, a leaderboard, an XP number |
| Clan | named in the ally's voice | prose first | an org chart |
| Guild | dashed ring, ✳ | feather-light: name + people only | a wallet, a badge, a figure |
| Alliance | rounded square, solid | wallet-bearing card | — |
| Organization (duna) | rounded square, solid, realm hue | the accountable entity | — |
| Institution | **square**, registered name beneath | counterparty card; "votes never" in the render | a voter, a member-shaped circle |
| Actor (in sim) | dotted border | purpose chip + routine | passing as a member's ally |

Catalyst and Luminary are wealth-threshold levels; their default rendering is contested — see OPEN-QUESTIONS-R4 #1 before building.

## 7. Fluid boundaries, shown

The screens make the fluidity deliberate: the Winter Crew guild spans three dunas in one sharing row (5b); Jaya is an Organizer in Kinship and a plain member in Mountain River Trail in the same breath (5a); Lightbrush's enrolled members work inside a duna it can never vote in (5c); a Kidunaversity regimen set in one duna is offered from a thread grounded in another (4a). The duna line answers exactly one question — *which entity is responsible* — and the UI never uses it to wall people apart.

## 8. Resolved-from-R3 status

All six R3 resolutions are now fully rendered: #1 (2a), #2 (unchanged, R3 §8), #3 (2b, 4a), #4 (4c), #5 (standing invariant, REALM-EXPRESSION §2.10), #6 (canvas 3). Nothing in R3's MANIFEST remains flagged visual-only.

---

<!-- ===== SOURCE: design-r2/REALM-EXPRESSION.md ===== -->

# THE REALM-EXPRESSION SYSTEM
**Kidunaverse Design Round 2 · a continuous expression space, not templates · July 7, 2026**

A realm (duna or alliance) expresses itself through a bounded set of continuous variables — the "rendering" clause of its configuration (working-organization Part III §5). There are no types, no templates, no "health orgs get the clinical skin." Every realm sets the same dials; the dials are continuous; the invariants are untouchable.

---

## 1. What a realm MAY set

| Variable | Range / bound | What it does |
|---|---|---|
| **ground hue** | one hue, mixed ≤12% into espresso `#1C140D`; drawn from the sanctioned deep set (camel, chocolate, aubergine, navy, violet, sky-dark, magenta-dark) | the neighborhood's temperature; the primary drift tell |
| **ground motion** | breathing amplitude 0–1, period 30–120s | how alive the floor feels |
| **rendering voice** | prose register in the baseline prompt | word choice and the pacing of ideas when grounded here (clinical / loud / quiet) — text only; see §2.10 for the spoken voice |
| **compression bias** | says-less ↔ says-more | how much a rendering elaborates (Cosmic Humanity would rather say less) |
| **type mood** | display scale ×0.9–1.15 · line-height snug↔loose · claim density 0.8–1.2 | spaciousness; never a different typeface |
| **claim garnish** | one optional per-claim annotation slot | e.g. BiHome's confidence interval, Lui Mutual's reserve band |
| **code skin** | how a traveling code renders | ember, ticket, printed QR — ritual only; the JWT and readout are fixed |
| **room dress** | room surface palette + presence-mark styling within the ground-hue bound | Cosmic Humanity's rooms ≠ Fellowship of Play's rooms |
| **field tells** | particle temperature; weather-tint intensity ×0.5–1.5 | how loudly the ground reports |
| **sound** | opt-in palette, off by default, only past the member's Contract | rooms and bells only; never the Thread |

All values are per-realm scalars in the duna's configuration — a point in expression space, editable by proposal like any policy. Two realms can be arbitrarily close or far; nothing snaps to an archetype.

## 2. What a realm may NEVER touch

1. **The eight invariants' semantics** — Thread, Account, Docket, Seal, Codes, Rooms, Contract, Vigil. A realm can change how a claim *sounds*, never whether it is cited, consequence-ordered, correctable.
2. **Sky = touchable. Gold = signature moments.** The two meaning-bearing colors are system-wide; a realm's hue may never collide with them (the sanctioned deep set excludes both).
3. **The Docket's anatomy and gravity** — title · consequence · acts · context-back; press-and-hold; bounded deck; words-not-numerals. No realm makes signing lighter or louder.
4. **Citations.** Every claim cites, in every realm, at every compression.
5. **The type families** — Goudy Heavyface display, Avenir body, IBM Plex Sans callouts. Mood moves; family doesn't.
6. **Legibility floors** — body ≥14px, contrast ≥ WCAG AA on the realm's ground (the 12% mix bound exists to guarantee this), motion-reduction honored.
7. **The member's Contract** — thresholds, interrupt rules, tone clauses bind identically everywhere; a realm cannot buy louder access to a member.
8. **The meter's honesty** — compute/token display is system-rendered, uneditable by realm.
9. **DS core tokens** — no realm injects colors outside the palette or redefines `--accent`/`--kid-sun-gold` semantics.
10. **The ally's spoken voice.** In a realtime voice session, timbre, pacing, warmth, and interruption style are constant per ally, everywhere — a realm's rendering voice (row 1) drifts word choice and the pacing of ideas, never how the voice sounds. Audible identity is felt far more strongly than type mood ever was; a voice that changes personality mid-conversation reads as a different person, and barge-in trust doesn't survive that. (Resolved in Design R3, `OPEN-QUESTIONS.md` #5.)

## 3. The seven real realms, as points in the space

| Realm | ground hue | voice | compression | type mood | code skin |
|---|---|---|---|---|---|
| **Kinship Duna** | camel 8% | warm, direct, literary | balanced | 1.0 · body | ember |
| **BiHome** | sky-dark 8% + mint garnish | clinical, cited, calm | says-more (with confidence) | 0.95 · snug | ember |
| **Service Alliance** | chocolate 12% | practical, brief | says-less | 1.0 · dense | ticket |
| **Cosmic Humanity** | aubergine 12% / violet | quiet, spacious, unhurried | says-least | 1.1 · loose | ember, dim |
| **Fellowship of Play** | magenta-dark 10% + lime sparks | loud, alive | says-more, punchy | 1.15 · dense | ticket |
| **Party Line** | magenta-dark 12% | playful, telegraphic | says-less | 1.1 · dense | ticket/QR |
| **Lui Mutual** | navy 10% | sober, obligation-literate | says-more, precise | 0.9 · snug | printed QR |

The same claim rendered by BiHome and Fellowship of Play differs in hue, register, density, and garnish — and is identical in citation, ordering, correctability, and what gold means. That is the whole system.

## 4. Enforcement

Expression values live in the realm's graph configuration and are validated at write time (bounds above are schema, not convention). The client renders only from validated configs; there is no realm-supplied CSS/code path. A realm that wants a variable outside the bounds proposes a change *to this document* — expression space grows by legislation, not exception.

---

<!-- ===== SOURCE: design-r2/MOTION-SPEC.md ===== -->

# MOTION & TRANSITION SPEC
**Kidunaverse Design Round 2 · what Flutter/Flame must render · July 7, 2026**

The rule underneath all of it: **motion is weather, not reward.** Nothing loops to attract attention; nothing bounces; nothing celebrates. Things settle, rise, recede, and seal. Every animation is interruptible; every one has a static fallback (reduced-motion and battery-saver render the final frame).

---

## 1. The ground (Flame, constitutive)

The one place the game engine is a reason, not plumbing.

- **Layered gradient field:** 2–3 radial gradients over espresso, positions drifting on a ~60s noise loop ("breathing"). Amplitude is a realm variable (Cosmic Humanity barely moves; Fellowship of Play swells).
- **Realm temperature:** the gradient hues are the grounding state's realm mix (≤12% hue into espresso — see REALM-EXPRESSION.md). Rendered as a shader uniform so drift is a continuous crossfade, not a repaint.
- **Activity glow:** the ember (Kiduna mark) modulates brightness with org-wide activity, low-pass filtered over ~10 min. A pulse, never a spike.
- **Weather tint:** the Sentinel's read as a faint tint band high in the field (amber = harmony drifting warm). Tint only; never an icon, never a number on the ground.
- **Ember particles:** ≤12 gold particles, reserved for signature moments (code signed, seal committed, room sealed). 2–3s, gravity-soft, then gone. Never ambient.
- **Budget:** ≤1 shader pass + particles; must idle under 5% GPU on a mid Android phone; static fallback is the blended gradient's final frame.

## 2. Drift (grounding change)

- **Trigger:** grounding state change from the server (reading deep, replying, working, room convening). Never a tap target.
- **Duration/curve:** 800–1400ms, `easeInOutCubic`, duration scaling with "distance" (how different the two configurations are).
- **What interpolates, in loose sync (deliberately not lockstep — neighborhoods arrive unevenly):** ground hue mix → token chip crossfade (old fades under, new fades over, 400ms, offset +200ms) → grounding line text swap (fade through 0, offset +400ms) → type mood (display scale/tracking, 600ms).
- **Interruptible & reversible:** the state is a float blend between configurations; a reversal mid-flight retargets, never snaps.
- **Blends are legal states:** the member can *stand between* two realms indefinitely (reading BiHome inside a Service Alliance errand). Engine requirement: ground shader accepts two realm configs + weight.
- **Forbidden:** any border flash, toast, breadcrumb, or "entering X" copy. Drift makes no sound.

## 3. The Account rendering

- **Compose-on-look:** on attention, claims settle top-down — 8px rise + fade, 180ms each, 40ms stagger, no spring. Ink drying, not cards dealing.
- **While the Renderer streams:** a quiet caret in the ally's voice line; never a skeleton screen (skeletons promise content and train waiting).
- **Correction print:** the correction block types its first line (300ms), then settles. The one place type "arrives," because corrections are the accountability ritual.
- **Sealing:** when the member scrolls past the rendering's foot, the foot stamps its artifact line (opacity 0.6→1, 200ms). No sound, no particle.

## 4. The deck (Docket)

- **Arrival:** when the deck becomes non-empty, the paper edge slides up 12px from the bottom, once, with a real shadow, 350ms `easeOutQuart`. It then *rests*. No pulse, no loop, no idle motion ever.
- **Open:** pull up (or tap) — cards fan from the edge with mild spring (stiffness 220, damping 26, no overshoot >4px). The Thread dims to 0.85 and scales 0.97 beneath.
- **Flip:** card flips on Y, 500ms, to its context back.
- **Press-and-hold signature:** radial gold fill, 1000ms linear (the deliberate second — never shortened). Haptic ramp through the hold; on commit, a single heavy haptic + gold seal stamp (scale 1.06→1.0, 250ms) + ≤12 ember particles. Release before commit rolls back at 2× speed — abandoning a signature costs nothing.
- **Card exit:** signed cards exit upward, "filed," 300ms. Skipped cards slide under the deck.
- **The door:** the last card's exit is followed by the deck edge sliding away and the ground brightening +4% for one breath (2s), then settling. Emptiness is announced by *light*, not copy.

## 5. Rooms (summons → room → seal)

- **The bell:** the summons rises *from the ground* — ground brightens toward the convening realm's hue, app chrome dims out (300ms), the summons sets in Goudy like a title card (text fades up 400ms). No ringtone by default; the Contract may grant sound.
- **In the room:** one shared surface, identical for all present. Presence marks (members and allies) arrive as small lights settling into an arc. Code strikes render one by one — each a short gold line drawn to the founder's mark (240ms each, sequential; nineteen codes = a visible, countable act of witness).
- **The seal:** the room's content condenses — scale toward a single mark (600ms `easeInCubic`), which stamps (as §4) and then *drops* into the Thread as an artifact line. The room is gone; there is no "room history."
- **Engine requirement:** rooms are a synchronized scene (server-timed cues) — Flame renders cue-driven sequences where all clients see the same strike at the same moment. Latency masking by cue windows, not by desync.

## 6. The Vigil (lens)

- **Open:** from a citation/card-back tap or by asking. The Thread scales to 0.96 and dims 0.8 (250ms); the lens slides over with 8% translucency — home visibly persists beneath.
- **Live content:** working-set lines stream as they change (fade-swap, 150ms). HEARTS strip flexes as values move — continuous, not stepped.
- **Close:** swipe down or lean-out; the lens recedes (250ms), the Thread returns to 1.0. **No residue:** no history entry, no scroll restoration on reopen, nothing persisted.

## 7. Making (birth)

- **The shape card** (ally proposing the thing) settles like a claim.
- **Birth:** on the member's strike (press-and-hold, §4 semantics — a birth is a code act), the made-thing's card gains its name in Goudy and its code chip in one stamp. One ember moment. It then exists in the Thread like any other real object.
- Never: progress bars, spinners, "deploying…" — the Registrar's latency is masked by the ally's sentence ("She's live. I put her where the river crew will find her.").

## 8. Global grammar

| Gesture | Meaning | Everywhere |
|---|---|---|
| pull down from top | the Contract | yes |
| pull up from bottom edge | the deck (only if it exists) | yes |
| press-and-hold, 1s | signature (codes, votes, seals, births) | the only way to sign |
| tap a citation | the Vigil lens | yes |
| swipe lens down | lean out, no residue | yes |
| scroll | time (the Thread) | the only scroll |

Timing tokens: `settle 180ms` · `overlay 250ms` · `object 350ms` · `flip 500ms` · `drift 800–1400ms` · `hold 1000ms` · `seal 600ms`. Curves: `easeOutQuart` for arrivals, `easeInCubic` for departures, `easeInOutCubic` for drift. Springs only on the deck, damped, never on type.

---

<!-- ===== SOURCE: skill-updates/cofounder-canon-2026-07-09.md ===== -->

# Kidunaverse cofounder skill — canon delta · 2026-07-09

**Apply via Settings → Capabilities (installed skills are read-only in-session). Supplements the 2026-07-08 delta; where they conflict, this file wins.**

Three governance rulings became canon on July 8–9:

## 1. The gold grammar (final)

The gold ceremony — stamp, embers, haptic — marks **signed acts and nothing else, forever**. Things that happen *to* a member (promotion, milestone) are announced by **light**: the ground briefly brightening. Never fireworks for the unsigned; never a leaderboard.

## 2. The receipt rule (build requirement)

The plain sentence over a command receipt is **machine-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 command name, ugly on purpose, until honest generation exists. (Protocol §3.)

## 3. Registration — vocabulary and architecture (supersedes "accountable domain")

- **The word is "registered / unregistered."** Not "trusted." **Not "accountable" either** — registration proves traceability, nothing stronger. This supersedes the earlier canon rule "DNS TXT records make domains 'accountable.'" Unregistered renders as *"a stranger, not a threat"* — no red, no shields.
- **The decentralized Kiduna registry** publishes exactly four address kinds, mapping to the WV Secretary of State: **member** (FROST wallet address) · **ally** (agent NFT address inside that wallet) · **alliance** (Squads wallet address) · **organization** (Squads wallet address bound to its WV Org ID). Every registry entry terminates in a legally registered entity.
- **Kinship Codes carry the registry as JWT claims** referencing those addresses. JWT is ordinary internet plumbing, so the registry rides the regular internet — email, web, any app or messaging channel — with no new infrastructure.
- **Anything can be registered:** a domain (DNS TXT record), a web page or piece of content (embedded code), a photograph or video (hash). Registered = traceable back to a member, ally, alliance, organization, and through the Org ID to the SoS.

## 4. Organizer economics (SUPERSEDES "never quote organizer/lineage percentages")

- **Commissions attach only to Compute purchases** by an Organizer's Clan — USD/USDC exchanged for a duna's Compute, including the initial purchase — never to enrollment itself, work payouts, splits, or votes.
- **Clan tracked four generations deep.** Default schedule (all dunas unless changed; Kinship Duna at launch): **Gen 1 20% · Gen 2 5% · Gen 3 3% · Gen 4 2%.** The Catalyst sets a duna's schedule at founding; the Forum can change it.
- **Settlement:** USDC purchases pay organizers immediately on-chain; fiat (Stripe) purchases show in the organizer's wallet as **pending** — earned, recorded, not yet on-chain — until fiat bridges to the blockchain, expected monthly.
- **Lineage is optional per duna:** open door (no codes at all), invite-only, or invite-first-then-open.
- **Membership clarified:** the $100 lifetime membership is Kinship Duna's initial Compute purchase; each duna sets its own initial purchase. One wallet, one ally, one identity everywhere; membership is per duna.
- The old rule "never quote organizer/lineage percentages" is retired; the default schedule above is quotable canon. Counsel review of the compensation language continues in parallel (counsel brief item 6).

## 5. The Sentinel — Track 8 (site is now EIGHT tracks)

- **Members never see HEARTS** — no acronym, no meters, no scores, ever. They see effects (the Sentinel's behavior) and plain sentences on request or Contract-set disclosure. The member-facing word is **vibe**. Symmetry carries the seventh signal, inward and outward.
- **Meters are bipolar:** each of the six axes runs **−100 to +100 and health is ZERO** — every virtue fails in both directions (Harmony− = conflict, Harmony+ = people-pleasing). The Sentinel is a regulator guiding toward the zero point, never a maximizer.
- **Meters attach to fields (contexts), never to persons.** Readings decay and carry provenance. Human field and agentic field are measured separately and kept clean: attribution before measurement; **no agent ever optimizes a meter** (diagnosis, never reward); stated-scope withholding is health, not deception (settles the Vigil-vs-Sentinel tension).
- **Graduated bands** (initial): 0–30 quiet · 30–60 ambient agent-side correction · 60–85 plain-sentence disclosure · 85+ **hard boundary: stop correcting, convene humans**. Always-human regardless of band: crisis/harm, minors, legal privilege, coercion. Constitutionally non-configurable: never votes, never money, never public readings, never evidence in disputes.
- **Vibe contracts** = per-duna/alliance tolerance configuration (debate circle vs grief circle), Catalyst-set, Forum-changeable, one default at launch.
- **Build order is a requirement:** measurement first (observe-only), human escalation path second, ambient-correction autonomy last.

## 6. Legal — Track 9 (site is now NINE tracks); counsel's resolutions are canon

All seven counsel-brief questions resolved 2026-07-09 and adopted as rules in force (legal.html, priority order: securities · money transmission · organizer comp · worker classification · trust accounting · insurance · recusal). The queue lives on legal-items-for-review.html — legal NEVER goes on Open Questions.

**Binding on ALL public copy (securities messaging — treat as law):**
- Compute is always **"prepaid usage credits that power intelligent agents."** Everything reinforces consumption.
- 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 = **recognition only** (1,000 cap, gifts/swag fine); never implied to exist because an asset will appreciate.
- Organizer messaging: introducing people to a product they actually use — never an income opportunity. **No earnings claims without actual statistics.**
- Every engagement is "an independent commercial agreement between the member and the organization" (never employment language: no titles, reviews, schedules, exclusivity, mandatory training).
- Money movement: "workflow software, not a financial intermediary" — the platform never redirects, holds, or reverses; instructions fixed before money arrives.
- Lui Mutual is never called insurance before licensure; trust money in law dunas is radioactive (automation refuses it).
- Recusal is being generalized to a full conflict-of-interest policy (software-enforced; drafting open as L-13).
- Open legal stubs: ToS, Privacy, Kiduna Club IP licensing (min monthly + % of Compute sales), KII fiscal sponsorship (Service Alliance, Mycelial Aid, BiHome/Inner Clinic first), patent provisionals (update + new filing). Initial-purchase commission mitigation open as L-14.

## 7. v5.0 — the Surfaces, Chat & Move, relationships, the launch cohort (site is ELEVEN tracks)

- **Track 1 is "The Surfaces"** (supersedes "The Experience"). Four products, four homes: **Kiduna** — the Flutter/Flame mobile app (iOS/Android + identical web app at kiduna.app; App Store, Google Play); **Kiduna Express** — the Chrome extension (kiduna.express; Chrome Web Store); **Kidunaverse** — the account site (kidunaverse.com); **Kiduna Studio** — the desktop building surface (mac/Windows/Linux/Chromebook).
- **The app's two areas are Chat and Move.** "Move" SUPERSEDES "Reality" as the graphic surface's name; the sim-flagged experiences formerly "Reality Games" are now **Games** (Kidunaversity first; nothing inside a Game affects the Kidunaverse). In Move the member still only converses with their ally, but steers — and can see ally↔ally and ally↔actor interactions, with goals and contextual actions. Where finished art doesn't exist, models + orchestration generate bounded spaces; generative tooling (ImageGen, Gemini) covers tiles/sprites/particles/HUD.
- **CANON: between two people it is a "relationship," never a "connection."** The Foundation node renamed Relationship; grants live on the Relationship. Studio's purpose is DESIGNING relationships (both sides inform: what you share/expose, what you learn/maintain) — and the same design applies to guilds, alliances, organizations as containers.
- **Studio** is agentic, not segmented (Cowork/Codex-style desktop app): building organizations, deep collaboration (sharing/modifying/connecting skills, knowledge bases, prompts, automations), and above all **communications between allies** — Bluesky, Telegram, and direct back-channel ally↔ally conversations, contextualized by the container. Studio interoperates with Claude Cowork/Code and OpenAI Codex locally, and connects MCP servers scoped to containers.
- **Kidunaverse.com** holds the **protocol browser** (the audit trail, navigable, access-scoped) and onboarding with **three USDC options at the $100 step**: Stripe headless onramp · connect a Solana wallet · send USDC to the new wallet (copy address). Stripe key expected imminently; UX in design round 5.
- **Tracks 10 & 11:** Institutions (KII — kinship.institute, purpose/fiscal sponsor; Kinship Systems — kinship.systems, labor; Kiduna Club — kinship.club, property/IP licensor) and Integrations (inward MCP/APIs/local agents scoped to containers; outward our own API + MCP server, no privileged path — "a tool under grants, never a party with standing").
- **The launch cohort (all start within Kiduna Club; participation never limited to their seat):** Catalysts — Dave & Susan Thompson (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). Luminaries — Howard Teich (Cosmic Humanity + Vibe Coast), Four Arrows (Indigenous Revival), Renée Smith (Mapshifting), **Mama Ayo (Black Love — now Luminary, was Catalyst)**, Bill Thatcher (Soul Kitchen), Darcia Narvaez (Homeworld).
- Build status (7/9): pgvector replacing Pinecone live; graph nodes for registration/onboarding landing; **the implemented visibility enum is missing "secret" — flagged, not optional.**

## 8. v5.2 — Create from Within (2026-07-10; MAJOR)

- **The method is "Create from Within"** (canonical; create-from-within.html): build the minimum necessary to start creating WITH the system, then create everything else from inside. NOT an MVP, NOT lean/agile — only possible with intelligent/probabilistic agents. First target: Moto sets up his ally and invites **swyx** (Shawn Wang, "The Rise of the AI Engineer"), prepared by the **Profiler** — the first Program (inputs: name+handles, defining works, relationship-in-a-sentence, the why, landing container + starting grants). **Every code/invite is unique to one person; the member prepares the system for who they're inviting.**
- **Modes are Chat and LIVE** ("Live" SUPERSEDES "Move" as the mode name). **Moves** = the authored Live experiences (scenes, vibes, games — the new name), built in Studio; Kidunaversity is the first; sim-flagged Moves never affect the Kidunaverse.
- **SIX surfaces:** Kiduna (mobile app, first KAP client, kiduna.app) · Kiduna Live (kiduna.live, Live alone) · Kiduna One (kiduna.one, Chat alone) · Kiduna Studio (desktop + kiduna.studio; NOT vibe-coding; create/maintain ally, invite, develop Moves; package-passing protocol with Claude Code/Codex modeled on the dispatch protocol) · Kiduna Express (kiduna.express) · Kidunaverse (kidunaverse.com; onboarding/registration, metrics, publishing, directories — **kidunaverse.com/handle** is a member's or ally's page; "handle" NEVER "username"; handles unique across members AND allies).
- **KAP formalized:** the Kinship Agency Protocol = everything connecting servers↔servers and servers↔clients; people install **Agency Servers** and **Agency Clients**; one server-side installation = an **ecosystem**; **the Genesis Ecosystem is Kiduna**, purpose: PROPAGATE (generate ecosystems worldwide, interoperating, decentralized); requires a **Genesis Profile** at install. **Everything Apache 2.0, launching Aug 10** (open code, licensed marks — Kiduna Club keeps the brand; L-17 review). KAP stewarded by **Kinship Agents DAO, LLC** (new Institution).
- **Hierarchy (canon):** Ecosystem (foundation) → Organization (duna) → Alliance → Guild → Ally → Member. **Institutions are a special type of Alliance OUTSIDE the hierarchy** (restrict membership, sponsor accounts, always tied to a non-DUNA legal entity).
- **Sources and Ki:** the owner of an ally is its **Source** (never handler/principal). **Every ally is really the Genesis Ally — Ki — personalized** by Source context. Allies are NFTs; transferable; co-owned only via a Squads wallet (holders vote to instruct as the Source). The Source commands through any channel; others can talk, never command. Path: Source 1 → Ally 1 → Ally 2 → Source 2. Ki onboards guests/members (replaces the generic "Host").
- **Site refocus:** kiduna.team is no longer team-only — it's how we build and how anyone participates as Builder or Creator. The download is the **KIDUNA KIT** (never "Core Team Package"), for anyone.
- **Lightbrush LLC** = first Institution integration (Moe; Dowbot/Zhowbot/Digital Dolly/RenderDeck/audio stack → The Ceremony Machine; Elias = forward-deployed engineer at no cost; ALL Lightbrush IP stays Lightbrush's; agreement Kinship Systems LLC ↔ Lightbrush LLC, L-16).

Spec: Create from Within (create-from-within.html); Surfaces (surfaces.html, Track 1), Institutions (Track 10), Integrations (Track 11), Legal (legal.html, Track 9) + legal-items-for-review.html; The Sentinel (sentinel.html, Track 8), Protocol §1a/§2/§4, Foundation §2/§6, Orchestration §1/§5, Roles §1–2, Organizations §2–4, Real Work Real Money §3 on kiduna.team.

---

<!-- ===== SOURCE: skill-updates/nightpapers-canon-2026-07-09.md ===== -->

# Nightpapers skill — canon delta · 2026-07-09

**Apply via Settings → Capabilities. Supplements the 2026-07-08 delta.**

For the genesis nightpaper's protocol material, three rulings are now canon:

1. **Gold marks signed acts only, forever;** promotions and milestones are announced by light (the ground brightening). Any passage about ceremony must respect this split.
2. **Receipt sentences are machine-generated** from a duna command's own parameters — never hand-written — so what members read and what executes cannot diverge. A strong essay beat: the bank statement, not the teller's note.
3. **The Sentinel (Track 8; the site is eight tracks now).** Interaction health runs on bipolar meters where **zero is health** — too much harmony is as unhealthy as conflict. Members never see the instrument (no acronym, no meters; the word is **vibe**), only its effects. The regulator guides toward the zero point and surrenders to humans past hard thresholds. Essay beats: the thermostat, not the scoreboard; the meeting that didn't steamroll its quietest voice; a regulator that earns autonomy last (measurement → escalation → correction).
4. **"Registered," not "trusted" or "accountable."** The decentralized Kiduna registry holds four address kinds (member FROST wallet · ally NFT · alliance Squads wallet · organization Squads wallet + WV Org ID); Kinship Codes carry them as JWT claims across the ordinary internet; anything — domain, page, content, photo, video — can register and become traceable to a member and a legal entity. The paper's honesty argument: we name only what the mechanism proves. Unregistered is "a stranger, not a threat."
