# Architecture

**The complete architecture, and how to hold it in your head · updated 2026-07-11**

**The vocabulary comes first: [The Core Taxonomy](taxonomy.html)** — the primary elements rebuilt 2026-07-17 (Principals, privacy-for-a-principal, the three engines + Artifacts, Abilities, trust default-low, deterministic Actions, roles, Compute with the Agency Premium). Read it before anything else on this page; where older pages disagree, the taxonomy wins. **The operating graph is specified here: [Kinship Graph Architecture v1.1](kinship-graph-architecture-v1.1.html)** ([PDF](downloads/Kinship-Graph-Architecture-v1.1.pdf)) — ratified 2026-07-14 (v1.1: the Persona · Visitor · Guest · Member vocabulary, the invitation lifecycle, twelve owner ratifications); Personas, Allies, Organizations, and Actions at the center; the Graph Command Service as the one deterministic boundary; Forums replacing Markets; Actions as a subgraph; one PostgreSQL transaction boundary; the August 10, 2026 build target. It replaces the earlier [Kinship Graph Workflow](kinship-graph-flow.html) and closes its [canon gaps](kinship-graph-gaps.html) — both preserved as history. **The technical white paper is here: [Kiduna: A New Architecture for the Agentic Internet (White Paper v0.1)](kiduna-new-architecture-agentic-internet-white-paper-v0.1.html)** — the argument and the design, whole. **The complete architecture is here: [Kiduna: A New Architecture for the Agentic Internet — Product & Engineering Specification v0.1](kiduna-agentic-internet-spec-v0.1.html).** It is the spec of record for the build — executive decisions, the products and surfaces, the domain model, creating the first Ecosystem, Allies and Actors and the first cast, the creation system, the Field and contextual HUD, Studio, Live, protocol and system architecture, trust/privacy/safety/custody, the development plan, acceptance and operations, and the canon objections with owner decisions. Read it front to back if you're building.

**Delta of 2026-07-14** (recorded in the [canon delta](skill-updates/cofounder-canon-2026-07-14.md), folds into the spec next revision): the Genesis bootstrap order — Genesis Ecosystem → Genesis Ally **Ki** ("Kinship Intelligence"; everyone's first conversation, effectively the initial interface) → the **Mage** account → Genesis Codes; **kiduna.ai** as the authoritative registration/wallet/launchpad home (third key share lives there; API moves to **api.kiduna.ai**); member-facing trust grammar — trust **High/Medium/Low** per Relationship side, authority = registered-with-whom (DUNA registry · KYC · DNS TXT · AT Protocol DID), privacy = the four levels; person-specific single-use 15-minute invitation codes, generalized codes default-untrusted, and the zero-spam law (the system never contacts the unregistered); the Allow-once/Allow-every-time permission grammar; the outward stack on [Integrations §8](integrations.html).

What follows on this page is the short version — the shape of the thing so anyone joining can hold it before diving in. Earlier reference: the [Protocol + Stack Architecture v1.0 (PDF)](downloads/Kiduna-Protocol-and-Stack-Architecture-v1.0.pdf). The spec tracks behind everything: [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.

---

*2026-07-11: the complete architecture installed — [the Agentic Internet Specification v0.1](kiduna-agentic-internet-spec-v0.1.html), the spec of record. Earlier references preserved: the [Protocol + Stack v1.0 PDF](downloads/Kiduna-Protocol-and-Stack-Architecture-v1.0.pdf) and [Kiduna-Architecture](kiduna-architecture.html). Full history: [versions](versions/index.html).*
