Working specification · Product-owner handoff · 11 July 2026

# Kiduna: A New Architecture for the Agentic Internet

A coherent first specification for creating the network’s first Ecosystem, growing organizations and Projects from within it, and rendering the whole system through one Field in Kiduna Studio and Kiduna Live.

Version 0.1 Engineering-ready proposal Canon v5.3 / Design R7 reviewed 12 product-owner calls remain
How to read this. Statements labeled Ship are recommended defaults that engineering can implement. Statements labeled Decide are product-owner calls that change contracts or ontology. Canon is cited, but this document deliberately challenges canon where coherence, safety, accessibility, or federated operation requires it.
01

## Executive decisions

The shortest useful statement of the product: Kiduna is a protocol-governed network of member-owned agents and organization-owned work, made visible as one addressable Field.

North star

A member enters one Field, speaks with one Ally, can see the people, agents, objects, work, provenance, and consequences relevant to the current context, and can create the next legitimate thing without leaving the system.

01
Four layers, two primary apps Protocol, Network, and Server are infrastructure; Live and Studio are the primary products; Express and Account/Registry are supporting surfaces.
02
The Field is a model, not mandatory scenery Every object has a Field address and spatial projection. The contextual HUD may become an opaque linear, document, chat, table, or diff view without leaving the Field.
03
Mage is a root service principal The Genesis Account cannot log in as a person, read personal data, or impersonate members. Human operators act through separately named, threshold-controlled steward roles.
04
Ki proposes; deterministic services authorize The Genesis Ally configures conversationally but holds no root power. Every state change passes the graph/command boundary.
05
Network account is not automatic duna membership Create an account and network identity first; joining Kinship Duna is a separate, explicit agreement. This removes a legal and decentralization contradiction.
06
Portable identity, explicit home Ecosystem Identity is network-portable; encrypted data and active command authority have one declared home Ecosystem at a time, with migration and recovery.
07
Every Project has a Scene identity The Scene may render collapsed as an object until entered or expanded. This preserves “a Scene per Project” without thirty tiny rooms cluttering an Organization.
08
Commands have three authority classes Personal commands, container-admin commands, and Forum-governed duna commands share one envelope but not one approval path.
09
Append-only Records, not full event sourcing Each command atomically updates current graph state, appends an immutable Record, and publishes an outbox event. Rebuildable projections, simpler operations.
10
Graph-service contract before graph-engine choice Start with PostgreSQL, pgvector, typed nodes/edges, and a graph-service API. Benchmark Apache AGE; keep engine choice behind the boundary.
11
Visible Actors are not implementation workers Only functional, explainable Actors appear in the Field. Queues, embedders, and outbox consumers remain system workers.
12
First proof is recursive real work Moto creates the Ecosystem, creates his Ally, invites one person, forms one Project, passes one package to a coding agent, accepts one authoritative Record, and that person can invite the next.

### The complete first slice

01 Install Signed Genesis Profile starts the first Ecosystem.
02 Seal Mage, Ki, policy bundle, command catalog, and Genesis Record.
03 Steward Moto claims a human account, passkey, wallet, and Ally.
04 Organize Kinship Duna validates; first Organization Field opens.
05 Create A Project and Scene appear with members, grants, and provenance.
06 Work A package leaves Studio, returns, and becomes a Record.
07 Propagate The invited member can invite another person or seed a peer Ecosystem.
Figure 1The minimum is not a feature checklist. It is a sealed creation loop that produces another legitimate participant and another legitimate unit of work.
02

## Products and user surfaces

The canon mixes infrastructure, a network instantiation, apps, modes, and websites in one “product” list. Engineering and go-to-market need a taxonomy where each name has one job.

#### Open infrastructure

Kiduna Protocol · KAP Identity, request, command, receipt, registry, and federation contracts; Solana adapters where accountability requires chain trace.
The Network The live federation of Ecosystems, registry entries, routes, and shared protocol state. An instantiation, not an app.
Kiduna Server Installable Agency Server. One installation is an Ecosystem with a home authority, data plane, orchestration, and protocol edge.

#### Primary member products

Kiduna Live The mobile-first member app. The Field for participating, understanding, conversing, acting, and receiving the pulse of Projects. Later: CTV and spatial devices.
Kiduna Studio The desktop workshop. The same Field grammar with local files, creation, inspection, Project work, integrations, packages, grants, and authoritative acceptance.
Shared Field runtime Object identity, Scene renderer, contextual HUD, ACTIONS, ally band, accessibility projection, and deep links reused by Live and Studio.

#### Supporting surfaces

Kiduna Express Browser extension: provenance, registration trace, member-authorized web action, and handoff into the current Field.
Kidunaverse Account & Registry Passkeys, recovery, wallets, payment authorization, public registry, handles, protocol browser, exports, and ecosystem controls.
API + MCP Third-party Agency Clients use the same command and policy boundary as first-party products. No privileged path.
Figure 2Recommended product architecture. “Kiduna One” and the old mode-specific websites become deep-link entry states of Live/Account, not separately maintained products.

Surface | Primary person | Core job | May authorize | Must not become | First release
--- | --- | --- | --- | --- | ---
Kiduna Live | Member or guest on phone | See and participate in the current Field; converse; take ordinary and sovereign actions that can be inspected honestly. | Non-financial commands; signatures only where the full consequence is inspectable. | A dashboard, game lobby, wallet, mobile Studio, or notification feed. | iOS/Android; responsive web later.
Kiduna Studio | Creator, Builder, Organizer, Project lead | Create and maintain Allies, relationships, Organizations, Projects, Scenes, tools, Actor definitions, and packages. | Desktop signatures, grants, package dispatch, draft-to-record acceptance; money still hands off to web. | An IDE, file browser into collaborators’ machines, or “vibe coding” shell. | macOS first; Windows/Linux after the real-work proof.
Account & Registry | Any account holder; public verifier | Identity, passkeys, recovery, wallet/payment, permissions, data export, registry and receipt browsing. | Money and custody actions; account recovery; ecosystem migration. | A social feed or second home experience. | Responsive web, required before Live onboarding.
Express | Member browsing the web | Explain what an artifact is registered to and let the Ally act under explicit grants. | Web tool calls; domain binding through Account confirmation. | A universal safety score, warning shield, or autonomous browser with ambient authority. | After core identity and command loop.
Server | Ecosystem operator | Host resources, enforce commands, serve KAP, run orchestration, and participate in federation. | Ecosystem operations only; never member sovereignty. | A super-admin console over member content. | Headless install + operator status page.
Protocol/Network | Implementer, operator, verifier | Make identities, commands, receipts, registrations, and ecosystem relationships interoperable. | No member action; only verifies signed authority and protocol state. | A centrally owned platform or a blockchain mirror of all data. | Versioned KAP v0 + registry adapter.

Product rule

Live and Studio share semantics, not identical pixels. A member should recognize the same container, object, ACTION, Ally, provenance, and consequence on both. Studio adds desktop instruments—drop, multi-select, diff, wire, inspect—while Live stays touch-first and participation-first.

Canon basis: skill-updates/cofounder-canon-2026-07-11.md §§ Products, Evening additions; surfaces.md §§1–5; integrations.md §§1–3. Proposed change: collapse Kiduna One and mode-only packaging into entry states.

03

## The domain model

The hierarchy is useful for containment, but the member—not the hierarchy—is the center of authority. Objects can belong to containers while members participate across them.

Network federation
Ecosystem server + Mage + Ki
Organization registered DUNA
Project / Alliance work and money scopes
Guild / Scene sharing and place
Ally member representation
Member Source and sovereign actor
Containment is not ownership One member may cross all containers One Ally per member identity Institutions sit beside the DUNA hierarchy
Figure 3The Field should never imply that a member is “under” an organization. The chain describes where policies and resources live; authority still resolves from the Source, grants, roles, and exact command.

### Canonical objects, sharpened for implementation

Root

#### Network

Federated namespace and protocol state. Contains no private member content.

- protocol version + registry
- ecosystem routes + trust relations
- public receipts/anchors

Root

#### Ecosystem

One server installation and administrative boundary, created from a signed Genesis Profile.

- home authority + endpoints
- Mage + steward group
- policy bundle + capabilities

Identity

#### Account / Member

Account is authentication and custody; Member is a human identity and Source. Organization membership is a separate edge.

- passkeys + recovery
- portable DID / wallet refs
- status and legal agreements

Agent

#### Ally

The member-representing persona, instruction-bound to its Source and portable across containers.

- handle + Contract
- voice + grounding
- authority always re-resolved

Agent

#### Actor

A named functional agent with a declared purpose, owner container, closed command set, budget, and lifecycle.

- no member representation
- no sovereignty
- explainable in the Field

Social

#### Relationship

The first-class bond between two members. Each side controls its own grants; trust/standing is explicit and contextual.

- directional grants
- history + provenance
- no shared secret by default

Container

#### Guild

Named sharing scope with no wallet. If money-shaped activity appears, create or promote to an Alliance.

- members + purpose
- access level
- no treasury commands

Container

#### Alliance

Working group with a wallet and charter inside an Organization; may exist while a new DUNA is forming.

- Squads wallet reference
- membership + agreements
- limited vote types

Legal container

#### Organization / DUNA

A registered DUNA with validated jurisdictional identity, Forum, policies, treasury, Compute configuration, and Projects.

- WV Org ID at launch
- registration status monitored
- no “draft Organization” object

Work

#### Project

The Studio organizing primitive inside an Organization: purpose, members, grants, systems, Records, derived state, and a Scene identity.

- one parent Organization
- zero or more workspaces
- archive, never erase provenance

Place

#### Scene

A bounded Field projection. It can be on-the-fly, generated, or crafted; fidelity never changes capability.

- stable object addresses
- layout versions + source sentence
- sim flag orthogonal

Work unit

#### ACTION

A consequence-bearing request addressed to a member or Actor, resolved through a named command and attached to its object.

- what + why + consequence
- authority class + deadline
- act + “not now”

Evidence

#### Item / Record

Item is a shareable resource. Record is the immutable, provenance-carrying account of a read, act, signature, result, or settlement.

- access + owner + hash
- source and derivative edges
- retention / legal hold

Capability

#### Tool / Package

A Tool is an operable external capability under grants. A Package is a bounded, self-describing handoff to a local or remote agent.

- scope + credentials ref
- ask + constraints + return
- terminal outcome + Record

Governance

#### Forum / Proposal / Policy

A Forum decides Organization-level commands. A passed proposal executes its exact command set and yields queryable Policy.

- equal, free pass/fail vote
- conflict recusal
- machine-derived receipts

### Four distinctions the schema must preserve

Identity

#### Account ≠ Member ≠ Organization membership

An Account authenticates; a Member is a person; a membership edge binds that person to a specific Organization and its agreements. Conflating them makes federation, withdrawal, and legal consent impossible to model cleanly.

Agents

#### Ally ≠ Actor ≠ worker

An Ally represents a member. An Actor is a product-visible functional agent. A worker is an implementation process. “Embedder” can be a queue consumer without becoming a character in the Field.

Action

#### Intent ≠ command ≠ settlement

Language captures intent. A deterministic command changes Kiduna state. A payment, chain, or external tool may settle later. Each layer has its own status, error, and idempotency.

Space

#### Object ≠ Field address ≠ Scene rendering

Every object can be addressed in the Field. Not every object needs a room. A Scene is a projection of a bounded subgraph; an opaque HUD is another projection of that same state.

