# Architecture

**The protocol and the stack — how the whole thing is actually built · v1.0 baseline · 2026-07-10**

This is the engineering shape of the Kidunaverse, written so anyone joining can hold it in their head. The full baseline — invariants, schemas, sequence, acceptance gates — is the **[Protocol + Stack Architecture v1.0 (PDF)](downloads/Kiduna-Protocol-and-Stack-Architecture-v1.0.pdf)**. Where that document and the [Kiduna Kit](index.html) disagree, the Kit wins. The spec tracks behind everything here: [Foundation](foundation.html), [Orchestration](orchestration.html), [Protocol](protocol.html), [Integrations](integrations.html).

---

## 1. The one rule everything hangs on

**The graph service is the sole policy and command boundary.** Models, personas, surfaces, channel adapters, and integrations never authorize themselves. That's the whole trick of building with probabilistic agents: the intelligence proposes, deterministic code authorizes and commits. An ally can be brilliant, persuasive, or wrong — it makes no difference to what it's *allowed* to do, because permission is checked in one place, on every read, write, and tool call, and that place can't be sweet-talked.

## 2. The six layers

Top to bottom: **Surfaces** (Kiduna · One · Live · Express · Studio · Kidunaverse — they render experience and collect human intent and signatures; they never decide authorization) → **KAP edge** (the protocol connecting clients and servers: identity, requests, receipts, registrations; thin channel adapters; the API/MCP edge) → **Orchestration** (one agent system: Ki's personas, Allies and Actors, LangGraph, context assembly) → **Graph service** (identity, access, grants, codes, roles, policies, conflicts, named commands, receipts — the authoritative boundary) → **Data** (the graph, pgvector for meaning, plain Postgres for accounts, Records for what happened) → **Protocol + rails** (the decentralized registry, FROST wallets, ally NFTs, Squads, Forums, USDC and Compute).

## 3. The invariants (the short version)

One policy boundary. Instruction comes only from the Source. Context is shared; authority is not. Four access levels, everywhere — and personal is never grantable. Vectors are meaning, never authority. Named commands, not raw CRUD. Receipts cannot lie — the sentence members read is generated from the exact parameters that execute. Minimal chain: on-chain only where legal accountability requires traceability. Registered proves traceability, not virtue. Simulations are structurally incapable of touching real rails. Integrations are tools under grants, never parties with standing.

## 4. How a command runs

Intent → Resolve (who's asking, as whom, where) → Authorize (level, grants, codes, role) → Validate (policy, state, recusal) → Execute (one named atomic command) → Record (receipt, provenance, trace). No prompt, persona, adapter, or integration can bypass the middle four steps. Reads are permission-scoped and side-effect-free; acts change state and leave a Record; settlement happens on web or chain rails and returns a verifiable reference.

## 5. Identity, in one chain

Member FROST wallet → Ally NFT inside it → Alliance or Organization Squads wallet → registered DUNA → WV Secretary of State Org ID. Kinship Codes carry those addresses as signed JWT claims, so the chain travels over ordinary email, web, and messaging. Members see **registered** (with its trace) or **unregistered — a stranger, not a threat** — never "trusted" as a verdict.

## 6. Ecosystems and KAP

One installed server-side stack is an **ecosystem**, created from a Genesis Profile. The Genesis Ecosystem is Kiduna; other ecosystems are peers, never subordinates, interoperating over **KAP** — which must preserve the same identity, authority, access, command, receipt, and trace semantics across every implementation. The stack ships Apache 2.0; the marks stay licensed.

## 7. What's decided and what's still open

The baseline marks its own gaps honestly: the graph engine selection (in-house model, Apache AGE named as candidate), the Code JWT profile and revocation transport, async settlement/retry/reconciliation design before financial commands ship, service boundaries and cloud topology. The build sequence runs contracts-first (freeze IDs, enums, schemas, receipts), then hardening the graph service as the only boundary, then data plane, identity chain, the command loop, orchestration, surfaces, the Sentinel (observe-only first), and finally proving federation with a second ecosystem. Release gates include: no protected object is ever retrieved-then-filtered; **secret exists end-to-end before code-gated content ships**; no non-Source message ever becomes an instruction.

---

*v1.0 baseline, derived from Kiduna Kit v1.1 (spec v5.2 + Design R6). The [full document](downloads/Kiduna-Protocol-and-Stack-Architecture-v1.0.pdf) is the engineering reference; [Kiduna-Architecture](kiduna-architecture.html) remains the earlier detailed draft. Full history: [versions](versions/index.html).*
