The agents do the work of the organization. The member's job is a relationship: teach your ally, correct it, read its account of the day, and sign what only you can sign. Everything else in this document follows from that.

## Part I — The shift

### What we have been building, without meaning to

Every app any of us has ever shipped makes the same silent assumption: the person does the work. The software is a set of surfaces — tabs, forms, lists, settings — and value comes out when a human operates them. That assumption is so deep we rebuilt it here without noticing: a Chat tab, a Create tab with five configuration sections, a Govern tab you visit to vote. A very good 2019 app.

Kiduna is not that. Kinship Duna is an organization whose workforce is mostly agents. It runs continuously — researching, drafting, negotiating, posting, tallying, paying, connecting — whether or not any member is looking at a screen. When agents do the work, an interface built from places-you-go-to-do-things answers a question nobody asked.

The member does not operate Kiduna. The member relates to their ally: teaches it, corrects it, gives it standing instructions, reads its account of what happened, signs what only a human sovereign can sign — and comes to trust it the way you trust a person, by watching what it does over time. Intervention is the exception, and when it happens it is meaningful: a vote, a code, a blessing, a correction. If we ever find ourselves designing a screen where a member fills in a form to make something happen, the error is upstream; the right question is always which agent does this work, and how does the member learn it happened.

### The two worlds

This is the frame everything else in this document hangs on.

The app is agent-centric. It is one place, with one relationship at its center: the member and their ally. Everything in it is mediated by agents — the member speaks to their ally, and the ally deals with every other agent: the allies of other members, the programs of dunas, the machinery of governance. A member never negotiates with another member’s ally, never files anything with the Operator, never queries the graph. Their ally does all of it, and gives an account. The app is where the member and their ally work together.

Everywhere else is people-centric. On Telegram, on Bluesky, at the farmers market, in a group chat with your hiking crew — people interact with people. That is what those places are for and Kiduna does not try to change it. What changes is that your ally can hold a presence there: administering and moderating the communities you run, responding on your behalf when you’ve allowed it and always marked as your ally, meeting people who are interested and enrolling them — extending codes, walking them in. The ally in people-space is staff, not a substitute for you. Nobody’s Telegram becomes another app surface; your friends still text you.

The bridge between the two worlds is the Kinship Code — the one object that carries verifiable trust across any channel — and the discipline is simple: agents broker everything inside; agents serve people outside.

### Ambient awareness — the scope of it

Dozens of agents will act for a single member in a single day: messages answered, research folded into wisdom, check-ins collected, a group moderated overnight, a negotiation advanced two rounds, compute metered. No human can supervise that volume and no human should. What replaces supervision is a covenant with three parts: awareness (the Account — a true-enough picture in minutes), account-ability (the Seal — a signed record with receipts), and audit (the Vigil — lean in on anything, on demand). That covenant is what replaces “checking the app,” and Part II derives each part from scratch.

### What this kills

Tabs as destinations. Forms as the way things happen. Settings pages. Notification trays. Feeds. “Checking.” The idea that Organize, Govern, and Create are rooms — they survive only as names for work the agents do. The v3 spec still half-believes the old thing; this document is the source for its inversion.

## Part II — The member moments, from first principles

Method, stated once and applied everywhere: for each moment, name the invariant function (what must be true regardless of design), derive the constraints that follow from it, choose the form last, and mark the skin — the metaphor, the styling — as explicitly replaceable. Metaphors are rented, never load-bearing. The newspaper taught us that: “daily” and “broadsheet” had crept from costume into architecture, and neither survives the derivation below.

### 1. The Thread — the relationship itself