Canon basis: foundation.md §§1–7; protocol.md §§1–4; design-r7/UX-SPEC-R7.md §§2–6. Proposed additions: Account object, worker distinction, command authority classes, stable Field address.

04

## Creating the first Ecosystem

The Genesis operation is an auditable ceremony with deterministic steps. It is not a wizard that silently creates a super-admin and a collection of mutable defaults.

Required canon correction

“Mage admins all accounts below it” must not mean “Mage can become or read any member.” Mage administers ecosystem services, schemas, routing, quotas, upgrades, and recovery policy. Personal content and member authority remain cryptographically and structurally outside its ordinary reach.

### Genesis Profile v0

The Genesis Profile is the signed declaration from which an Ecosystem can be reproduced and verified. It contains configuration, public bindings, policy digests, and key references—never raw secrets.

- Identity: network ID, Ecosystem ID, canonical name, root DID, software version, creation time.
- Endpoints: KAP, client API, federation, registry proof, status, and key-discovery URLs.
- Custody: Mage public key, threshold steward set, recovery quorum, hardware-key policy.
- Policy: access enum, command catalog digest, receipt renderer bundle, role bundle, retention defaults.
- Placement: home region, data residency, artifact storage, backup policy, model-provider policy.
- Legal binding: operator entity, jurisdiction, terms version, registry anchor, initial DUNA reference if any.
- Genesis Ally: Ki template/version, guest budget, allowed onboarding commands, public grounding digest.
- Parent proof: spawning Ecosystem Code and issuer, except for the single network-genesis exception.

    {
      "profile_version": "kiduna.genesis/0",
      "network_id": "kiduna-main",
      "ecosystem_id": "kiduna:ecosystem:01J...",
      "name": "Kiduna",
      "root_did": "did:key:z6Mk...",
      "mage_key_ref": "hsm://kiduna/mage/1",
      "steward_policy": { "threshold": 2, "members": 3 },
      "endpoints": {
        "kap": "https://kap.kiduna.example/v0",
        "keys": "https://kap.kiduna.example/.well-known/jwks.json"
      },
      "policy_bundle_sha256": "…",
      "command_catalog_sha256": "…",
      "ki_template": "kiduna:ally-template:ki@0.1",
      "parent_code": null,
      "genesis_exception": "network-genesis",
      "signed_at": "2026-07-11T…Z",
      "signatures": ["mage", "steward-1", "steward-2"]
    }

### The first boot, step by step

# | Operation | Authority | Writes | Failure behavior | Acceptance evidence
--- | --- | --- | --- | --- | ---
0 | Preflight: verify binaries, clock, DNS, database, object store, chain endpoint, email/SMS, model provider, and legal configuration. | Local installer | None | Fail closed; no network identity exists yet. | Signed preflight report.
1 | Generate custody: Mage key in HSM/secure enclave; steward and recovery shares offline. | Installer + human ceremony | Public key refs only | Destroy partial keys and restart before any public anchor. | Key ceremony Record; recovery drill.
2 | Sign Genesis Profile and calculate immutable profile digest. | Mage + steward threshold | Profile draft | Any change creates a new digest; no in-place mutation. | Signatures verify independently.
3 | Migrate stores: create schemas, access enum including `secret`, typed node/edge catalogs, Records, outbox, embeddings, and artifact buckets. | Deployment principal | Infrastructure state | Transactional and resumable; migration ledger prevents skips. | Schema manifest equals profile bundle.
4 | Seed system contracts: identity types, role templates, baseline Actions, command schemas, error taxonomy, receipt renderers, and policy tests. | Bootstrap command service | Versioned system nodes | Idempotent by bundle digest; mismatch halts. | Catalog round-trip test passes.
5 | Create Ecosystem + Mage: Mage is non-interactive; attach capabilities only for ecosystem operations. | Bootstrap command | Ecosystem, service principal, steward group | No rollback after sealing; before sealing, delete draft namespace. | Negative tests prove Mage cannot read personal data or impersonate.
6 | Instantiate Ki: public onboarding persona/template, guest Contract, budget, and allowed commands. | `genesis_ally.instantiate` | Ki template + host instance | Can be disabled without disabling the Ecosystem. | Ki cannot execute root/admin commands; all claims cite profile sources.
7 | Create initial Actors and deterministic workers; start only minimum scopes. | Steward-approved bundle | Actor definitions + worker leases | Actors default paused until capability tests pass. | Closed command set and budget per Actor.
8 | Bind the network: publish DID document, KAP endpoints, registry entry, and network-genesis proof. | Mage + steward threshold | Public registry / chain anchor | Retry idempotently by profile digest; never create a second identity. | External verifier resolves keys and endpoints.
9 | Import/validate Kinship Duna: check WV Org ID 628407, legal identity, registered agent, and on-chain organization binding. | Registrar + deterministic validator | Organization + validation Record | If validation fails, Ecosystem remains active but Organization stays unavailable. | Proof includes registry source and timestamp.
10 | Issue steward claim: one-time, short-lived code creates Moto’s Account, Member identity, passkey, and steward-role edge. | Mage issues; human accepts | Account, Member, credentials, role | Code bound to device/person proof; single use; revocable. | Moto can operate the Ecosystem but cannot act as Mage.
11 | Create Moto’s Ally from Ki through conversation: handle, Contract, grounding, disclosure, and recovery binding. | Moto as Source | Ally + Contract Records | Resume from last confirmed sentence; no duplicate Ally. | Non-Source instruction tests fail.
12 | Seal Genesis: append Genesis Record, public digest, health snapshot, and peer-spawn capability. | Steward threshold | Immutable Genesis Record | After seal, changes are migrations/proposals, never Genesis edits. | A clean install reproduces the same public state from the profile.

Moment
Installer
Mage / stewards
Graph service
Registry / KAP
Ki / Moto
Prepare
preflight + keys
threshold ceremony
Declare
profile digest
sign profile
Create
migrations
seed contracts + root nodes
Connect
authorize publish
append bootstrap Records
publish DID + endpoints
Humanize
issue bound claim
Account + Member + role
Ki meets Moto; Ally created
Seal
reproducibility check
threshold seal
Genesis Record
network-genesis anchor
first Field opens
Figure 4No model participates in key generation, root authorization, schema migration, registry anchoring, or sealing. Ki translates and explains; deterministic code performs the ceremony.

### How later Ecosystems spawn

Parent Ecosystem

#### Issue an Ecosystem Code

A Mage may issue a time-limited, single-use spawn code only after steward approval. Claims include the intended operator DID, protocol range, network, allowed registry namespace, expiry, and the parent Genesis Record. The code grants network entry—not administrative rights over the child.

Child Ecosystem

#### Prove independent custody

The child generates its own keys, profile, policies, and stewards; consumes the code during public registration; and establishes an explicit ecosystem relationship. Parent and child become peers. Revoking the relationship cannot erase the child’s identity or member data.

Federation invariant

A spawning code establishes provenance and compatibility. It must never create a transitive chain of control. The Network is coherent because proofs and contracts compose—not because the Genesis Ecosystem can administer every descendant.

Canon basis: skill-updates/cofounder-canon-2026-07-11.md §§ Mage, Ecosystems spawn ecosystems; architecture.md §§1–7; Protocol + Stack Architecture PDF §§11–13. Most Genesis mechanics are necessarily proposed because the Kit explicitly leaves them open.

05

## Allies, Actors, and the first cast

The model should stay human-legible: one agent represents a member; functional agents do bounded work; invisible system processes remain invisible.

### Resolve Ki without weakening the Ally invariant

Product language

#### Ki is the Genesis Ally

Ki is who a person meets before they have an Ally. Ki explains the Ecosystem, drafts configuration, creates the continuity of the first conversation, and helps a member personalize their own Ally.

Runtime truth

#### Ki is a Genesis Host Actor + Ally template

In the schema, Ki does not pretend to represent a human. `Actor(kind=genesis_host)` serves guests; `AllyTemplate(ki)` supplies the shared capabilities from which member Allies are created.

Authority

#### Mage is not Ki’s conversational boss

Mage authorizes Ki’s fixed configuration capabilities, but Ki never relays free-form Mage language as member authority. Typed ecosystem commands still require policy and steward approval.

Proposed canon wording

“Ki is the Genesis Ally in the experience: the public face and template from which personal Allies begin. In the authorization model, Ki is a non-sovereign Genesis Actor until a Member becomes the Source of a personal Ally.”

### Agent contracts

Family | Represents | Instruction | Standing | May hold | May never
--- | --- | --- | --- | --- | ---
Personal Ally | Exactly one Member/Source | Binding only from authenticated Source; anyone else is context or a grant-bounded request. | Acts through the Source’s grants and roles in the current context. | Contract, handle, voice, grounding, context pointers, proposed ACTIONS. | Self-authorize, vote, sign, widen a grant, or merge organization secrets into another context.
Genesis Host (Ki) | No member; represents the declared Ecosystem experience only | Guest conversation; typed configuration requests authorized by Mage/stewards. | Public/guest onboarding scope and a fixed operational budget. | Public Genesis Profile, help content, provisional onboarding state. | Read personal data, become a member, create legal authority, or instruct a personal Ally.
Actor | A function, never a member | Triggers and typed work requests within its manifest. | Only explicit reads, tools, commands, budget, and time window. | Versioned package, model policy, owner container, stop condition, traces. | Acquire a member role, vote, sign, own a personal wallet, or change its own allowlist.
System worker | Nothing; implementation process | Queue/event trigger | Least-privilege service identity. | Lease, retry state, deterministic code. | Appear as a social participant or use natural language as authority.

### The first visible Actors

Profiler

Builds an invitation-bound briefing from inviter-provided sources, then—only after disclosure and consent—may enrich from public sources. It cannot send the invitation or widen access.

GENESIS LOOP
Configuration Drafter

Turns “create this Project / Alliance / policy” into a typed command preview, flags missing authority, and reads the consequences back. It cannot commit.

GENESIS LOOP
Registrar

Collects official legal-registry evidence and monitors status. A deterministic verifier, not the model, decides whether evidence satisfies the adapter.

ORGANIZATION
Project Steward

Narrates Project state, derives what is waiting, explains grants, and keeps packages and Records legible. State always comes from the graph.

STUDIO V0
Field Composer

Projects objects and relationships into a Scene and raises fidelity from words/pixels to generated or crafted dressing. It cannot change the objects or grants it renders.

FIELD V0
Package Courier

Composes, dispatches, scopes, relays, recalls, quarantines, and returns packages. No arbitrary filesystem reach and no credentials inside the package.

STUDIO V0
Forum Facilitator

Explains proposals, conflicts, and machine-generated command receipts; records discussion. It cannot vote, tally outside deterministic rules, or settle.

ORGANIZATION V1
Ingestion Actor

Extracts metadata, entities, chunks, and provenance from a member-authorized Item. Its semantic findings are candidates, never authority.

STUDIO V0
Sentinel

Reads context fields for interaction-health signals. Launches observe-only, with hard human escalation and explicit constitutional limits before any intervention.

OBSERVE LATER

### Deterministic services that must not become Actors

#### Identity & sessions

Passkeys, proof-bound tokens, DIDs, Code verification, rate limits, recovery ceremonies.

#### Graph command service

Resolve, authorize, validate, execute, version-check, append Record, generate receipt.

#### Registry verifier

WV evidence adapter, DID/key discovery, chain confirmation, registration freshness.

#### Event & outbox

Transactional publication, ordering, retries, dead-letter review, projection rebuild.

#### Artifact security

Object storage, envelope encryption, malware scan, content hash, retention and legal hold.

#### Embedding worker

