The Protocol and the Stack

Architecture

Six layers, one rule: the graph service is the sole policy and command boundary. The intelligence proposes; deterministic code authorizes and commits. Everything else follows.

← The Kidunaverse — home Surfaces Orchestration Foundation Protocol Organizations Actions Roles Sentinel Legal Institutions Integrations
No prompt, persona, adapter, or integration can authorize itself. Permission is checked in one place, on every read, write, and tool call — and that place cannot be sweet-talked.

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 is the engineering reference; Kiduna-Architecture remains the earlier detailed draft. Full history: versions.