Function: the member needs one continuous working relationship with the agent that represents them — the place where teaching, asking, directing, and being answered happens. Constraints: exactly one counterpart (the ally; every other agent reaches the member through it); everything the system can do must be reachable by saying so; voice and text are the same relationship, not two features; the relationship is ambient — one relationship, many doors. The ally hears its member wherever it has presence: an instruction given on Telegram at midnight is as binding as one given in the app, and lands in the same relationship. The app is not the only door; it is the place with the full instrumentation (the Account rendered, the Docket, the Vigil). The relationship’s history is memory, but memory is artifacts, not an infinite scrollback the member must manage. Form: a conversation. The oldest form there is, and correct. Skin: chat styling. Replaceable; the relationship isn’t.

### 2. The Account — awareness

Function: a true-enough model of everything done in the member’s name and everything moving in their organizations, at the cost of minutes of attention, without training compulsive checking.

Constraints, derived:

- Synthesis, not stream. A feed makes the member the integrator of raw events — the old paradigm’s core move plus its worst economics (infinite surface, recency ordering, variable-ratio reward). Integration is the ally’s work. The Account presents claims — “Rosa grew the alliance; here’s what it means for you” — each cited to its graph sources.
- Continuous ledger, attention-driven rendering. The organization doesn’t have a publication schedule and neither does awareness. The ledger of claims is maintained continuously; what the member sees is composed at the moment they look, covering exactly the interval since they last looked. Since-you-were-gone, whether that’s forty minutes or nine days — with compression scaling to the gap: a week away yields deeper synthesis, not seven times the text.
- Consequence-ordered, never recency-ordered. Recency ordering is the feed sneaking back in. The first thing you read is the thing that matters most to you.
- Interrupts only by contract. Between renderings, silence — except events that cross the threshold the member set in their Contract (§7). An interrupt that arrives is one the member already agreed they’d want.
- Every rendering persists and is correctable. Each rendering is an artifact. Contest a claim and the correction propagates to memory and prints in the next rendering. Corrections are how an agentic organization does accountability; this property outranks any skin.
- Readable and droppable. Nothing happens if you stop reading. The Account is never a task list.

Form: a structured beat inside the Thread — the ally telling you, scannably and with citations, what happened since you were gone. Not a separate surface; awareness is part of the relationship. The weather line (the Sentinel’s read of your circles) and the wire (the organization-wide pulse) are sections of it; the compute meter rides its header. Skin: rendering style — and this is a duna-level grounding. BiHome renders the Account clinically; Fellowship of Play renders it loud; Cosmic Humanity renders it quiet. A member who wants a morning ritual can schedule one; that’s a preference, not architecture. “The Edition” is retired as a primitive and survives only as one possible skin.

### 3. The Docket — sovereignty

Function: some acts are constitutionally non-delegable — votes, code signings, blessings on new organizations, answers only the member can give. These must reach the member reliably, with exactly the information a decision needs, and nothing else riding along. Constraints, derived: a bounded set (unbounded pending-items is an inbox, and an inbox is a task-generator — the anxiety machine we refuse to rebuild); consequence-stated (the decision-relevant fact is what signing does, not the data behind it — “passes with or without you; your signature moves the precedent”); context-inspectable (trust requires seeing exactly what the ally used to prepare it); emptiness is success (“nothing needs you” is the system working); acts must be unmistakably the member’s (the gesture of signing should not be confusable with dismissing a notification). Form: a small deck the ally presents — take a card, decide, flip it for its context, done. Skin: the card, and press-and-hold for signatures. Both replaceable in principle; press-and-hold earns its keep as ritual — a signature should cost one deliberate second.

### 4. The Seal — attestation

Function: delegation without accountability is abdication. At bounded intervals the member must be able to attest — or contest — everything done in their name. Constraints, derived: the interval must be bounded (an open-ended “review sometime” never happens; signatures need periods the way audits do); short enough that memory serves, long enough that the act stays meaningful — weekly is the derived default, and it’s the one legitimately periodic thing in the system, because the period serves the signature, not the information (the Account already handled information); duna policy may bound how loose a member can set it; every line carries receipts (artifact links); a contested line becomes a card — the audit loop closes through the Docket; the signed Seal enters the graph as the member’s attestation. Form: one page, weekly, in the Thread; sign or contest. Skin: the name “Seal,” the signature styling.