Permission-scoped chunking and vectors; never changes access or authorship.

#### Settlement reconciler

External-operation state, idempotent submit, confirmation, retry, manual exception.

#### Federation relay

KAP signatures, routing, replay protection, capability narrowing, receipt resolution.

### How Builders and Creators create an Actor type

draft→manifest complete→simulated→evaluated→approved→registered→instantiated→paused / retired

    actor_type:
      name: "Project Steward"
      purpose: "Explain one Project's state and next actions"
      version: "1.0.0"
      owner: organization_id
      reads: [project_graph, permitted_records]
      tools: []
      commands: [action.propose, summary.create]
      model_policy: project-steward-v1
      budget: { daily_compute: 500 }
      escalation: "project-lead"
      stop_conditions: [project_closed, budget_exhausted]
      package_hash: "sha256:…"

Naming and describing an Actor can be conversational. Giving it executable authority cannot be. Studio should turn the conversation into a signed, inspectable manifest; run policy, safety, cost, and example tests; then ask an authorized Builder to register that immutable version.

Updating an Actor always creates a new version. Existing instances stay pinned until migrated. Retirement revokes capability and leaves every prior Record verifiable.

Canon basis: orchestration.md §§1–8; the-working-organization.md Part IV; skill-updates/cofounder-canon-2026-07-11.md Evening additions. Proposed change: product-visible Actor vs invisible worker distinction; Ki schema correction.

06

## The creation system

“Create from within” needs one uniform command grammar, clear authority classes, and lifecycle rules for every object the member can make.

### One command envelope; three authority classes

A · Source

#### Personal command

The Source can change their Ally Contract, add an Item, set their side of a Relationship grant, defer an ACTION, or issue a personal Code within hard invariants.

B · Role / grant

#### Container command

A Builder or Project lead may create a Project, connect a Tool, add a member within policy, or dispatch a Package. Authorization comes from role + policy + current grant.

C · Forum

#### Governed duna command

Changing constitutional policy, issuing Compute, spending treasury funds, changing Forum rules, or dissolving an Organization requires the exact commands in a passed proposal.

Critical clarification

`project.create` is a duna-domain command, but it does not automatically require a Forum. The command schema declares its authority class. An Organization policy can narrow it to Forum approval; the UI never guesses.

### Minimum command catalog

Domain | Required commands for first release | Later commands
--- | --- | ---
Network / Ecosystem | `network.genesis_declare` · `ecosystem.create` · `ecosystem.publish_attestation` · `ecosystem.spawn_code_issue/reserve/consume` · `ecosystem.set_peer_relationship` · `ecosystem.rotate_keys` | `ecosystem.migrate_host` · hosting agreements · decommission
Account / identity | `account.create` · `account.bind_passkey` · `account.recover` · `member.create` · `handle.reserve` · `ally.create` · `ally.contract_amend` | guardian recovery · cross-ecosystem home migration
Access / relationship | `relationship.create` · `relationship.statement_set` · `grant.set/revoke` · `code.issue/reserve/redeem/revoke` · `item.access_set` | paid private access · federated capability exchange
Social containers | `guild.create/rename/dissolve` · `alliance.create/add_member/dissolve` · `institution.register/enroll` | alliance merge · multi-organization sponsorship
Organization / DUNA | `duna_plan.create` · `organization.verify_registration` · `organization.register` · `organization.configure` · `role.appoint/revoke` | other legal-form adapters · subsidiaries · dissolution saga
Project / Scene | `project.create/add_member/set_grant/close/archive` · `scene.anchor/materialize/raise_grade/archive` · `field.place/link` | cross-organization Project · spatial-device placement
Items / tools | `item.add/correct/forget` · `tool.connect/grant/disconnect` · `skill.register/version/release` | paid Tool marketplace · automatic skill propagation
Actors | `actor_type.draft/register` · `actor.instantiate/pause/retire` · `actor.capability_grant/revoke` | cross-ecosystem Actor hosting
Packages / Records | `package.compose/dispatch/return/refuse/recall/retry` · `record.accept/reject` · `record.correct` | remote execution only after a separate sandbox review
ACTIONS | `action.request/defer/perform/withdraw/expire` · `action_ledger.query` | multi-party orchestration and delegated non-sovereign actions
Forum / policy | `proposal.create` · `vote.cast` · `proposal.finalize/execute` · `policy.enact` | additional voting methods; prediction mechanics only after semantics are explicit
Money / Compute | Read-only ledger and web handoff; fixed, nontransferable usage credits recommended for v0. | Any token, transfer, liquidity, lineage, or chain settlement after counsel/security approval.

### Creation lifecycles

Account and Ally

#### Invited → active

code offered→guest reserved→passkey bound→member created→Ally named→active

Network standing and Organization membership are separate edges. A member can be active, suspended, withdrawn, or expelled; history remains.

Relationship

#### Two authored sides

proposed→accepted→grants stated→collaboration enabled→narrowed / ended

Trust is a human-facing summary. Actual authorization is directional grants plus policy; neither side can edit the other’s statement.

Guild → Alliance

#### Social scope to working group

guild active→money-shaped need→promotion proposed→new Alliance created

The Guild is not mutated into a wallet object. The Alliance cites the Guild as origin; the Guild may remain or close.

Alliance → DUNA

#### Forming to legally verified

DunaPlan→governing principles→100+ consenting members→filing→verified→Organization registered

A new Organization node is linked `EVOLVED_FROM` the Alliance/DunaPlan. It is never called a registered DUNA before verification.

Project

#### Work container

proposed→created→active→blocked / waiting→complete→archived

State is derived from open work, active packages, ACTIONS, and closure Records. A member never types “active” into a status field.

Scene

#### Address to place

anchor→on-the-fly→generated→crafted→archived

Capability does not change with grade. A Project may stay collapsed at its anchor until entered, explicitly expanded, or collaboration needs a room.

Package

#### Bounded correspondence

draft→dispatched→working / quiet→returned / refused→accepted / rejected

Retry creates a new Package citing the old. Returned output is draft until inspected. Gold is reserved for promotion into an authoritative Organization Record.

External operation

#### Saga, not pretend atomicity

authorized→submitted→awaiting external→settled or failed / compensating

Property, payments, legal filings, and chain transactions cannot be one local atomic transaction. The receipt distinguishes authorization from final settlement.

### ACTION is a first-class request, not a visual chip

Every ACTION attaches to the object whose state requires a person. It must remain queryable when the Scene is not visible, and it must expire or withdraw when the underlying need disappears.

- Stable ID and target object
- Addressed member or Actor
- Issuer and authority basis
- What is needed, why now, and exact consequence
- Access consequence in the action label
- Available acts, “not now,” and optionally “at my desk later”
- Object/version precondition and stale-state behavior
- Deadline, withdrawal, or expiration condition
- Resulting command and receipt renderer

    {
      "id": "act_01J…",
      "target": "pkg_01J…",
      "addressed_to": "mem_moto",
      "issued_by": "actor_project_steward",
      "what": "Review returned adapter Records",
      "why": "Package #7 returned within scope",
      "consequence": "Accepting promotes 3 drafts into the
                       Organization's official Record",
      "authority_class": "source_signature",
      "acts": ["inspect", "accept", "reject", "not_now"],
      "expected_version": 12,
      "expires_when": "package_state_changes",
      "command": "record.accept"
    }

Action Ledger

Ship one canonical, queryable Action Ledger. Render it at objects, through the Ally’s answer to “what needs me?”, and as a temporary opaque HUD card grouped by consequence. Do not add badge counts, streaks, or a permanent inbox—but do not make important work depend on remembering where an object was.

Canon basis: actions.md §§1–4; protocol.md §3; design-r7/UX-SPEC-R7.md §§2, 4; design-r7/OPEN-QUESTIONS-R7.md OQ-6. Proposed additions: authority class, ActionRequest contract, state machines, saga model.

07

## The Field and contextual HUD

The Field is the only interaction shell. It is the current, permission-filtered subgraph made perceptible—and it remains intact while the HUD becomes conversational, documentary, tabular, or opaque.

Field definition

The Field is an addressable semantic projection, not a game map. It provides place, relationship, presence, action, and continuity. The graph remains authoritative; the Scene is one view; the HUD is how a member focuses without leaving.

### Four HUD states over one persistent Field

01 · Ambient

#### Perceive

Container chip, up to three contextual ACTIONS, ally band, and sky rims. No panels, minimap, inbox, or permanent navigation.

02 · Conversational

#### Speak while moving

A translucent thread grows from the ally band. The current object remains visible and cited; voice and text share one conversation.

03 · Opaque focus

#### Read or decide

Chat, document, receipt, grant, ACTION, table, or diff occupies most of the viewport. “Back to [object]” preserves exact position.

04 · Wide focus

#### Work at a desk

Studio-only dense projection for comparison, multi-select, package composition, or inspection. It is still the focused state of Field objects, not another app mode.

### The HUD grammar

Element | Meaning | Rules | Accessibility equivalent
--- | --- | --- | ---
Container chip | Where the member is acting and whose policies bind. | Always visible; shows breadcrumb on focus; never silently changes. | Heading + breadcrumb + current authority summary.
Contextual ACTIONS | What the current object or moment needs. | Maximum three, ranked by consequence then relevance; one primary. Labels state access consequence. | Ordered list with what/why/consequence and keyboard shortcuts.
Ally band | Continuity of the member–Ally relationship. | Persistent, citation-aware, voice/text, never used as a notification ticker. | Live region only for requested/essential state; transcript available.
Sky rim | An object responds to touch or focus. | Thin edge, never sky paint; color never acts alone. | Focusable semantic object with action label and role.
Gold ceremony | Human signature crossing an authoritative boundary. | Press-and-hold only after exact consequence and parameters are inspectable; never package status or promotion. | Explicit confirmation with fresh authentication and textual signed-state announcement.
Light / mint | Something happened to or around the member. | One state change, then quiet; no pulse for attention. | Concise status sentence in the Ally transcript.

### Field object grammar

Object | Spatial grammar | Focus must state | Relationships shown
--- | --- | --- | ---
Member | Warm circle; sky rim when interactable. Position reflects disclosed context, not online surveillance. | Handle, current-container role, Ally, disclosed Institution relationship. | Relationship paths appear on focus; grants are directional.
Ally | Companion light/orb associated with its Source. | Source, public Contract clauses, current container grounding, reachability. | Ally↔Ally exchanges are shown as routed work, never independent sovereignty.
Actor | Distinct square/diamond at its function, not a human avatar. | Function, owner, version, scopes, tools, budget, stop condition, last meaningful Record. | Capability links to Project, tools, and command allowlist.
Organization | Ground or compound; its register changes atmosphere, not core UI. | Verified legal identity, purpose, Forum, policies, current registration evidence. | Projects, Alliances, Institutions, and member roles.
Project | Anchor/workbench in parent Scene; bounded room when materialized. | Purpose verbatim, members/grants, systems, Records, derived state. | Parent Organization; linked Engagements; Scene; active Packages/ACTIONS.
Tool / resource | Instrument or container; provenance chip remains legible at every Scene grade. | Provider, host, scopes, registered/unregistered, owner, data destination. | Grant path and output Records.
Record | Paper/slab/light trail; grouped without hiding provenance. | Actor, authority basis, source, access level, command/outcome, corrections. | Derived-from and supersedes edges.
Package | Parcel at Scene edge facing its destination. Use sky/mint for transit—not gold. | Context, ask, constraints, return address, agent, elapsed facts, terminal outcome. | Dispatch/return thread and produced draft Records.
ACTION | Sky rim and local chip at the object that needs a person. | Addressee, what, why, consequence, authority, act/not now/at desk later. | Target object, issuing Actor/Ally, resulting command.