### 5. Codes — trust extension

Function: trust must move between people — and across the two worlds — in a way that is verifiable regardless of the channel it traveled. Constraints, derived: issuing is human-sovereign (extending your trust is never delegated — it’s always a Docket act); the object is self-contained and verifiable (signed, checkable against the endpoint; the code is verifiable because the channel never is); exchange is bidirectional at first agent-contact, and either side may demand re-presentation at any time; scope is explicit (context, role, expiry, binding, uses); redemption forms the relationship in the graph. Form: the signed JWT and the exchange protocol (Appendix 4 of the spec stands). Skin: how a code looks when it travels — an ember, a ticket, a printed QR at a festival gate. Entirely per-duna.

### 6. Rooms — ceremony

Function: some acts only bind if they are witnessed together — the formation of an organization, the first strike of its codes, the repair of a rupture. Asynchronous approval produces the same database rows and none of the same reality. Constraints, derived: rare (ceremony inflated is ceremony destroyed); convened, not browsed (a room is entered at a time, together — the bell that summons you is negotiated by your ally against your Contract); bounded and resolving (every room ends, and ends in something: an outcome, an artifact, a sealed record — never a channel left open); witnessed (presence is part of the record; your ally attends and can stand for you, and the difference is recorded). Form: live rooms with members and allies co-present, presided by the relevant program (the Launcher for spin-outs, the Repairsmith for repairs). Skin: the bell, moonrise scheduling, how a room looks in a given duna. Cosmic Humanity’s rooms and Fellowship of Play’s rooms should not feel alike, and won’t.

### 7. The Contract — standing instructions

Function: delegation this deep requires an agreement both parties can read: what the ally may do, when it may interrupt, what tone it keeps, what it must never do without asking. Constraints, derived: prose, not settings (the member should change the sentence, not hunt a toggle; a sentence carries nuance a switch can’t); short (a contract nobody can recite governs nobody); versioned (every behavior change in the ally traces to either a contract edit or a correction — the two levers, and only those two); quoted back (the ally restates the relevant clause when it acts near an edge: “your contract says weekends are for the trail, so I held this until Monday”). Form: a few sentences at the top of the relationship, editable in place, echoed wherever they bind. Skin: “the masthead” is retired with the newspaper; it’s simply the Contract now.

### 8. The Vigil — audit

Function: trust in an agent workforce is built by being able to watch, not by watching. The member must be able to drop into any live workstream and see exactly what their ally is doing and holding — and must never be made to feel they should. Constraints, derived: on demand from anywhere (any claim in the Account, any card in the Docket — “show me what you’re doing right now”); total within scope (the working set is fully inspectable: the graph facts, artifacts, code chain, HEARTS state in play); never the default posture (a home built from surveillance converts delegation into anxiety and punishes the ally for legible reasoning); asymmetric by design (you see your ally’s private lane; the counterpart member sees theirs; nobody sees across — one open question from the spec, Vigil-vs-Sentinel reconciliation, still stands). Form: a lens that opens over the Thread, live. Skin: minimal; it’s an engine-room window either way.

Eight moments. Everything a member ever does is one of these, and each survives its own derivation or gets rebuilt until it does.

## Part III — The mechanics, base by base

### 1. The two worlds in practice: presence on Telegram, Bluesky, and the rest

Get the model right and every channel question answers itself. Outside networks are where people live. The ally goes there as staff. Four presence roles, each separately granted, each scoped by the Contract and by ToolConnection scopes in the graph:

- Representative. When someone messages you and you’ve allowed it, your ally may respond — always identified as your ally, never impersonating you. Its judgment about what it may say comes from context, wisdom scopes, and your Contract; anything past its scope becomes a line in your Account or, if it’s consequential, a card. Your friends still reach you; your ally handles what you’d have delegated to a good assistant, visibly.
- Administrator. Communities you run — the alliance’s Telegram group, the duna’s Discord, the event’s channel — get the ally as moderator and operator: onboarding new arrivals, holding the gate (code checks for entry where the group demands it), keeping house rules, answering the questions that have answers. The Fellowship of Play’s gate crew is people; the group’s 3am spam problem is the ally’s.
- Enroller. The growth engine, and the reason presence matters strategically. Someone in your hiking group asks about “this organization thing” — your ally can carry the conversation, answer honestly, and when the person is ready, request a code from you (a Docket card: extending trust is always yours) and walk them through the door. Enrollment happens where people already are, person to person, with the agent doing the paperwork invisibly.
- Publisher. Posting as you or as the organization (the Envoy’s version), within the Contract: the BiHome digest to its Bluesky, the festival announcement, your own “we’re doing trail day Sunday” that you asked it to put out.

Presence is also the ally’s ears. The ally hears its member everywhere it has presence — instructions given over Telegram, a voice note from the trail, a forwarded link with “look into this” — all of it lands in the same relationship, as binding as anything said in the app. And it hears other people, continuously, on a wide range of topics: the alliance group’s chatter, a reply to your Bluesky post, what Dana said about her sleep. It is always building context — and it weights what it hears by source: your word is instruction; a code-holding alliance member’s word is trusted context at the scope their code encodes; a stranger’s word is unverified signal, held as such. Relationship history, code standing, and the Contract set the weights; nothing heard is treated as flat. The distinction between the worlds survives intact — in the app, agents broker everything; out there, people talk to people and the ally serves — but the relationship itself has many doors, and the app is simply the one with the full instrumentation.

First contact, reframed. When an unknown agent or person approaches your presence, the Gatekeeper runs the code exchange before anything else: code-holders get their encoded scope; strangers get courtesy, a path, and a line in your Account (“held at the gate,” reasoning available). Spam and impersonation die at the protocol layer, not in your attention.

Connecting an account is granting presence. It’s a conversation with your ally ending in the platform’s own OAuth consent — the one honest form in the system — followed by the ally stating, in one sentence each, what it now may do there and what it never will without asking. The connection binds a code to the account, which is what lets codes delivered through that account inherit identity verification.

### 2. Memory: how the vector database actually gets updated

Nobody updates a vector database — that sentence should never describe a human act. The loop runs on one rule: the graph is truth; artifacts are memory; vectors are searchable meaning; LLM context is temporary. Work completes → an Artifact is written (a sealed conversation, a resolved gathering, a delivered check-in, an Account rendering, a moderation log) → the Archivist records it with privacy state → the Embedder chunks and embeds into pgvector in the same Postgres → the Distiller periodically re-derives the five vector families (Experience, Qualities, Values, Challenges, Aspirations) per member, so the ally’s sense of its member deepens from evidence rather than a profile form.

The member’s levers are relational, and there are exactly three: tell (say something about yourself; it becomes artifact, then vectors), correct (contest a claim in an Account rendering or a Seal line; the artifact is amended, embeddings regenerate, the correction prints), and ask (“what did you learn about me this month?” — answered from the Distiller’s output in plain language). Align’s personal section is the first lever dressed formally.

Wisdom rides the same pipeline at organizational scale: hand the ally files, or say “build me wisdom about X” — a Researcher gathers, a Librarian maintains (dedupe, staleness, citation health), and the result registers in the graph with its privacy mode (public / private / secret), governing both Seek visibility and embedding scope.

### 3. Skills: maintained and propagated like a living package system

A skill is a versioned artifact — procedural knowledge with semver, owner, changelog, privacy mode. The team authors defaults in Studio today; the Steward owns staged rollout (team allies → volunteers → everyone, rollback on error-rate); the Examiner tests every submission against its stated examples before even private publication. Propagation is subscription by membership: join a duna, receive its skills. Promotion to default is a proposal — the skill registry and the policy list are siblings in the graph, which means how we do things here is literally legislated.