### How the Field expands

A Anchor Every Project receives an address and object in its Organization.
B Workbench Artifacts, people, and ACTIONS cluster at the anchor.
C Scene Materializes when entered, explicitly expanded, or collaboration needs bounded grants.
D Dressing On-the-fly → generated → crafted. Same objects and capabilities.
E Grounds Organization arranges active Scenes by relationship and current work—not a manual folder tree.
F Archive Active ground clears; address, Records, and scene transcript remain.
Figure 5This reconciles R7’s “Scene per Project” with its own proliferation objection: every Project has a Scene identity, but the visual room is lazy and collapsible.

### Representing relationships and “who is doing what”

Relationship

#### Paths, not halos

Trust/standing belongs on the relationship path; registration belongs on the resource label. Never put a “trusted” badge on a registered object. Selecting a member reveals only the relationship and grants the viewer may know.

Presence

#### Position plus declared activity

Show facts such as “Elias · at the adapter Records,” “Moe · working on his machine,” or “Package #7 · with Codex · quiet 10 min.” Do not infer productivity, online duration, typing, or exact presence beyond a grant.

Work

#### State is derived

A Project reads “work out” because a Package is dispatched; “waiting on Moto” because an ACTION is current; “quiet” because there are no active work objects. The label changes when the graph changes.

Provenance

#### Never falls off

Machine output is always “via [agent] · package #N.” Generated scenery cites its source sentence and model. Corrections supersede Records; they do not rewrite history.

### Accessibility is a projection of the Field

#### Scene transcript

Every Scene exposes a semantic reading order: current container, nearby meaningful objects, people, activity, relationships, and available ACTIONS. This is the same Field, not a fallback product.

#### Keyboard & switch

Tab moves by consequence/relevance, arrows or WASD move spatially, Enter focuses, Escape collapses HUD. Do not ship the proposed spacebar-hold peek.

#### Motion & sensory parity

WCAG 2.2 AA; 44×44px targets; 4.5:1 text contrast; captions/transcripts; 200% zoom; reduced motion removes crossings, breathing, parallax, embers while state text remains.

Canon basis: July 11 evening additions; design-r7/R7-PROMPT.md; R6/R7 HUD and Scene designs. Proposed interpretation: Field as semantic shell with opaque linear projections; anchor-first/lazy Scene materialization.

08

## Kiduna Studio

The desktop workshop for creating and operating the system from within: one Field, local access, deep inspection, and Projects as the spine.

### Complete Studio path

ST-00 Bootstrap Install, join, or restore Server.
ST-01 Genesis Keys, Mage, profile, network proof.
ST-02 First person Passkey, Member, personal Ally.
ST-03 Organization Claim/verify Kinship Duna.
ST-04 Project Purpose, members, grants, Scene.
ST-05 Connect Files, tools, systems, collaborators.
ST-06 Dispatch Bounded package to coding agent.
ST-07 Accept Inspect, promote to Record, cite.

### High-fidelity desktop screen specification

KIDUNA STUDIO · GENESIS ecosystem · Kiduna · local
Kiduna · first Ecosystem · not sealed
inspect profile seal the Ecosystem
Kiduna Server · healthy
Mage · threshold ready
Ki · Genesis host
Kinship Duna · verification pending
Ki · The server is ready. Before I seal it, review the Profile and the two-of-three steward rule. Nothing public has been published yet.voice

ST-05 · Empty/Genesis Ecosystem. The first Field contains only verifiable roots: server, Mage, Ki, network edge, and the Organization claim. Primary action is singular and consequence-stated.

KIDUNA STUDIO The Ceremony Machine → Lightbrush integration
The Ceremony Machine · Lightbrush integration · private
inspect what returned ask what needs me add to Project
Dowbot · registered
Digital Dolly · registered
adapter Records · 23
package #7 · returned
Elias · at the adapter
Project Steward
Your Ally · Package #7 returned within its declared scope. Three draft Records are ready to inspect; none is part of the Organization’s official Record yet.voice

ST-12 · Project operating Field. Tools, people, an Actor, Records, and package state are objects. Registration is textual; provenance stays attached.

KIDUNA STUDIO · OPAQUE HUD organization · The Ceremony Machine
Command preview · role-authorized · not a signature

### Create “Lightbrush integration”

Creates one Project address and on-the-fly Scene identity inside The Ceremony Machine. Adds Elias, Moto, and Moe with the stated initial grants. Connects no tools and spends nothing.

project.create( organization: the-ceremony-machine, name: "Lightbrush integration", purpose_verbatim: "Bring Lightbrush's creative stack in as connected systems", lead: elias, members: [moto, moe], access: private )
run this command change it not now
Your Ally · conversation
Start a Project here for the Lightbrush integration. Elias runs it; Moe brings the tools in.
I’ve translated that into the command at left. Your Organization policy lets a Builder create a Project without a Forum vote. Say “go” or change any line.
Go.
Receipt preview
The Ceremony Machine will have a private Project named Lightbrush integration, led by Elias, with Moto and Moe as members. It begins with no connected tools or accepted Records.

ST-11 · Opaque HUD. Dense command inspection is still the Field focused on one Organization object. Receipt preview comes from the same typed parameters.

KIDUNA STUDIO · PACKAGE #7 Lightbrush integration · draft Records
Returned via Codex · pkg #7 · 18 min

### Three draft Records

Adapter implementation

12 files changed · constraints satisfied · malware scan clear

Test report

41/41 passed · generated by Codex · source package cited

Open limitation

Color pipeline remains outside the declared ask; no change made.

Consequence · fresh signature required

### Promote into the Organization Record

You are vouching that these three draft Records accurately represent the returned work. Authorship remains “via Codex · package #7.” This does not claim you wrote the work.

Accepts 3 draft Records from package #7 into The Ceremony Machine’s official Project Record under Moto’s vouching signature.
press and hold to sign acceptance

Gold appears only because the drafts cross into an authoritative Organization Record.

ST-17 · Acceptance. Routine WIP acceptance uses light; this authoritative promotion uses the gold signature ceremony with fresh authentication.

### Studio screen inventory and states

ID | Screen / Field state | Primary outcome | Failure / empty state
--- | --- | --- | ---
ST-00 | Server bootstrap | Install, join with Genesis Code, or restore existing Ecosystem. | Preflight failure names one dependency and offers safe retry; nothing registered.
ST-01 | Genesis custody | Create Mage keys, 2-of-3 stewards, recovery proof. | No cloud-only root; cannot continue until recovery drill succeeds.
ST-02 | Genesis Profile focus | Review signed public/operational consequences before publication. | Profile mismatch creates new digest; old signatures invalid.
ST-03 | Network registration | Publish DID/endpoints and receive generated registration receipt. | Pending and refused are explicit; local Ecosystem remains inspectable.
ST-04 | First Account and Ally | Moto binds passkey, becomes Source, names personal Ally, sets first Contract. | Handle race returns to conversation; no duplicate Ally.
ST-05 | Organization claim | Match Kinship Duna to official evidence and bind authority. | Verification unavailable/pending never fabricates Organization state.
ST-06 | Organization grounds | Inspect purpose, policies, Forum, Projects, alliances, registration. | No active Projects shows one conversational next act, not an empty dashboard.
ST-07 | Profiler / invitation | Prepare, disclose, correct, and sign one bound invitation. | Expired/withdrawn profile is deleted per policy; wrong recipient sees no sensitive detail.
ST-08 | Project create | Preview exact command, authority class, Scene identity, and receipt. | Missing role/policy is explained; no hidden “request admin” escalation.
ST-09 | Project Field | See people, tools, Actors, Records, packages, derived state, and ACTIONS. | Offline snapshot time is always visible.
ST-10 | Ingest / connect | Drop file or connect system; set access at add time; see destination and provenance. | Quarantine, scan failure, credential expiry, and unsupported resource are explicit.
ST-11 | Grant focus | State scope, path, trace, expiration/revocation, and exact commands. | Overbroad scope is narrowed before activation.
ST-12 | Actor / skill definition | Turn conversation into manifest, run evals, register immutable version. | Failed policy/eval leaves a Draft and cites the failing case.
ST-13 | Package compose / transit | Read context, ask, constraints, and return address whole; dispatch and recall. | Silence is elapsed fact; failure returns a reason; retry is new correspondence.
ST-14 | Return / diff / accept | Inspect provenance and promote only justified Records. | Out-of-scope return refused/quarantined; rejection preserves returned evidence.
ST-15 | Vigil / Record lens | Inspect exact authority, context sources, command, model/tool traces, and corrections. | Unavailable source is named; protected sources remain redacted honestly.
ST-16 | Ecosystem peers | Inspect endpoint, registration, relationship/trust scope, hosting, and recent KAP receipts. | Unregistered/untrusted remains usable at arm’s length; no fear styling.

Desktop-only truth

Five acts remain at the desk until Live can support honest inspection: composing packages, wiring systems, granting machine access, accepting returned work into an official Record, and uploading crafted assets. Live may capture “at my desk later” without pretending completion.

Canon basis: design-r7/UX-SPEC-R7.md and canvases 01–07; integrations.md §1; R7 “The Cut.” Screen proposals extend R7 backward to the actual Genesis path.

09

## Kiduna Live

The mobile-first end-user product: the full Field for participating, understanding, conversing, acting, signing when honest, and feeling the pulse of Projects without becoming Studio on a phone.

### High-fidelity mobile screen sequence

Kiduna Club · your ground
meet Moto’s Ally see what was prepared
Kiduna Club
Latent · your Ally
Moto relationship
Latent · I began with two sources Moto chose. Before we do anything else, you can inspect, correct, or forget every line.
LV-06 · First Field. Provenance before fluency; one clear next act.
The Ceremony Machine · Lightbrush integration
take the file leave it here at my desk later
Moe · at RenderDeck
test render · waiting
Project Steward
Your Ally · Moe sent a 240 MB test render through the server. Taking it syncs to your Project workspace and records the transfer.
LV-14 · Project pulse. Safe mobile acts plus an honest desk handoff.
BACK TO · LIGHTBRUSH INTEGRATION · PACKAGE #7
Three draft Records returned. The tests passed; the color limitation is still open.
Can I accept this here?
Not honestly yet. Acceptance makes the work part of The Ceremony Machine’s official Record, and this phone view can’t show you the full diff. I can hold it for your desk.
at my desk later read the summary not now
Your Ally · Your Field position and the returned package will still be here.
LV-11 · Opaque HUD. The Field persists; the product refuses signature theater.

### The member’s complete path

Beat | Member experience | System work | Required proof
--- | --- | --- | ---
1 · Invitation | Personal page distinguishes registry proof from the inviter’s verbatim voice and discloses what was prepared before an account exists. | Code verifies without consuming; sensitive detail stays recipient-bound; profile has expiration. | Issuer, scope, expiry, recipient binding, sources, deletion/objection path.
2 · Account | One act per page: passkey, recovery, account terms. Network standing is not silently Organization membership. | Create proof-bound session and portable member identifier. | Terms version, data home, recovery method, Account Record.
3 · Ally | Name and handle conversationally; first Contract sentences read back; exactly what the Ally knows is disclosed. | Reserve handle atomically; create personal Ally; bind Source; inherit no unauthorized context. | Source proof, Contract version, grounding provenance.
4 · Organization choice | Joining Kinship Duna or any duna is explicit; money/Compute is a separate web act if required. | Render agreement and role consequences; hand financial authorization to Account web. | Membership agreement, payment/credit receipt, Organization membership Record.
5 · First Field | Arrives on own relevant ground—no lobby or world picker. Ally opens with provenance, then meaningful context. | Permission-filter current subgraph; load low-fidelity Scene first; hydrate assets later. | Snapshot time, container, access basis, citations.
6 · Relationship | Each side states what they share; one two-sided relationship card, rendered everywhere from one graph object. | Create directional grants and history; no signature unless a protected capability requires it. | Each author, scope, revocation, last change.
7 · Daily return | Since-you-were-gone is consequence-first, cited, compressed to the gap, and asks at most one thing at a time. | Ledgerkeeper/Renderer query Records and Action Ledger; no fabricated urgency. | Every claim cites a Record; corrections print.
8 · ACTION | What, why, consequence; act, not now, or at desk later. The object is rimmed where the need lives. | Version-check underlying object, authorize command, expire stale ACTION. | Command receipt and clear outcome.
9 · Signature | Exact consequence and parameters, press-and-hold, fresh auth, gold once, then quiet. | Verify Source, policy, freshness, and signature; append immutable Record. | Signed intent + outcome/settlement reference.
10 · Project pulse | Walk Project Scene, hear narration, see declared presence and Package facts, answer mobile-safe ACTIONS. | Use same Project graph and Scene transcript as Studio; downshift visual assets. | Snapshot/freshness, provenance, mobile act capability.
11 · Invite next | Member begins a prepared, person-specific invitation; corrections improve the next welcome. | Profiler stays source-limited until invitee consent; Code is unique, expiring, revocable. | Signed Code; profile retention/deletion Record.

### Live requirements

#### Touch and voice

Tap to walk/focus, drag to look, pinch to rise. Voice-out is an early capability because reading while steering is a real usability failure. Full transcripts and interruption remain available.

#### Offline honesty

Cache semantic Scene graph separately from assets. “Offline · snapshot from 14:04.” Read and draft only. Never queue signatures, permission changes, money, registration, or authoritative acceptance.

#### Graceful fidelity

Crafted → generated → words/pixels under memory, network, or battery pressure. Capability and object identity remain unchanged; low-power mode reduces density and nonessential motion.

#### Boundary language

Secret objects are absent. Known private boundaries use plain lines: “held closer,” “you see the ones you share,” “none of this page’s business.” No locks or teaser silhouettes.

#### Notifications

Opt-in, Contract-bound, deep-link to exact object/ACTION, no app badge counts. Consequence—not engagement—determines whether the OS is used.

#### CTV / spatial later

Reuse Field semantics and spectator permissions only after mobile/desktop parity. Do not let device expansion drive protocol ontology.

Canon basis: design-r5 cohort journey; design-r6 invitation and Live; design-r7 mobile decision. Proposed changes: no separate Chat mode/One product, explicit network-vs-duna membership, offline signature prohibition.

10

## Protocol and system architecture

Probabilistic intelligence can propose, explain, compose, and render. Deterministic services resolve identity, authorize, commit, sign, reconcile, and preserve the record.

### Logical stack

Member surfaces Live · Studio · Account/Registry · Express · third-party clients `render + intent + signatures`
KAP edge Sessions, proof-bound identity, named queries/commands, federation envelopes, rate control, version negotiation `HTTPS · SSE/WS · signed envelopes`
Orchestration Ally routing, context assembly, candidate ACTIONS, Actor workflows, model/tool calls, citations `cannot authorize`
Graph command service Identity resolution, reachable subgraph, grants, roles, policy, conflicts, version checks, named commands, Records, receipt generation `SOLE POLICY + COMMAND BOUNDARY`
Data plane Typed nodes/edges, pgvector candidates, account/session control, artifact references, immutable Records, outbox, external-operation state `PostgreSQL + object storage`
Protocol adapters DIDs/keys, registry, Solana program(s), FROST/member custody, Squads, USDC/Compute, legal-registry adapters `independently verifiable refs`
Operations Key custody, logs/traces, privacy audit, backups, projection rebuild, reconciliation, incident response, conformance tests `no hidden authority path`
Figure 6The line around the graph command service is the architecture. Every first- or third-party path crosses it; no prompt, model, client, database query, integration, or Mage shortcut bypasses it.

### Deployment shape for the first Ecosystem

Recommendation

#### Modular monolith + workers first

Run one versioned application deployment for KAP/API, graph commands, named queries, identity resolution, receipts, and Record creation. Isolate orchestration, artifact processing, federation relay, and external reconciliation as workers. Split services only at measured security or scaling boundaries.

Why

#### Keep the one boundary real

A premature microservice mesh makes authorization and atomic local state harder to reason about. The product needs a clean contract more than a large service count. One PostgreSQL deployment can host typed graph tables, control tables, and pgvector while APIs enforce separation.

Runtime component | Owns | Trust level | Scaling path
--- | --- | --- | ---
API/KAP process | HTTP/SSE endpoints, auth challenges, envelope verification, request limits, response redaction. | Untrusted input boundary. | Stateless horizontal replicas.
Graph command process | Named queries/commands, policy evaluation, current graph projection, Records, receipts, outbox. | Highest application trust; no raw internet. | Single write leader initially; read replicas only through named queries.
Orchestration workers | Ally and Actor runs, context assembly requests, model calls, candidate ACTIONS. | Capability-scoped; never database or root-key access. | Queue partition by Ecosystem/Project, model budget.
Artifact workers | Upload, scan, parse, chunk, embed, generate previews, provenance. | Quarantined files and least-privilege storage paths. | Content-type queues and resumable chunks.
External-operation workers | Chain, wallet, email, domain, registry, and payment requests plus reconciliation. | Typed operation allowlist; idempotent external references. | Per-provider adapters and dead-letter operations.
Federation relay | KAP handshakes, peer keys, signed offer/accept, event/receipt resolution. | Peer input isolated from local graph writes. | Per-peer limits and circuit breakers.

### Storage model

#### Typed graph

`nodes` + `edges` with kind, controller, origin, current host, access level, lifecycle, version, provenance event, and validity. No generic client CRUD.

#### Semantic candidates

`embedding_chunks` in pgvector reference authorized Items/Records. Search runs only inside the caller’s reachable scope; vectors never grant traversal.

#### Control plane

`commands`, `events`, `records`, `outbox`, `external_operations`, `key_registry`, sessions, bootstrap runs, migrations.

#### Artifacts

S3-compatible encrypted object storage, content-addressed hashes, per-object keys, quarantine and scan state, retention/legal hold.

#### Records

Append-only member-facing evidence. Corrections and forgetting create superseding/tombstone Records; public audit hashes remain verifiable.

#### Event log

Internal ordered transitions with command, authority basis, stream version, origin Ecosystem, previous hash, and signature. Not every low-level event is member-visible.

Graph engine decision

Freeze the graph-service contract first. Implement v0 with explicit typed node/edge tables and recursive queries in PostgreSQL, plus pgvector. Benchmark Apache AGE against the real authorization traversals before adopting it. Do not let an engine choice leak into KAP or product object IDs.

### Identity and portable IDs

Identifier | Format | Purpose | Rule
--- | --- | --- | ---
Internal ID | `prj_01J…` (type prefix + UUIDv7) | Database and logs | Opaque; never proves authority.
Protocol ID | `kid:<network>:<kind>:<uuidv7>` | Portable cross-Ecosystem reference | Immutable when host or controller changes.
Controller | DID resolving verification keys and KAP service endpoints | Current signing/authority set | Rotatable with historical keys resolvable.
Handle | `[a-z][a-z0-9-]{2,29}` for v0 | Human address | Routing convenience, not identity; atomic reservation; global uniqueness is a product decision.
Field address | `kiduna://<protocol-id>?scene=…&focus=…` | Deep link to object and projection | Resolves permission at open time; never embeds a capability secret in the URL.

### The command loop

01 Intent Member language, UI act, Actor trigger, or federated request.
02 Resolve Authenticated principal, Source, Ally, container, object versions.
03 Authorize Access, grants, Code, role, policy, conflict, command class.
04 Validate Typed parameters, state preconditions, budgets, simulation boundary.
05 Execute Atomic local transition; external work becomes a saga operation.
06 Record Events, immutable Record, outbox, provenance, usage.
07 Render Sentence generated from executed parameters; Field updates.
Figure 7Reads stop after an authorized, side-effect-free result. Every Tool call or write re-enters this loop. External settlement returns later with its own verifiable outcome.

    {
      "command_id": "cmd_01J…",
      "name": "project.create",
      "schema_version": "1.0",
      "idempotency_key": "client-generated-uuid",
      "expected_versions": {"org_…": 18},
      "acting_context": {
        "principal_id": "kid:…:mem:…",
        "ally_id": "kid:…:ally:…",
        "ecosystem_id": "kid:…:eco:…",
        "organization_id": "kid:…:org:…"
      },
      "parameters": {},
      "intent_record_id": "rec_…",
      "authorization_proof": {}
    }

    {
      "record_id": "rec_01J…",
      "command_id": "cmd_01J…",
      "command": "project.create@1.0",
      "actor": "kid:…:mem:…",
      "authority_basis": ["role:builder", "policy:project-create"],
      "parameter_hash": "sha256:…",
      "renderer_version": "project-create/1",
      "sentence": "The Ceremony Machine now has…",
      "outcome": "committed",
      "external_refs": [],
      "access_level": "private",
      "provenance": ["rec_intent_…"],
      "occurred_at": "…"
    }

### Idempotency and concurrency

#### Same key, same payload

Return the original command status and Record. Never repeat the side effect.

#### Same key, different payload

Hard `409 idempotency_conflict`; require a new explicit intent.

#### Stale object version

Return `409 state_changed` with a safe, permission-filtered summary; the Ally re-reads consequences.

#### External uncertainty

Query by deterministic address/reference before retrying. “Submitted” and “settled” remain different.

#### Bootstrap rerun

Deterministic seed IDs and step keys converge. After public anchor, recover the same identity—never regenerate.

#### Cross-Ecosystem work

No distributed transaction. Each side writes signed offer/accept Records; shared settlement reference joins them.

### KAP v0

KAP is the versioned contract for client↔server and server↔server identity, capability, request, Record, registration, revocation, and receipt semantics. The Solana registry program is one protocol adapter—not the whole of KAP.

#### Client/API endpoints

`POST /v1/auth/challenges`
`POST /v1/auth/sessions`
`POST /v1/codes/verify|reserve|redeem`
`POST /v1/commands`
`GET /v1/commands/{id}`
`POST /v1/queries/{name}`
`GET /v1/objects/{protocol-id}`
`GET /v1/events?cursor=…`
`POST /v1/packages`

#### Federation endpoints

`GET /.well-known/kiduna`
`POST /kap/v1/handshake`
`POST /kap/v1/envelopes`
`POST /kap/v1/objects/resolve`
`POST /kap/v1/receipts/resolve`
`POST /kap/v1/codes/introspect`
`POST /kap/v1/events/pull`

    {
      "message_id": "msg_01J…",
      "protocol_version": "kap/0",
      "sender_ecosystem_did": "did:…",
      "recipient_did": "did:…",
      "message_type": "command.offer",
      "resource_id": "kid:…:prj:…",
      "issued_at": "…",
      "expires_at": "…",
      "nonce": "…",
      "body_hash": "sha256:…",
      "body": {},
      "signing_key_id": "…",
      "signature": "…"
    }

### Home Ecosystem and federation

Network-resident account, made concrete