### 4. Alliances: the smallest institution, alive in both worlds

Introducing an alliance: a member tells their ally who it’s for and why; the one-sentence charter becomes the first artifact; codes go out; redemptions form the node. From then on every member’s ally carries shared, scoped context for it — and the alliance usually lives in both worlds at once: the people in a Telegram group being people, the allies present as staff (collecting the check-in across three platforms, holding the gate, keeping the shared wisdom current).

Alliances differ on five real axes, and members feel each: charter (purpose, grounding every agent action inside it), wisdom (what it knows together, often commons-held), rhythm (its pulse — worked by agents, felt by people), code policy (who may invite, how far trust extends), and vibe (its HEARTS contract; one default now, differentiated later — a debate circle and a grief circle should not be regulated identically). Your ally speaks differently inside different alliances for the same reason you do.

### 5. Dunas: a configuration, not an app

A duna is exactly seven graph-real things: a baseline prompt (voice and values), default wisdom, default skills, its programs (the organizational agents it employs), its policies (the legislated rulebook), its ceremonies (what gets convened), and its rendering (how the Account and its surfaces feel — the skin layer Part II kept separating out, now formally part of the grounding). Same member, same ally, different ground. This is the factory thesis in one line: build the workers once; a duna is a grounding. Launching an organization is authoring a configuration.

## Part IV — The workers we actually develop

The named agents members meet (Ally, Host, Operator, Elector, Envoy, Launcher, Sentinel) are the cast. What we build is the crew: LangGraph workflows with triggers, graph commands, and model tiers — S (small: routing, gathering, classification), M (mid: drafting, summarizing, moderating), L (frontier: negotiation, spin-outs, anything HEARTS-heavy). Changes from v1 of this document are marked ●.

Worker | Serves | Trigger | Does | Tier
--- | --- | --- | --- | ---
Switchboard | presence | inbound events, any platform | resolves identity → routes to the right ally’s presence with the right scope | S
Gatekeeper | presence | first contact / code challenge | bidirectional code exchange; verifies against endpoint; opens, bounds, or courteously holds | S
Presence adapters ● (Telegram, Bluesky, Gmail/Calendar, plugin bridge) | presence | platform events | translate platform ↔︎ graph commands; enforce ToolConnection scopes | S
Moderator ● | presence | community activity | admin/moderation duties in groups the member or org runs: onboarding, gate-holding, house rules, FAQ | M
Enroller ● | presence | interest signals | carries the interested-person conversation in people-space; requests the code (a card — always the member’s act); walks the newcomer in | M
Ledgerkeeper ● (was Gatherer) | Account | continuous | maintains each member’s claim ledger from graph events: what happened, what it means to them, consequence-ranked | S
Renderer ● (was Editor) | Account | member attention + contract thresholds | composes since-you-were-gone at the moment of looking; compression scales with the gap; cites every claim | M
Corrector | Account | each rendering | diffs prior claims against the graph; prints corrections; routes contested claims to memory amendment | S
Clerk | Docket | sovereignty events | assembles cards; writes the consequence statement; prepares card-back context | M
Sealer | Seal | weekly (member-tuned) | compiles the attestation with receipts; contested lines become cards | M
Archivist | memory | work completion | writes artifacts with privacy state, hashes, source edges | S
Embedder | memory | kg_event outbox | chunk → embed → pgvector, privacy-scoped | S
Distiller | memory | weekly per member | re-derives the five vector families from artifact evidence | M
Researcher | Wisdom | “build wisdom about X” / feeds | deep agent: gather → assess → structure | L
Librarian | Wisdom | continuous | dedupe, staleness, citation health, embedding refresh | S
Examiner | Skills | submissions | tests skills against stated examples; blocks unexamined propagation | M
Steward | Skills | releases | semver, staged rollout, rollback on error-rate | S
Drafter | Operator | proposal intents | member intent → well-formed proposal with treasury math | M
Marketmaker | Elector | open markets | pass/fail token books; settlement | S
Tallyman | Govern | deadlines | closes gatherings; every one resolves — enforced | S
Scribe | Govern | passed outcomes | writes Policy nodes; maintains the living rulebook and its lineage | S
Classifier | Sentinel | sampled exchanges | fast seven-signal HEARTS read | S
Modulator | Sentinel | band thresholds | corrections through ally behavior: tone, pacing, structure | M
Repairsmith | Sentinel | ±61+ | repair protocols; convenes repair rooms; human referral at bounds | L
Charterer | Launcher | spin-out intents | charter, membership design, starter policies, with the founder | L
Registrar | Launcher | spin-out execution | founding codes, duna configuration, filings | M
Poster | Envoy | org communications | posts as the organization, inside Envoy policy | M
Meter | Earn | continuous | usage → 7x → balance; the Account’s header line | S
Concierge | Host | new members | conversational onboarding; the welcome Account; hands off to the named ally | M