A Member’s identity is portable and independently controlled; each mutable object declares one current authoritative home Ecosystem. Public state can replicate. Private state replicates only under grant. Secret state is not advertised. Personal material may have encrypted member-controlled replicas but never becomes peer-readable.

Federation fact | Required behavior
--- | ---
Any client may enter through any compatible Ecosystem | Ingress authenticates, resolves current authority endpoint, and either runs locally or forwards a signed request. Identity is not copied into an authoritative row at ingress.
Object may migrate hosts | Protocol ID remains; DID/controller and current-host attestations update through an authorized migration saga.
Peer relationship | Explicit, directional, scoped, revocable, time-bound. A spawn lineage does not imply trust.
Unregistered compatible server | May exchange public/explicitly offered material at arm’s length. Spawn Code is registration/endorsement in this Network, not permission to implement KAP.
Partition | Local permitted reads and local commands continue; cross-Ecosystem operations remain pending and cannot be reported settled.
Conflict | One authority stream per aggregate; optimistic versions reject divergent writes. Copies are caches, not co-writers.

### On-chain boundary

On-chain / independently anchored

#### Only accountability roots

Network configuration/program IDs; member controller/wallet reference; Ally registry entry if needed; Alliance/Organization authority refs; verified legal binding; Compute movement if approved; vote/outcome and external settlement references; public hash anchors.

Off-chain / permissioned

#### Everything that need not be public

Chat, personal context, relationships, grants, Guilds, Projects, full policies, skills, items, most Records, Field layouts, Actor prompts, lineage detail, simulations, and private artifacts.

Do not claim atomicity across the world

A Forum may atomically authorize a command set in Kiduna. Purchasing property, moving bank funds, filing legal documents, and confirming title are an external saga. The pre-execution receipt says what was authorized; the outcome receipt says what actually settled.

Canon basis: architecture.md; Protocol + Stack Architecture PDF §§1–13; foundation.md; protocol.md; integrations.md. Proposed decisions: modular monolith, typed Postgres graph first, home-Ecosystem authority, KAP/registry terminology split, saga semantics.

11

## Trust, privacy, safety, and custody

The four access levels are an excellent member-facing disclosure model. They are not, alone, a complete authorization, privacy, or security model.

### Policy precedence

HARD Protocol invariants Source-only, personal ungrantable, no raw CRUD, sim isolation.
NET Network policy KAP version, registry, required proofs, constitutional commands.
ECO Ecosystem policy Hosting, residency, abuse transport, model/provider boundaries.
ORG Organization policy Roles, Forum, conflicts, Project authority, legal constraints.
SCOPE Project / tool grants Objects, workspaces, commands, budgets, time.
HUMAN Relationship / Code Directional sharing and portable capabilities.
Figure 8A lower layer may narrow authority, never widen it. Explicit denial wins. Member-facing labels describe discoverability; authorization also considers controller, grants, purpose, legal class, retention, residency, role, policy, state, and conflict.

### Access labels plus orthogonal controls

Member label | Discoverability | Access path | Additional controls
--- | --- | --- | ---
public | Listed and readable | No grant required; rate/abuse controls still apply. | Controller, provenance, license, retention, registration, integrity.
private | Existence visible | Author/container grant or valid Code. | Purpose, fields, tool scope, expiry, residency, export restrictions.
secret | Not listed or discoverable | Proof required before resolution; query must not leak existence. | Key envelope, audit, anti-enumeration, strict retention and replication.
personal | Only the Member and personal Ally experience | Source-bound session; never grantable. | Member-controlled keys where feasible; server operator promise stated honestly.

Sentinel storage correction

Do not invent a fifth access level called “personal-to-the-system.” Keep the four member labels and add an orthogonal `security_class=system_internal` for operational readings, service credentials, abuse signals, and key metadata. System-internal data still needs controller, retention, purpose, and audit.

### The trust matrix

Relationship established · resource registered

#### Known here and traceable

Full standing only within explicit grants. Registration adds provenance, not extra permission or safety.

Relationship established · resource unregistered

#### Known here, not globally traceable

May work inside the scoped Project; provenance states unregistered; no automatic travel outside the context.

Relationship limited · resource registered

#### Traceable, held at arm’s length

Use public/explicit exchanges and cite the issuer; no file sync or member-machine execution.

Relationship limited · resource unregistered

#### A visitor at the counter

Public offers only; quarantine and inspect any returned artifact; no fear language and no hidden escalation.

The database should not store one global “trusted” Boolean as authorization. Store directional, scoped assertions and grants. The HUD may summarize mutual standing in plain language when both sides have explicitly established it.

### Four independent trust roots

#### Network root

Chain/network configuration, registry program IDs, governed and time-locked upgrade authority. Never controlled by one Mage.

#### Ecosystem root

Mage threshold keys, signed Genesis Profile, server/service keys, hosting and recovery policy.

#### Member root

Member DID/FROST wallet, passkeys, chosen recovery guardians. Mage may freeze a hosted session, never become the Member.

#### Organization root

Verified legal identity, governing-principles version, Squads/authority set, Forum policy. Not subordinate to Genesis Duna.

### Key custody

Key | Custody | Use | Rotation / recovery
--- | --- | --- | ---
Ecosystem recovery root | Offline 3-of-5 or product-owner-approved threshold | Replace Mage and online service keys | Annual drill; no private material in database.
Mage control | HSM-backed threshold stewards | High-risk ecosystem commands | Named command, delay, immutable Record.
KAP / Code / event signing | Online HSM/KMS, separate keys | Envelopes, capabilities, log chains | Overlap window; historical public keys remain resolvable.
Data KEK | HSM/KMS | Envelope-encrypt per-object data keys | Rewrap without rewriting provenance.
Member authority | Passkeys + FROST/wallet + optional guardians | Source sessions and high-risk signatures | Member recovery ceremony independent of Mage.
Program upgrade authority | Separate time-locked DAO/Squads authority | Solana program upgrades | Not Mage; public delay and receipt.

### Privacy requirements for the Profiler and ambient context

P0 gate

#### Invitation-bound profile

Before invitee consent: only inviter-provided facts and links; encrypted; public-source-only; no sensitive inference; no model training; expires with the Code; wrong recipient sees no sensitive details. The invitation discloses source, purpose, holder, retention, and rights.

P0 gate

#### Invitee control

Before retention or enrichment, invitee can inspect, correct, forget, object, and choose access. Joining does not silently ratify every inferred fact. Deletion leaves only minimal abuse/audit proof where legally required.

Channel consent

#### Bystanders and groups

One system presence per channel does not create permission to retain everyone. Define group notice, platform terms, recording rules, retention, and when non-member speech stays ephemeral.

Purpose limitation

#### No omnivorous “one store”

Store one logical subject fact with provenance, not one physical global lake. Separate organization contexts, credentials, legal privilege, health information, and model-provider boundaries.

### Collaboration and package safety

#### Package-only v0

User-selected workspace, explicit input manifest, no raw credentials, declared ask/constraints/return, output quarantine, scan, and human inspection.

#### Remote machine later

No remote desktop and no arbitrary shell. If added: per-command allowlist, ephemeral sandbox, one Project workspace, time budget, shared trace, immediate revocation.

#### Registered still sandboxed

Registration verifies provenance only. Registered resources need least privilege, content scanning, rate limits, and revocation just like unregistered ones.

### Sentinel launch contract

Observe first

v0 may collect only the minimum, consented signals needed to evaluate the design. No hidden pacing correction, public reading, person score, employment/credit/insurance use, dispute evidence, vote, money, sanction, diagnosis, or autonomous crisis decision. Human escalation and member-readable explanations must exist before any intervention.

### Threat model: minimum abuse cases

Threat | Primary defense | Required test
--- | --- | ---
Prompt injection attempts to widen access | Graph-service authorization and scoped retrieval/tool closures. | Adversarial text never changes reachable graph or command authority.
Non-Source commands another Member’s Ally | Authenticated Source equality at every instruction/tool call. | Cross-channel and federated spoof suites fail closed.
Mage compromise | Threshold keys, closed capabilities, offline recovery, no personal decryption. | Compromised Mage cannot vote, sign as Member, move funds, or read personal.
Secret enumeration | No existence response before Code proof; uniform errors/timing budgets. | Dictionary, search, vector, error, and count side channels.
Code replay / wrong recipient | Proof-of-possession binding, nonce, reserve/consume, expiry, revocation. | Concurrent redemption and device-transfer cases.
Malicious returned package | Quarantine, scan, sandboxed preview, manifest diff, no auto-execution. | Path traversal, secrets, binaries, symlink, prompt/file injection.
Federation replay/equivocation | Signed envelope, nonce, expiry, ordered authority stream, hash chain. | Duplicate, out-of-order, conflicting host/controller claims.
False receipt | Renderer consumes executed typed parameters; round-trip/property tests. | Every command schema → sentence → parameter proof.
Sim reaches real rail | Separate capability graph and simulated identifiers; no resolver path. | Property test over every financial/wallet/Code command.
Offline stale act | Read/draft only offline; freshness/version check on reconnect. | No queued signature, grant, money, registration, or acceptance can commit.

Canon basis: architecture invariants; Foundation access; R7 trust matrix and collaboration; Sentinel; Legal/Privacy open work. Security additions are proposed implementation requirements.

12

## Development plan

Build the constitutional contracts first, then the creation loop, then the real-work loop, then the daily member loop, and only then prove federation and broader economics.

Planning stance

Use exit gates, not calendar theater. With a focused 10–13 person product/engineering group, the sequence below is roughly 28–36 engineering weeks with four parallel workstreams. The first meaningful internal demo should arrive much earlier, at the end of Phase 2.

### Parallel workstreams

#### A · Contracts & graph

Ontology, IDs, policy, named queries/commands, Records/receipts, event/outbox, access and grants.

#### B · Field & clients

Shared Field runtime, HUD states, Scene transcript, accessibility, Live mobile and Studio desktop shells.

#### C · Agents & integrations

Ki, personal Ally, Profiler, Actors, artifact pipeline, package protocol, model/tool evals.

#### D · Protocol & operations

Genesis, keys, Account/Registry web, KAP, legal registry, chain adapters, backups, security and conformance.

### Phased build

Phase | Outcome | Primary work | Exit gate | Indicative
--- | --- | --- | --- | ---
0 · Canon freeze | One build contract | Ratify product names, glossary, typed graph, Ki/Mage, membership, Organization/DUNA lifecycle, Project/Scene, ACTION, Compute v0, KAP terms. Publish ADRs and schema registry. | No P0 ontology conflict remains; every screen label maps to one schema term. | 2–3 weeks
1 · Constitutional core | Graph service is real | IDs; access including secret; named queries/commands; policy stack; Source checks; Records/events/outbox; receipt renderers; auth/passkeys; artifact skeleton. | Authorization suite proves no retrieve-then-filter, no non-Source instruction, no raw CRUD, honest receipts. | 4–5 weeks
2 · Genesis slice | First Ecosystem can seal | Installer/preflight, key ceremony, Genesis Profile, Mage, Ki host, deterministic seed, Account/Registry status, Kinship Duna verification, first steward claim. | Clean install reproduces public state; Mage negative tests; restore drill; Moto reaches first Field. | 4–5 weeks
3 · Recursion slice | One person can bring one person in well | Personal Ally, Contract, handles, Code reserve/redeem, Profiler-limited flow, invitation disclosure, Account onboarding, relationship grants, first Field/scene transcript. | Moto invites one collaborator; collaborator creates Ally and can prepare the next invitation; all sources/corrections visible. | 4 weeks
4 · Studio real-work slice | One Project completes real work | Organization grounds, Project/Scene/ACTION, uploads, tools, grants, Project Steward, Package Courier, Codex/Claude Code handoff, return quarantine/diff, Record acceptance, Vigil. | Lightbrush path runs upload → connect → dispatch → return → inspect → accept → render in Field. No hidden filesystem authority. | 5–6 weeks
5 · Live daily slice | Member can live in the system | Flutter mobile Field, HUD states, voice-out, awareness, object focus, ACTION, signature ceremony, Project pulse, deep links, offline snapshot, accessibility parity. | Core path works on mid-range iOS/Android, keyboard/screen reader web harness, reduced motion, offline safety. | 4–5 weeks
6 · Organization factory | Alliance can form a verified DUNA | DunaPlan, ≥100-member/consent evidence, governing principles, filing evidence, Organization registration, roles, Forum v0, policies, conflict recusal, fixed usage-credit ledger. | No Organization before verified legal adapter; one signed proposal executes its exact local command set; registration lapse handled. | 4–5 weeks
7 · Federation proof | Second independent Ecosystem | Spawn endorsement, child Genesis, KAP discovery/handshake, current-home routing, signed offers/receipts, all four trust/registration quadrants, partitions and recovery. | Independent operator passes conformance; parent cannot administer child; unregistered KAP server works at arm’s length. | 4–5 weeks
8 · Hardening & release | Operable public beta | Threat model closure, load, privacy review, counsel gates, accessibility audit, observability, support, incident runbooks, supply-chain/SBOM, Apache/trademark review. | All release gates green; backup restore and key compromise exercises; no open P0 legal/security item. | 3–4 weeks

### Roadmap by workstream

Workstream
Constitution
Genesis + recursion
Studio work
Live + org factory
Federation + hardening
A · Graph
ontology · commands · access
accounts · Allies · grants
Projects · packages · ACTIONS
Forum · legal adapter
federated capabilities · conformance
B · Field
semantic shell · transcript
first Field · relationship
Studio HUD · diff · ingest
Live · voice · offline
peer Field · performance · audit
C · Agents
runtime contract · eval harness
Ki · Ally · Profiler
Steward · Courier · ingestion
Forum Facilitator · observe-only Sentinel
federated routing · safety evals
D · Protocol/Ops
keys · KAP envelope · CI
installer · registry · recovery
artifacts · local agent seam
legal evidence · web handoffs
second Ecosystem · DR · release
Figure 9Each vertical slice must run through all four workstreams. A beautiful Field without the command boundary—or a perfect graph with no member path—is not a release.

### Recommended team shape

Capability | Minimum ownership | Notes
--- | --- | ---
Product / canon | Product owner + product architect | Own decision ledger, scope, terminology, and acceptance; counsel/design are embedded reviewers.
Graph / command / identity | 3–4 backend engineers, one security lead | At least one engineer owns schemas and conformance, one owns identity/custody.
Field / Live | 2–3 Flutter/Flame engineers | Shared semantic runtime, mobile performance, accessibility projection.
Studio / desktop / integrations | 2 engineers | Desktop shell, local file boundary, package protocol, inspection/diff.
Agent runtime / evals | 2 agent engineers | Context assembly, Actors, tool sandbox, versioning, cost and behavioral evals.
Design / accessibility | 1 product designer + 1 design engineer/accessibility owner | Field grammar, screen states, semantic transcript, motion and language.
Reliability / QA | 1 SRE/platform + 1 QA/automation | Genesis/restore, KAP conformance, device matrix, security and failure injection.

### Scope cut

v0 · must prove

#### One safe Ecosystem

Server, Genesis, Mage limits, Ki, one Member/Ally, Kinship Duna verified, invitation recursion, Project/ACTION/optional Scene, package handoff, Studio desktop, Live core, Account web, fixed usage ledger, observe-only Sentinel.

v1 · network proof

#### Two peers

Formal KAP conformance, second independent Ecosystem, current-home routing/migration, cross-Ecosystem resources, legal-form adapters, Alliance wallet, Forum maturity, Express provenance browser.

defer until gated

#### High-risk expansion

Transferable Compute/tokens/liquidity, multilevel commissions, Ally NFTs, remote-machine command execution, ambient Sentinel correction, unconsented profiling, many voting types, CTV/MR/VR, broad autonomous browser action.

Plan derives from architecture PDF §12, Create from Within, R6 recursion cut, R7 real-work cut, and the open security/legal decisions identified in this review.

13

## Acceptance, quality, and operations

The system is ready when its invariants survive failure and adversarial use—not when its happy-path demo looks complete.

### Release gates

Identity & authority

- No non-Source message becomes instruction.
- Mage cannot use Member capabilities or read personal plaintext.
- First- and third-party clients pass identical authorization tests.
- Member recovery and Mage recovery are separate ceremonies.
- Institution conflict recusal is command-enforced.

Access & privacy

- `secret` works end-to-end, including search/count/error side channels.
- No protected object is retrieved then filtered.
- `personal` is ungrantable and operator access is stated honestly.
- Profiler expiry, disclosure, correction, objection, and deletion are tested.
- Offline never queues a consequential act.

Commands & Records

- Every mutating path is a named command—no generic graph CRUD.
- Every command round-trips exact parameters to a generated receipt.
- Duplicate idempotency keys cannot duplicate effects.
- External operations have pending/settled/failed/reconciled states.
- Records remain verifiable after key rotation and correction.

Field & clients

- Every meaningful object/action has semantic transcript parity.
- Core path works by keyboard and screen reader.
- No meaning depends on color, shape, motion, distance, or sound alone.
- Reduced motion and 200% zoom preserve function.
- Studio and Live render the same object IDs, consequences, and provenance.

Agents & tools

- Actors cannot change their allowlists, budgets, or owner scopes.
- Returned packages are drafts, quarantined, scanned, and source-cited.
- Prompt injection cannot widen retrieval or tool scope.
- Model/provider failure never fabricates completion.
- Sentinel remains observe-only until a separate gate passes.

Federation & operations

- A second independent Ecosystem passes KAP conformance.
- Parent Mage cannot administer child Ecosystem.
- All four relationship/registration quadrants behave as specified.
- Backup restore, projection rebuild, key compromise, chain outage, and partition drills pass.
- Supply-chain signatures/SBOM and Apache/mark separation are reviewed.

### End-to-end acceptance scenarios

ID | Scenario | Pass condition
--- | --- | ---
E2E-01 | Fresh Genesis | Offline profile ceremony → deterministic seed → public attestation → Kinship Duna verification → Moto account/Ally → sealed Genesis Record; rerun changes nothing.
E2E-02 | Prepared invitation | Inviter-provided sources → disclosure → bound Code → invitee inspection/correction → account/Ally → relationship grants; expired invitation deletes profile.
E2E-03 | Recursive creation | The newly invited member can prepare the next unique invitation without an operator or database edit.
E2E-04 | Project from conversation | Typed preview names authority and consequence; command creates Project/anchor/Record; state derived; Studio and Live show same object.
E2E-05 | Lightbrush package | Upload → connect → grant → compose/read-back → dispatch → truthful in-flight → return/quarantine → diff → authoritative acceptance → Field Record.
E2E-06 | Secret search | Unauthorized member cannot discover existence through graph, vector, counts, latency, errors, federation, or cached Scene.
E2E-07 | Non-Source injection | A peer member, website, email, Tool, and peer Ecosystem all fail to turn context into binding Ally instruction.
E2E-08 | Organization formation | Alliance/DunaPlan remains forming until governing principles, member threshold, filing, and evidence verify; active Organization appears only then.
E2E-09 | External saga | Authorized external operation survives timeout/duplicate callback/restart and never reports settlement before verifiable confirmation.
E2E-10 | Peer Ecosystem | Child consumes bound Code, creates independent custody, defaults limited/untrusted, completes KAP handshake, and retains autonomy after relationship revocation.
E2E-11 | Offline mobile | Member reads snapshot and drafts; consequential actions are unavailable; reconnect re-reads current state before any send.
E2E-12 | Accessible Field | Blind keyboard/screen-reader participant completes invitation, object inspection, ordinary ACTION, and Project pulse without spatial guessing.

### Initial service objectives

Area | Target for beta | Measurement boundary
--- | --- | ---
Graph named read | p95 ≤ 300 ms, excluding model generation and remote federation | Authenticated request to permission-filtered response.
Local command commit | p95 ≤ 700 ms, excluding fresh-auth ceremony and external operations | Accepted command to committed Record/outbox.
Field semantic first render | ≤ 2 s on supported mid-range phone; crafted assets may hydrate later | Open/deep link to usable container, transcript, Ally band, ACTIONS.
Availability | 99.9% monthly for identity, graph command, and Account web in beta | Exclude announced maintenance only with safe read-only behavior.
Recovery | RPO ≤ 5 min; ordinary RTO ≤ 4 h; root incident ≤ 24 h | Confirmed by quarterly restore and annual root ceremony drill.
Receipt integrity | 100% schema/property round-trip; zero independent prose fields | Every command/version in CI and production sample verification.
Accessibility | WCAG 2.2 AA; zero critical audit blockers | Automated + manual assistive-technology testing.

### Observability without surveillance

#### Operational

Request IDs, command latency, authorization reason codes, outbox lag, external-operation age, KAP peer health, cost and model/tool error. No raw personal prompts in ordinary logs.

#### Member-visible Vigil

For a selected act: context sources, authority basis, model/Actor version, tools, command, Record, corrections, and external refs—permission-redacted but never misleading.

#### Product learning

Completion, refusal, correction, abandonment, accessibility, and latency at aggregate/privacy-preserving levels. No addictive engagement targets, person scores, or hidden trust ranking.

### Operational runbooks required before beta

#### Key compromise

Mage/KAP/Code/member/organization keys each have different freeze, rotate, notify, and historical-verification paths.

#### Data incident

Contain host, identify objects/grants, preserve signed audit, notify controllers/members, rotate envelopes, support export/deletion and regulator timelines.

#### External inconsistency

Read-only affected commands, reconcile from verifiable source, never rewrite Records, append correction/outcome, expose status plainly.

#### Federation abuse

Rate-limit/circuit-break peer, retain signed evidence, narrow relationship without erasing identity, keep local permitted work available.

#### Model failure

Fall back to deterministic views and command previews; no silent model/provider switch across declared data boundaries.

#### Legal status change

Mark evidence stale/invalid, preserve Organization history, notify humans, block only commands requiring current legal standing.

14

## Canon objections and owner decisions

These are not editorial preferences. They change data contracts, authority, legal posture, or the meaning of the product and should be decided before the corresponding phase begins.

### P0 — decide before schemas and public commitments

P0.1
Field-only conflicts with R7’s separate Chat postures.

Evening canon says the Field is the only interface; delivered R7 UX still names Field-only, Chat-only, overlay, and side-by-side. This spec resolves them as HUD states over one Field.

RATIFY THIS SPEC
P0.2
Mage cannot be an omnipotent account administrator.

That wording conflicts with personal access, Source sovereignty, peer ecosystems, and recovery separation. Limit Mage to hosting/control-plane capabilities with threshold custody.

LIMIT AUTHORITY
P0.3
Ki exists before a Member although Allies represent Members.

Use “Genesis Ally” in the experience but model Ki as Genesis Host Actor + Ally template, or define one explicit non-sovereign genesis subtype.

TYPE KI
P0.4
Network identity cannot silently equal Kinship Duna membership.