Twenty-nine workers; the three new ones (Moderator, Enroller, and the adapters’ presence reframe) all serve the people-space model. Most are S-tier and boring on purpose; design and eval effort concentrates in the seven that carry judgment: Renderer, Clerk, Researcher, Charterer, Modulator, Enroller, Concierge. Every worker acts only through graph commands; none holds authority; all of it traces in LangSmith. This table is the backlog.

## Part V — Kinship Duna, running

A composite week, buildable from the roster above. Note what’s absent: no publication times, no one “checking” anything.

Sunday night. The Distiller has run; twelve allies know their members slightly better. The Steward promotes governing-skills v1.3 to everyone; the changelog is a wire-line in whoever’s next rendering.

Monday, 7:04am. A new member — paid Saturday, wallet created, Ally NFT minted at naming; she called him Bracken. She opens the Thread for the first time and the Concierge’s welcome Account renders: the organization’s story in eight paragraphs, what Bracken already does, her first three cards. She answers one Sentinel question about interruption thresholds — her Contract’s first clause. No forms, anywhere.

Tuesday. A member’s rough idea — pay member-organizers for onboarding cohorts — reaches the Operator through her ally; the Drafter returns proposal #21 with treasury math. Clerks cut cards across the membership, each with the consequence stated for that member.

Wednesday. Cosmic Humanity’s founder begins with the Launcher; the Charterer works in her own Thread across three days. Her ally negotiates founding terms with two other allies; both members drop into the Vigil twice, whisper once, intervene never. Meanwhile a stranger DMs a member’s Telegram presence; the Gatekeeper holds him courteously at the gate; the member’s next rendering gives it one line. She doesn’t expand it. That’s the point.

Thursday, 11:40pm. A member gets home from a shift and opens the Thread. Since-you-were-gone covers two days in nine claims, consequence-first: proposal #21 needs her (card waiting, closes Friday); her Sleep Circle’s check-in collected without her (she was on nights — her ally answered for the logistics and flagged the personal question for her); the Cosmic Humanity room is Sunday. Four minutes, done, phone down.

Friday. The Tallyman closes #21; the Scribe writes the policy. Fourteen signed, nine let it run, everyone’s ledger carries their own relation to it (“you signed for; it passed; the stipend precedent now exists”).

Sunday, 7pm. The week’s one bell: Cosmic Humanity spins out, witnessed; the Registrar strikes nineteen founding codes in the room. An hour later every member’s Seal arrives in their Thread: the week, one page, receipts. Sign or contest. Two members contest one line each; both corrections will print.

And the team — us — are members zero. Our allies keep our presence in the dev Telegram, our standups render as since-you-were-gone over the repos, spec versions are proposals, claimed open questions are missions. If the system can’t run its own builders, it isn’t ready for anyone else.

## Part VI — Real dunas, worked in detail

Four configurations of the same twenty-nine workers. Watch what changes (grounding, presence, rendering) and what doesn’t (every primitive from Part II).

### BiHome — health, wellness, and the living literature