New canon forces every Account into the Genesis Duna; older canon makes membership per-duna and purchase-gated. Separate Account, Member, affiliation, Organization membership, and Compute purchase.

SEPARATE CONSENTS
P0.5
Small founding circles do not automatically meet WV DUNA requirements.

Current West Virginia Code defines a DUNA as at least 100 mutually consenting members and permits dissolution if membership falls below 100. A filing/Org ID alone is not a complete lifecycle model.

COUNSEL + ADAPTER
P0.6
WV DUNA is not a global protocol ontology.

Use jurisdiction-neutral Organization + verified legal-form adapters; WV DUNA is the first adapter. Otherwise worldwide Ecosystems terminate in one state’s law by design.

GENERALIZE
P0.7
“Accounts live on the Network” needs a home-authority model.

A mesh cannot be one physical global context store. Specify portable identity, one authoritative home per mutable object, explicit replication, migration, partitions, residency, and encryption.

ADOPT HOME ECO
P0.8
Four access levels are discoverability labels, not the complete policy model.

Authorization also needs controller, capability, purpose, field, legal class, retention, residency, role, state, and conflict. “personal-to-the-system” proves an orthogonal class is needed.

ADD ABAC
P0.9
Compute’s mechanics may contradict “usage credit” substance.

Transferability, launch-price conversion, liquidity, investment commands, and holding behavior create facts that vocabulary cannot erase. Recommend fixed nontransferable service credits in v0; counsel approves any later token design.

DEFER TOKEN
P0.10
Four-level organizer commissions on initial purchases are not ready for v0.

The canon’s 20/5/3/2 downline includes mandatory initial purchase while legal item L-14 remains open. Remove multilevel commissions from v0; revisit only with counsel and real consumption data.

REMOVE FROM V0
P0.11
External organizational acts are sagas, not atomic commands.

Property, bank, filing, title, and chain systems cannot share one transaction. Distinguish local authorization receipt from final settlement receipt.

ADOPT SAGA
P0.12
Profiler and ambient listening need a privacy basis before launch.

Pre-account research and retention of non-member speech require notice, source/purpose limits, sensitive-inference bans, correction/deletion, bystander rules, provider disclosure, and regional compliance.

PRIVACY GATE

### P1 — resolve before expansion

P1.1
The hierarchy is not a containment tree.

Guilds do not contain Allies; Members cross organizations; Alliances can include people from elsewhere. Implement typed edges and show the hierarchy only as policy/container context.

GRAPH, NOT TREE
P1.2
Institution is currently entity, role, and Alliance subtype.

Model Institution as an external legal entity under agreement. Its humans receive InstitutionDelegate roles. It can participate with a wallet but never vote as an entity.

NORMALIZE
P1.3
Project, Engagement, and Alliance are blurred.

A Project is work; an Engagement is a contract; an Alliance is a durable member-governed group with a wallet. They may link but should never be synonyms.

FREEZE TERMS
P1.4
Membership permanence conflicts with remove/suspend/restore.

Make historical membership immutable but operational status active, suspended, withdrawn, expelled, or organization-ended.

STATE MACHINE
P1.5
Binary trust is too coarse for authorization.

Trust may summarize a human relationship; only directional, scoped grants authorize files, tools, machines, or secrets.

GRANTS AUTHORIZE
P1.6
No-list/no-navigation absolutism harms discoverability and access.

Ship a semantic Scene transcript and canonical Action Ledger rendered as temporary HUD states—not a competing file tree or addictive inbox.

ALLOW PROJECTIONS
P1.7
Every Project room can become spatial clutter.

Give every Project a stable Scene identity and anchor, but lazily materialize/collapse the room. Capability remains independent of visual grade.

LAZY SCENE
P1.8
Gold on in-flight packages violates gold = signature.

Use sky for actionable and mint/light for returned state. Use gold only when a human signs promotion into an authoritative Record or another defined sovereign boundary.

RESTORE GOLD LAW
P1.9
Remote collaboration exceeds the bounded package protocol.

Ship package-only v0. Remote commands require a separate sandbox, consent, credential, malware, trace, and revocation design.

DEFER REMOTE EXEC
P1.10
One logical Ally must not mean one undifferentiated security context.

Keep one member-facing relationship, but isolate organization/project secrets, tool credentials, model-provider boundaries, conflicts, and budgets.

ISOLATE CONTEXTS
P1.11
Ally NFT is both mandatory and newly unnecessary.

Start with a registry entry controlled by Member/authority set; preserve transfer/co-ownership semantics only if needed. Do not force token form into product identity.

DECIDE LATER
P1.12
Forum semantics are inconsistent with prediction markets.

v0 should be signed one-person/one-vote pass/fail. Additional voting/market mechanisms require named semantics and cannot reuse “Forum” ambiguity.

SIMPLE FORUM V0
P1.13
One worker classification everywhere is not a software invariant.

Classification depends on actual control and independence facts. Store engagement-specific terms and review triggers; do not hard-code 1099 as truth.

COUNSEL + DATA
P1.14
Sentinel opacity can become covert behavioral manipulation.

Keep v0 observe-only and opt-in by context. Require plain explanations, member-accessible provenance without public scores, false-positive evaluation, and independent review.

OBSERVE ONLY

### Product-owner ratification checklist

# | Decision | Recommended call in this spec | Blocks
--- | --- | --- | ---
1 | Current normative canon | Create v0.1 from July 11 evening canon; historical tracks are precedent where non-conflicting. | All work
2 | Product taxonomy | Live + Studio primary; Express + Account support; Server/Protocol/Network infrastructure; One becomes deep link. | UX, repos, domains
3 | Field semantics | One Field shell; chat/docs/tables/diffs are HUD projections. | Field runtime
4 | Mage / Ki | Mage control-plane only; Ki Genesis Host Actor + Ally template. | Genesis, auth
5 | Identity / membership | Network Account and Member separate from explicit Organization membership and Compute. | Onboarding, legal
6 | Organization ontology | Jurisdiction-neutral Organization; WV DUNA adapter first; DunaPlan before verification. | Schema, Registrar
7 | Project / Scene | Project is work container; stable Scene identity; lazy materialization/collapse. | Studio, Field
8 | ACTIONS | Definition, request, command, Record are distinct; ship Action Ledger without badges. | Graph, HUD
9 | Compute v0 | Fixed nontransferable service ledger; no multilevel commissions. | Legal, money
10 | Forum v0 | Signed equal pass/fail; role/policy commands do not all require Forum. | Governance
11 | Federation entry | Spawn Code registers/endorses a child in this Network; compatible servers may remain unregistered. | KAP
12 | Profiler / Sentinel / remote execution | Consent-limited Profiler; observe-only Sentinel; package-only collaboration for v0. | Privacy, agents

Legal posture

This is a product and architecture risk review, not legal advice. DUNA status, securities/crypto, payments, organizer compensation, worker classification, privacy, and consumer claims must be reviewed against the implemented facts—not only the intended wording.

15

## Canon source map

The archive is rich but currently has metadata and precedence drift. Engineering should receive this specification, generated schemas/registries, ADRs, and conformance tests—not the historical archive as an undifferentiated contract.

### Precedence used for this specification

1. July 11 evening canon: `skill-updates/cofounder-canon-2026-07-11.md`, especially Evening additions; corroborated by the R7 prompt.
2. Design R7: interaction and visual precedent where it does not restore the superseded Field/Chat split.
3. Current tracks: Architecture, Foundation, Protocol, Orchestration, Surfaces, Actions, Roles, Organizations, Institutions, Integrations, Sentinel, Legal, Create from Within.
4. Architecture PDF: detailed engineering baseline for unresolved contracts and release gates; July 11 canon wins on conflicts.
5. R2–R6: visual grammar and journey precedent—gold/light, receipts, onboarding, Live HUD, cards, motion—translated into the Field-only model.

### Source-to-decision map

Source | Used for | Important caveat
--- | --- | ---
`START-HERE.md` + July 11 delta | Terminology, current products, Server/Network/Mage/Ki, Projects, Field-only, trust matrix. | START-HERE metadata still mixes v5.2/v5.3/v5.4 language.
`architecture.md` | Sole boundary, six layers, command path, identity trace, peer Ecosystems, release gates. | Predates Field-only and Mage detail.
`foundation.md` | Graph, nodes, four access labels, grants, context/provenance, Records, sim boundary. | Hierarchy and one-store language need federation correction.
`protocol.md` | Minimal chain, governance commands, machine-generated receipts, registration vocabulary. | Ally NFT, WV-only global model, and “atomic” external commands are reconsidered.
`orchestration.md` | Source-only instruction, Ki/personalized Allies, two agent families, channels, Profiler, traces. | Physical “one system/store” is interpreted logically, not globally.
`design-r7/*` | Project anatomy, package seam, server collaboration, Field object grammar, Studio screens, mobile limits. | Separate Chat postures are superseded; gold package rim rejected.
`design-r6/*` + R5 journey | Invitation, disclosure, Account/Ally onboarding, Live HUD, access geometry, mobile flow. | Chat/Live modes and separate One product become HUD/deep-link states.
`the-working-organization.md` | Actor/worker roster, ambient coordination, Records, Project-like real-work narrative. | Older HEARTS, roles, markets, and surfaces are not current canon.
`legal.md` + `legal-items-for-review.md` | Messaging constraints, payment posture, trust funds, conflict recusal, open counsel queue. | Some adopted “rules” remain fact-sensitive and require final counsel review.
`Kiduna-Protocol-and-Stack-Architecture-v1.0.pdf` | Services, storage responsibilities, command properties, KAP, release sequence and unresolved decisions. | v5.2/R6 baseline; later canon wins.

### External public authorities verified for objections

#### West Virginia DUNA statute

The current definition requires at least 100 mutually consenting members; dissolution provisions address falling below 100. See WV Code §36-13-2 and §36-13-14.

#### Crypto/securities substance

The SEC explains that even a non-security crypto asset may be offered subject to an investment contract depending on representations and expected managerial efforts. See SEC: Transactions Involving Crypto Assets.

#### Organizer/downline risk

The FTC’s guidance evaluates downlines, participant purchases, recruitment incentives, and genuine product demand. See FTC MLM business guidance.

#### Worker classification

The IRS describes common-law classification through actual control and independence facts rather than labels alone. See IRS common-law employee guidance.

#### Pre-account profiling transparency

European Commission guidance summarizes notice duties around source, purpose, recipients, retention, rights, and automated decision/profiling information. See EC information for individuals.

#### Use of these sources

They establish that the flagged questions are real implementation gates. They do not substitute for Kiduna’s counsel applying the law to its exact entities, agreements, software, economics, and jurisdictions.

### Engineering artifacts to generate next

#### `CANON.md`

One version, glossary, invariants, product taxonomy, source precedence, superseded language, and owner-ratified decision ledger.

#### Schema registry

JSON Schema/Protobuf for IDs, Genesis Profile, KAP envelope, commands, events, Records, Codes, grants, Actor manifests, ACTIONS.

#### Command registry

Authority class, parameters, preconditions, effects, receipt renderer, error taxonomy, idempotency, external saga, tests.

#### ADRs

Mage/Ki; Account/membership; Organization adapters; home Ecosystem; graph engine; KAP/chain split; Compute v0; Project/Scene; Action Ledger.

#### Conformance suite

Authorization, receipt, Code, KAP, sim isolation, federation quadrants, offline safety, accessibility semantic parity.

#### Clickable prototypes

Genesis, first invitation, Project creation, Studio package seam, Live ACTION, opaque HUD, Scene transcript, peer Ecosystem relationship.