Purpose. Really understanding your own body and taking care of it, with the current research within arm’s reach — an organization of people taking their health seriously together.

Configuration. Baseline prompt: careful, cited, never diagnostic, allergic to wellness-hype. Default wisdom: the BiHome Corpus — Researcher/Librarian pipelines reading PubMed, preprints, retraction watch, with translation that keeps confidence levels attached. Skills: how to read a study; how to build a personal protocol; how to self-experiment safely. Programs: the Registry (its research-watching program), a health-tuned Concierge. Policies: health data is secret-tier, full stop; no product promotion without a passed proposal. Rendering: clinical and calm — claims carry confidence intervals; the weather line reads like a good GP, not a horoscope.

The member experience. Your ally asks — once, gently, over weeks — about sleep, movement, what your body is telling you; all of it secret wisdom only your ally reads. Then the organization works. Your since-you-were-gone carries a BiHome section when there’s something real: two studies relevant to your profile, translated, with what changed since you last cared about the question. Bloodwork lands in Drive; your ally reads it into secret wisdom and adjusts what it watches. A new paper contradicts your protocol’s assumption — that’s a card, consequence stated, sources on the back.

Presence. BiHome’s Bluesky digest is the Poster’s work; members’ allies moderate the condition-group Telegrams (the Sleep Circle’s group is people swapping 2am notes — the ally is the one keeping the archive, collecting the weekly check-in across time zones, and holding the gate); the Enroller does its quiet best work here, because health conversations happen person-to-person and “you should look at BiHome” now comes with someone who can actually walk you in.

Alliances. Condition, practice, and season-of-life circles — a Sleep Circle, a Lyme alliance, strength-after-sixty, new parents. Real because of shared wisdom (commons-held, anonymized experiments), rhythm (agents collect; people connect), and vibe (a gentler HEARTS contract than the biohacker cohort runs, eventually literally).

### Lui Mutual — the legal duna that assembles an insurance company

Purpose. Members pooling real risk for each other — mutual insurance rebuilt on the one legal form that lets a member-owned pool exist without a corporate shell, in the most procedural industry on earth. The stress test: if the paradigm works here, it works anywhere.

Configuration. Baseline prompt: precise, obligation-literate, zero improvisation on regulated ground. Wisdom: the regulatory corpus with change-watchers on the WV code; the pool’s actuarial tables, member-owned. Programs: the Actuary (continuous pool modeling, L-tier, duna-specific), the Assessor (claims evaluation) — and a human-professional docket: licensed counsel and actuaries are members whose own Dockets carry the signatures only license-holders can make. Some sovereignty belongs to credentials; the Docket already knows how to route it. Rendering: sober; the pool’s health reads like weather — reserves, claims ratio, the Actuary’s confidence band, plain language.

The member experience. Underwriting is a conversation your ally has on your behalf, sharing nothing secret without a card. A claim is a gathering: you tell your ally what happened; it assembles evidence artifacts; the Assessor evaluates against the policy list — and “policy” means both things at once, because the insurance policy IS a Policy node, legislated by proposals. Routine claims resolve in hours, reasoning on the card-back; contested claims convene a room, witnessed and precedent-setting; claims decisions become underwriting policy the way cases become law, Scribe-maintained.

The honest line for partners: this duna ships last and slowest — the regulatory questions are real, counsel is in the loop from the charter. It’s here because it proves the ceiling.

### Cosmic Humanity — archetypal depth psychology

Purpose. A society for meaning-making — dreams, archetypes, the examined inner life. Filed, real, and the best test of the parts of the system that aren’t about efficiency at all.

Configuration. Baseline prompt: a literate companion in symbolic work — knows the corpus (Jung, Hillman, von Franz, the mythologies), holds ambiguity without collapsing it, and never plays therapist; the line is constitutional, and the Modulator watches Symmetry-inward hard, because rumination is this duna’s occupational hazard. Wisdom: the archetypal corpus public; every dream journal secret, always. Skills: dream capture (voice, 6am, half-awake — the voice interface earns its keep), amplification method, active imagination. Ceremonies: this duna lives in rooms more than any other — moon rooms, seasonal thresholds, witnessed passages. Rendering: quiet, spacious, unhurried; the Account here would rather say less.

The member experience. You mumble a dream at your phone before it evaporates. By the time you next look, your ally has held it against the corpus — not interpreted for you, but amplified: the motifs, where the image appears across three mythologies, what you dreamed in March that rhymes. Your dream circle — five members, secret wisdom held in common, fierce code policy — meets monthly in a convened room; allies prepare the motif-map beforehand; humans do the work in the room, because that is the point.

What it teaches the platform: privacy at maximum, ceremony first-class, agents as preparation for human depth rather than replacement of it.

### The Fellowship of Play & Party Line — festivals and gatherings

Purpose. Organizations that exist to convene joy — festivals, parties, scenes. Both filed. The dunas where presence and the Commons seed show first, because these members already live in groups and already think in worlds.

Configuration. Baseline prompt: playful, logistical under the hood, consent-literate (Safeword is a sibling duna; shared skills). Wisdom: venues, artists, production lore. Programs: the Producer (event orchestration — the swarm coordinator) and an Envoy doing heavy outward duty. Rendering: loud, visual, alive — the same claims BiHome would whisper, shouted.

The member experience. A ticket is a Kinship Code — bound to you, embedded in the event page, verifiable at the door by an ally with a phone, transferable only per the event’s code policy. The event is a Gathering in the graph months early: the lineup forms as proposals (members vote the bill), crews form as alliances — and here the two-worlds model does its clearest work: the gate crew’s Telegram group is people running a gate together, while their allies hold the roster, route “four more hands at six” to exactly the members who said yes to that kind of ask, and keep the gate list synced to the code ledger. The org’s socials are the Poster’s; artists’ agents DM the Envoy’s presence and get code-gated, which quietly kills scalper bots and fake-ticket DMs in one move. Afterward the artifacts — sets, photos, the moment everyone talks about for a year — seal into memory, and the kitchen alliance doesn’t dissolve; it’s the seed crew for the next one.

Why these matter strategically: festivals are the fastest path to members who never think of any of this as software. A hundred people leave having voted a lineup, carried a code, worked a crew, and read their since-you-were-gone. The Dunathon opening August 10 is this pattern pointed at ourselves.

## Part VII — What this means for the build

The spec gets inverted, not amended. v4 restructures as: the two worlds → the eight member moments (Part II here, normative) → the mechanics → the worker roster as the spine of the build. The five verbs stop being sections. The v3 appendices survive nearly intact (graph, HEARTS, Codes were always agent-first).

Cut three prototypes the primitives, concretely. The since-you-were-gone rendering inside the Thread — real BiHome and Kinship Duna content from this document, not placeholders — with the Docket deck, a presence report (“held one at the gate; enrolled two”), the Contract quoted back, and a Seal. No masthead, no morning paper. Cuts one and two remain beside it for comparison; v1 and v1.1 are archived.

Build order falls out of the roster. Presence spine first (Switchboard, Gatekeeper, adapters, Moderator) because relationship needs reach and growth needs the Enroller; memory loop second (Archivist, Embedder, Distiller) because everything feeds on it; Account/Docket third (Ledgerkeeper, Renderer, Corrector, Clerk, Sealer) because that’s the covenant; governance and Sentinel in parallel; the Launcher’s crew last before August 10, proven by spinning out the first real duna on stage in Charleston.

The standing test grows one clause. For every future feature argument: which agent does the work; how does the member learn it happened; what, if anything, must only a human sign — and which world does it live in? If a proposal can’t answer all four, it’s the old paradigm knocking.

Kinship Duna · Kiduna · kiduna.team — pairs with the Launch Spec and the Interface Paradigms overview. Questions and challenges to Moto, or to any ally once we have them.