Kiduna
Technical White Paper · Version 0.1

# Kiduna: A New Architecture for the Agentic Internet

A graph-native, protocol-governed system for human-directed agents, working organizations, and a federated Internet of verifiable action.

Published 12 July 2026 Status Architecture proposal Audience Technical and product leaders

## Abstract

The current Internet is application-centric: people authenticate into isolated systems and operate interfaces. Agentic software reverses that relationship. It can interpret intent and act continuously across services, but it exposes unresolved questions: whose instructions bind, what information an agent may reach, which organization bears responsibility, how consequences can be inspected, and how independently operated systems can cooperate without a central platform. Kiduna proposes an agency layer for the Internet. Each Member is the Source of a personal Ally. Functional Actors perform bounded work but never inherit Member sovereignty. A deterministic graph command service—not a language model, prompt, client, or integration—authorizes every protected read, tool call, and state change. Consequential actions execute as named commands and produce durable Records and machine-derived receipts. The Field renders each Member’s current permission-filtered subgraph across Kiduna Live and Studio. Independently operated Ecosystems interoperate through the Kinship Agency Protocol (KAP), while signed Genesis Profiles and peer-spawn Codes make the Network reproducible without making a parent Ecosystem sovereign over its descendants.

Status. This paper presents a coherent implementation profile derived from the Kiduna Kit dated 11 July 2026 and the companion architecture specification.[13] It identifies several decisions as proposals rather than settled protocol. It is a basis for engineering, review, and iteration—not a claim that every legal, economic, or standards question is complete.
01 · The problem

## The problem changes when software can act

The Web was designed to publish documents. Platforms were designed to operate accounts. The agentic Internet must support delegated action—and delegated action changes what the infrastructure has to know.

A document needs an address. An account needs authentication. An agent needs much more: a principal it represents, context it may use, capabilities it may exercise, rules it must obey, and a durable account of what happened. If any of those are left implicit, the system eventually falls back to the prompt: a block of probabilistic text is asked both to decide what should happen and to decide whether it is allowed to happen.

That is not an adequate foundation for agents that send messages, change records, operate tools, coordinate teams, move value, or act across organizational boundaries. The more capable the model becomes, the more important it is that authority live somewhere the model cannot rewrite.

#### Document Internet

Primary unit: a page
Core primitive: URL
Main question: where is it?

#### Platform Internet

Primary unit: an account
Core primitive: API + login
Main question: who may use it?

#### Agentic Internet

Primary unit: delegated action
Core primitive: authority + record
Main question: who may cause what, for whom?

Figure 1Each Internet era adds a new kind of consequence. Agentic systems require an explicit substrate for representation, authority, context, and accountability.

### Six failures in the current pattern

#### Authority is prompt-shaped

The same model that interprets a request is often trusted to decide whether it should execute it.

#### Context is copied and drifts

Each bot, workspace, and application keeps its own partial memory, permissions, and version of the person.

#### Tools become shadow principals

Integrations acquire broad credentials and ambient access without a coherent model of standing or purpose.

#### Provenance falls off

Machine output is copied into human work until authorship, source material, and authorization can no longer be reconstructed.

#### Interfaces expose software structure

People navigate menus, files, inboxes, and dashboards because deterministic systems require them to operate the machinery directly.

#### Federation stops at identity

Open protocols can move messages or public data, but agentic work also needs portable capability, permission, receipt, and organizational context.

What capable agents encounter
Models and tools reasoning, generation, code, APIs, local systems
Application silos separate accounts, permissions, memories, logs
Human and institutional reality relationships, obligations, roles, law, money, trust
Missing substrate representation · authority · bounded context · receipts
Kiduna’s architectural answer
One policy and command boundary probabilistic systems propose; deterministic code authorizes
Typed institutional graph people, agents, work, relationships, policies, and provenance
KAP federation portable identity, capabilities, commands, records, and routes
The Field the authorized graph rendered as place, conversation, document, or action
Figure 2Kiduna is not a new model or another agent framework. It is the institutional and protocol layer between intelligent software and consequential action.
02 · First principles

## Requirements derived from the problem

A sound agentic architecture begins by separating intelligence from authority, then makes every other design follow from that separation.

Kiduna’s requirements are expressed as invariants. They are deliberately stronger than UI conventions or prompt instructions: implementations must preserve them across clients, models, integrations, organizations, and federated servers.

Invariant must hold across conforming implementations Proposed v0 recommended initial mechanism Open requires ratification or evidence
One policy boundary Every protected read, write, tool call, vote, payment instruction, and organizational act is authorized by the graph command service.
Source-only instruction A personal Ally takes binding instruction only from the authenticated Member it represents. Everyone else contributes context or a grant-bounded request.
Context is shared; authority is not Facts about a subject are stored once with provenance and scope. Personas receive filtered views, never copied authority.
Vectors are meaning, never permission Semantic search may propose relevant material. Only graph policy determines whether a caller may traverse to or use it.
Named commands, not raw mutation Every state change is a typed domain verb with explicit preconditions, effects, authority class, and error behavior.
Receipts cannot lie The human sentence is generated from the exact parameters that execute. A command without an honest renderer exposes its raw name.
Minimal public chain Only independently traceable identity and settlement roots belong on-chain. Conversation, private context, Projects, and most Records remain off-chain.
Registration is not trust A registered resource is traceable to an issuer. It is not thereby safe, true, or authorized.
Simulation is structurally separate A sim-flagged environment cannot resolve production wallet, grant, or settlement capabilities—not merely by policy, but by construction.
Integrations are tools An integration receives bounded capabilities. It never becomes a voting member, a sovereign party, or a self-expanding authority.

> Intelligence proposes. Deterministic code authorizes and commits. The Record preserves what happened.

These constraints are not meant to make agents passive. They make agents composable. Once an agent can be ambitious inside a hard scope, the system can safely give it more context, more tools, and longer-running work without confusing competence with legitimacy.

### What Kiduna is not trying to be

Not one global private database or one omniscient agent.
Not a claim that deterministic authorization makes model output true or safe.
Not a blockchain replica of chat, Projects, grants, or personal context.
Not a mandatory three-dimensional interface or a rendering mandate for third-party clients.
Not a replacement for payment, legal, identity, or public-registry systems.
Not a token economy, autonomous government, or machine personhood model for v0.
03 · Architecture overview

## The architecture in one view

Kiduna is a federated agentic system with one shared policy model. Every surface and agent relies on the same typed objects, commands, access rules, and Records.

Member surfaces Kiduna Live · Kiduna Studio · Account & Registry · Express · third-party clients `render + intent + signatures`
KAP edge Authentication · capability exchange · named requests · federation envelopes · rate and version controls `client ↔ server ↔ server`
Orchestration Ally routing · context assembly · candidate ACTIONS · Actor workflows · model and Tool calls `may propose, never authorize`
Graph command service Identity · reachable subgraph · access · grants · roles · policies · conflicts · commands · Records · receipts `sole policy boundary`
Data plane Typed graph · pgvector candidates · current projections · immutable Records · artifacts · outbox · external-operation state `PostgreSQL + object storage`
Protocol adapters DIDs and keys · registry · legal identity · wallets · governance · Solana and payment rails where required `independent proofs`
Operations Key custody · traces · backups · reconciliation · privacy audit · projection rebuild · conformance `no hidden authority path`
Figure 3The architecture’s defining seam is the graph command service. Clients, models, and integrations cannot authorize themselves, and no first-party path receives special treatment.

The implementation can begin as a modular monolith plus isolated workers. That is an operational choice, not an architectural compromise. What must remain singular is the command contract: every consequential operation resolves through the same deterministic boundary and produces the same form of evidence.

### Three different forms of state

#### Current graph state

The latest authorized projection: who is related to whom, what is active, which grants and policies apply, and where an object is currently hosted.

#### Semantic memory

Permission-scoped vectors and text help agents find meaning. They are candidates for context, not a parallel truth or authorization store.

#### Immutable Records

What happened, under which authority, from which sources, with which outcome. Corrections supersede Records; they do not rewrite history.

Implementation profile

For the first release, the architecture recommends explicit typed node and edge tables in PostgreSQL, pgvector for semantic candidates, and a graph-service API that hides the storage engine. Apache AGE can be adopted after real authorization traversals are benchmarked.[8][9]

04 · Agency model

## Agency without sovereignty

Kiduna separates the agent that represents a person from agents that perform functions. This keeps delegation legible even as the number and variety of automated workers grows.

Member human principal
and Source
binding instruction
Personal Ally represents one Member
across contexts
proposes answers
and ACTIONS
Graph command service re-resolves identity, scope, grants, role, policy, state, and conflicts for every act
Actors Organization- or Project-owned functions with explicit manifests, budgets, tools, commands, and stop conditions.
Tools External capabilities under grants. They supply reach, not standing.
Figure 4The Ally may be persuasive and the Actor may be capable, but neither carries sovereign authority. The graph service resolves what the authenticated principal may cause in the current context.

### The two agent families

Allies represent Members. A personal Ally is instructed by exactly one Source, maintains a stable relationship and voice, and works across organizations without merging their secrets or authority. “One Ally” means one member-facing relationship—not one undifferentiated prompt, credential store, or security context.

Actors perform functions. A Profiler prepares a consent-bounded invitation briefing. A Project Steward explains work state and pending ACTIONS. A Package Courier dispatches and returns bounded work. A Registrar collects legal-registry evidence. An Actor has a versioned manifest, an accountable owner, an allowlist of reads, Tools and commands, a budget, an escalation path, and an explicit end condition.

Implementation workers—queue consumers, embedders, reconcilers, malware scanners—are not a third agent family. They are deterministic services. They do not need personalities or social standing merely because they perform background work.

### Ki and the Genesis boundary

Ki is called the Genesis Ally in the experience: the first conversational presence in a new Ecosystem and the template from which personal Allies begin. Before a first Member exists, however, Ki cannot literally represent a Member. The implementation therefore treats Ki as a non-sovereign Genesis Host Actor plus an Ally template. This preserves the product relationship without weakening the invariant that a personal Ally represents a human Source.

Why the distinction matters

If “Ally” can quietly mean a system administrator, an organizational bot, a public concierge, and a personal representative, then the most important authority rule becomes ambiguous. The schema should be stricter than the product metaphor.

05 · Institutional substrate

## The graph is a model of standing, not a picture of storage

Agentic work is relational. An authorization question rarely concerns one row in isolation; it concerns a person, a role, an Organization, a Project, a grant, a policy, an object version, and a requested consequence at the same time.

Kiduna therefore defines its authoritative domain as a typed object graph. The graph describes identities, agency, containers, work, governance, evidence, and federation. Its purpose is not to insist on a particular graph database. Its purpose is to make relationships first-class and to force every consequential decision to name the relationships on which it depends.

Four distinctions prevent common category errors:

- Account ≠ Member ≠ membership. An Account provides authentication, custody, recovery, and terms. A Member is a human principal. Organization membership is an explicit, independently evidenced agreement.
- Ally ≠ Actor ≠ worker. An Ally represents one Member; an Actor performs a declared function; a worker is implementation infrastructure and represents no one.
- Intent ≠ command ≠ settlement. Language expresses desire, a command authorizes a local transition, and an external system later reports its own outcome.
- Object ≠ address ≠ Scene. A stable graph object can have a Field address and many renderings. Moving or restyling a Scene does not change the object’s authority.

Identity & agency Account authenticates Member Member is SOURCE_OF Ally Actor is INSTANCE_OF ActorType Relationship and Grant are first-class objects
Federation Network · Ecosystem Object CURRENT_HOME Ecosystem signed KAP envelope · controller keys
Authority resolution principal + Source + role + grant + policy + capability + purpose + object version + conflict + requested command
every protected traversal and mutation crosses this evaluation
Work Organization HAS_PROJECT Project Project HAS_SCENE Scene Package RETURNS draft Record
Governance Organization GOVERNED_BY Forum Proposal · Policy · Role ACTION RESOLVES_VIA CommandDefinition
Evidence Record DERIVED_FROM Item or Package Record CORRECTS or SUPERSEDES Record ExternalOperation settles separately
Figure 5Containment locates work and policy; it does not confer ownership of a Member. Authority is recomputed from typed identities and relationships for the exact command being requested.

### Minimum object contract

Every addressable object has a protocol identifier, kind, controller, origin, current authoritative home, access label, lifecycle state, optimistic version, provenance, and validity interval. Domain types add their own required fields and edges. This common envelope makes it possible for Live, Studio, Actors, and remote Ecosystems to reason about the same object without agreeing on its visual representation.

Relationships that carry authority are objects, not informal labels on a line. A Grant names an issuer, grantee, scope, allowed commands, purpose, expiry, delegation rule, and revocation state. A Role names the container and policy under which it is meaningful. A Relationship can describe social standing without automatically granting access. The graph can therefore answer both “how are these principals related?” and the stricter question “what can this relationship authorize here?”

### Access is resolved before retrieval

Kiduna exposes four member-facing discoverability labels: public, private, secret, and personal. Public objects may be discoverable subject to minimization and controller policy. Private objects are visible to explicit principals or roles. Secret objects are not enumerable before authorization. Personal objects are Source-bound and are not shareable through an ordinary grant.

These labels are intentionally incomplete. Effective authorization also considers controller, capability, purpose, field, legal class, retention, residency, role, lifecycle, conflict, and explicit denial. Policy composes by narrowing:

effective authority = hard invariants ∩ network policy ∩ ecosystem policy ∩ organization policy ∩ scoped grants ∩ human grants − explicit denials

A lower layer may remove authority; it cannot create authority that an upper layer forbids. A model prompt cannot widen the intersection. Neither can a cached object, vector result, signed URL, federation route, count endpoint, error message, or administrative shortcut.

### Semantic search follows authorization

Embeddings help an Ally or Actor find potentially relevant material. They do not prove the material is visible, current, reliable, or appropriate for the present purpose. The safe order is: resolve the caller and context; compute an authorized scope; search candidates only within that scope; recheck each returned object and field; then assemble cited context. “Retrieve everything and filter the answer” is specifically forbidden because retrieval itself can disclose existence, shape model behavior, and leak through caches or timing.

This is also why the graph, not the vector index, remains the authority model. Vectors encode similarity. Kiduna needs directionality, revocation, scope, version, and institutional standing—properties similarity does not supply.

### Current state, Records, and internal events

The current graph is the operational projection used to answer present-tense questions. A Record is member-visible evidence of an accepted fact, command, correction, return, or settlement. An internal event and outbox entry exist to drive asynchronous work and rebuild explicitly designated projections; they are not automatically public and should not be confused with the member-facing Record.

“Append-only” applies to the evidence relationship: corrections append and supersede rather than silently overwriting history. It does not mean all plaintext must be retained forever. Redaction, expiry, legal hold, tombstones, and cryptographic erasure require a retention policy that preserves the integrity of what may lawfully remain without promising an impossible universal memory.

Architecture versus engine

A conventional relational database can implement this logical graph. The architectural claim is the typed, permissioned relationship model and the sole command boundary—not a particular storage vendor. Storage choices remain replaceable behind stable graph and command contracts.

06 · Experience model

## The Field is the authorized graph made perceptible

People should not have to operate the topology of the software in order to understand their work. The Field turns the Member’s current permission-filtered world into a coherent place for attention and action.

The Field is both an address space and an interaction shell. It is not necessarily scenery, a game world, or a permanent three-dimensional room. A Scene is one bounded projection of a Project or context. The contextual HUD may be ambient, conversational, documentary, tabular, or fully opaque when the work calls for focused reading or editing.

Field(principal, context, time) = Render(AuthorizedReachableSubgraph(principal, context, time), device, preferences)

This definition creates a useful constraint: device and fidelity can change presentation, but never identity, access, capability, or consequence. The same Project opened in Studio, Live, a screen-reader transcript, or a third-party KAP client refers to the same protocol object and the same current authority. KAP requires semantic fidelity, not visual imitation.

Authorized reachable subgraph stable IDs · provenance · ACTIONS · grants · versions · consequences
semantic reading order
Field / Scene spatial anchors, presence, objects, relationships
Conversation Ally dialogue with cited objects and command previews
Document / diff opaque focus for content, change, and acceptance
Table / transcript linear semantic parity for dense work and accessibility
Figure 6One object model supports several projections. The Field is not a second database and visual position is never a capability.

### Four HUD postures

Ambient keeps the Scene visible while showing only the next relevant consequence. Conversational centers the Ally and cited objects while preserving context. Opaque focus temporarily lets a document, diff, table, or command preview occupy the surface. Wide focus combines the work product with provenance, participants, ACTIONS, and status. These are postures of one shell, not separate applications.

The architecture ranks ACTIONS by consequence, urgency, dependency, and current ability to respond. It must not reduce meaningful work to badge counts or force the Member to remember where an object was placed. Every Scene has a stable semantic reading order and a complete nonspatial route. Keyboard, switch, screen-reader, reduced-motion, and high-contrast presentations must preserve the same actions and consequence previews.

### How the Field expands

A new Project begins with a stable Field address and an anchor. As Items, participants, Tools, ACTIONS, and Actors enter scope, the system can form a workbench cluster and then a bounded Scene. Generated dressing may improve orientation, but the Scene can always collapse back to a transcript or compact list without losing identity or capability. Archiving preserves the semantic structure and Records even if the visual dressing is discarded.

The expansion rule is therefore not “make a larger world.” It is “materialize only the structure that helps the Member understand the current work.” When focus becomes a long diff, the Field should disappear behind the diff. When the important fact is a relationship between Projects, a map may be best. When the Member is walking, Live may reduce the same state to one spoken ACTION and its consequence.

07 · Work and institutions

## Organizations, Projects, Packages, ACTIONS, and Records

Kiduna represents institutional work as a traceable progression from shared intent to bounded execution to accepted evidence.

An Organization is the protocol-neutral container for members, governance, policies, treasury references, Actors, and Projects. It may be linked to jurisdiction-specific legal evidence. A West Virginia decentralized unincorporated nonprofit association is the proposed first legal-form adapter, not the universal meaning of Organization. Current West Virginia law defines a DUNA around mutual consent and a threshold of at least one hundred members, which makes legal status a verified lifecycle condition rather than a label an interface may invent.[11][12]

A Project is a durable unit of work. A Scene is one projection of it. An Item is addressable content or material. A Tool is an external capability under a grant. A Package is bounded correspondence with a manifest, destination, declared operations, and inspectable return. An ACTION is a consequence-bearing request awaiting a person or Actor. A Record is durable evidence that something was proposed, accepted, corrected, executed, returned, or settled.

1
Create Project role and policy resolve
2
Compose Package manifest, sources, scope
3
Dispatch bounded Actor or Tool
4
Quarantine return scan and manifest diff
5
Human inspection drafts and consequences
6
Accept Record authoritative provenance
Figure 7Returned model or Tool output remains draft. Authority enters only when a permitted principal accepts selected work through a named command.

### A running example

Mara asks her Ally to create a Project called “Community Solar Filing” inside an Organization. The Ally interprets the request and presents the proposed Project name, Organization, initial members, visibility, and consequence. The command service confirms Mara’s current role and the Organization’s Project policy, then creates the Project and its initial Scene in one local transaction. A Record captures the authority and exact parameters.

Mara next asks a Configuration Drafter to prepare a public-data integration. The system creates a Package containing the selected files, source references, expected outputs, tool allowlist, budget, and return rules. A Package Courier sends it to a coding agent. The external agent receives no ambient filesystem, wallet, Member identity, or Organization credential—only the manifest and explicitly supplied material.

On return, the Package enters quarantine. Deterministic workers check hashes, file types, malware signals, unexpected files, and the manifest diff. The coding agent’s result appears in the Field as draft Records with provenance. Mara can inspect the diff, reject it, request revision, or accept selected artifacts. Acceptance creates the authoritative Record; the model’s confidence never does.

### ACTION as an accountable request

An ACTION is not a chat message and not the command itself. It is a durable object naming a target, addressee, issuer, need, reason, consequence, authority class, allowed responses, relevant object version, expiry, and the command that would resolve it. This makes work queryable across surfaces and time. Deferring an ACTION changes its attention state; it does not silently approve the underlying consequence.

The distinction matters most when an Actor operates asynchronously. An Actor may discover that a registry record is stale or that a Package exceeded budget. It can raise an ACTION with evidence and a proposed response. It cannot decide that the Organization has accepted the consequence merely because no one replied.

### The initial functional cast

Actor | Function | Important boundary
--- | --- | ---
Configuration Drafter | Drafts versioned configuration and integration manifests from Member intent. | Cannot register, grant, or connect the integration.
Registrar | Collects and verifies external registration evidence through adapters. | Registration establishes provenance, not trust or authority.
Project Steward | Explains Project state, dependencies, Records, and pending ACTIONS. | Cannot accept work or widen roles.
Field Composer | Proposes Scene anchors, layouts, reading order, and accessible projections. | Presentation cannot change access or capability.
Package Courier | Dispatches manifested work and manages return state. | No ambient remote-machine access in v0.
Ingestion Actor | Proposes Items, provenance edges, and semantic candidates from approved sources. | All returned material is quarantined and permission-checked.
Sentinel | Observes agreed signals and raises evidence-backed ACTIONS. | Proposed v0 is observe-only, consented, and without person scoring.

### Creating an Organization from within

A founding group first creates an Alliance or formation plan, agrees governing principles, records consent, selects a legal-form adapter, and collects required evidence. Only after an adapter verifies the external status does the command service create or transition the protocol-neutral Organization into its registered state. Membership, role appointment, wallet authorization, governance participation, and Compute purchase remain separate acts. An Account login never implies any of them.

This pattern is recursive. A Member can create a Project; a Project can host work that prepares an Alliance; an Alliance can produce a verified Organization; an Organization can issue an invitation; the next Member can create the next Project. The architecture is successful only if each step occurs through Kiduna’s own authority and evidence contracts rather than through hidden operator edits.

08 · Deterministic consequence

## From intent to accountable consequence

The command lifecycle is the technical center of Kiduna. Models can compose a preview; they cannot make the preview true.

Every consequential act follows the same lifecycle, whether it begins with speech in Live, a click in Studio, an Actor trigger, or a signed request from a peer Ecosystem. The pathway is deliberately narrow:

Intent language, UI act, trigger, signed request
Resolve principal, Source, context, home, IDs, versions
Authorize access, roles, grants, policy, conflicts
Validate schema, preconditions, budget, simulation
Execute atomic local state transition
Record evidence, event, outbox, usage
Render receipt and Field projection
Figure 8Everything above the boundary is a proposal. Only the deterministic service resolves authority and commits a named transition against current state.

### Named commands

A command is a versioned domain verb such as `project.create`, `package.dispatch`, `record.accept`, or `grant.revoke`. Its definition identifies typed parameters, authority class, preconditions, expected object versions, local effects, possible external operation, Record schema, receipt renderer, idempotency rules, and stable denial codes. Clients never receive generic graph create, update, delete, or unrestricted query interfaces.

This design makes the actual consequences reviewable. A Member can see that accepting a return will create two Records, supersede one draft, publish one public artifact, and consume a defined amount of service credit. The Ally may explain that preview in natural language, but the canonical preview is generated from the same command schema and resolved parameters that execution will use.

### Three classes of authority

Class | Authority source | Illustrative acts
--- | --- | ---
A · Source | The authenticated human acting through the personal Ally contract. | Personal Item, personal Code, one side of a Relationship grant, ACTION deferral.
B · Role or grant | A scoped role, capability, or grant evaluated under current container policy. | Project creation, Package dispatch, Tool connection, membership acts within policy.
C · Forum | An Organization’s valid governance outcome and execution policy. | Constitutional policy, treasury spend, Forum rules, dissolution, proposed Compute issuance.

The object’s domain does not determine the class by itself. `project.create` concerns an Organization, but it may be role-authorized until that Organization’s policy narrows it to Forum approval. Conversely, a personal visibility change remains Source-authorized even when the Item is shown inside an Organization Scene.

### Idempotency, concurrency, and honest failure

Every mutation carries an idempotency key and expected versions. Repeating the same key with the same payload returns the original status and Record. Reusing the key with a different payload is a hard conflict. If current state has changed, the service returns `state_changed` with a permission-filtered explanation and requires a fresh preview. This prevents retries, stale clients, duplicated callbacks, and model loops from repeating effects.

The local transaction updates current graph state, appends evidence, and writes the outbox atomically. Delivery to projectors, notifications, or external adapters is asynchronous and idempotent. A failed outbox worker does not make the commit disappear, and a successful local commit does not allow the interface to fabricate external completion.

Local command committed authority and parameters are recorded atomically
↘
authorized operation may begin
submitted provider reference exists
awaiting external outcome remains uncertain
settled / failed later evidence appends a Record
Figure 9Real-world systems cannot share one database transaction. Kiduna records authorization, submission, and settlement as separate facts in a recoverable saga.

### What a receipt proves

A receipt is a deterministic member-facing rendering, and where required a signed subset, of the committed Record. It proves what Kiduna resolved, authorized, and recorded under a particular software and policy version. It does not prove that generated prose is factually correct, that a registry’s data is current, or that an external payment or filing completed. Those claims require their own evidence and settlement state.

Receipt text is generated from the parameters that actually executed, rather than authored as an independent narrative. The canonical command and Record remain authoritative because renderer bugs, localization errors, or version skew are still possible. Conformance tests must round-trip receipt claims to their source parameters.

> The model may compose the command preview; it cannot make the preview true.

09 · Origin

## Bootstrapping the first Ecosystem

The beginning of an authority system cannot be an ordinary administrator signup. Genesis is a human-controlled key, policy, and evidence ceremony that creates the first legitimate place from which later acts can be evaluated.

A Kiduna Server is the deployable software distribution. An Ecosystem is the logical administrative, security, data, and federation domain instantiated by that software; it may span replicas, workers, stores, and regions. The Network is the live federation of compatible Ecosystems and shared public protocol state—not a global private database.

The first installation has no prior Kiduna authority to appeal to. It therefore begins from a signed Genesis Profile: a declaration of the Ecosystem identifier, public endpoints, protocol versions, command and policy digests, key references, recovery policy, legal/operator binding, registry adapters, and initial configuration. The profile contains no raw secret. It is reproducible in the sense that public state derives from the same declared profile and identity, not in the impossible sense that fresh keys, timestamps, and external confirmations are byte-identical.

Installer & humans
preflight approve ceremony verify profile digest
Custody
recovery root Mage key steward shares rotation policy
Graph bootstrap
migrations typed catalogs commands + policies Ecosystem + Mage Ki + initial Actors
Registry & KAP
profile attestation DID / key discovery KAP endpoints
First authority
Organization evidence steward claim Account + Member personal Ally Genesis seal
Figure 10Genesis is deterministic where it must be and human-controlled where authority begins. No model generates keys, authorizes roots, migrates schemas, publishes the attestation, or seals the Ecosystem.

### The ceremony in operational order

1. Preflight. Verify binaries, clocks, stores, endpoints, providers, chain/registry configuration, and the exact source baseline.
2. Generate independent key classes. Create the Ecosystem recovery root, Mage service key, federation keys, signing keys, and human steward shares. Record their custody and rotation policy.
3. Sign the Genesis Profile. Human stewards verify its canonical digest and produce the required threshold signatures.
4. Seed the constitutional core. Apply resumable migrations; install object, edge, command, policy, error, Record, and receipt registries.
5. Create Mage. Instantiate a noninteractive service principal limited to control-plane duties such as routes, quotas, schema lifecycle, backups, and Ecosystem recovery.
6. Instantiate Ki. Create the Genesis Host Actor and the versioned Ally template. Register the minimum initial Actors, paused until capability tests pass.
7. Publish profile attestation. Announce the Ecosystem’s public identity, protocol compatibility, KAP endpoints, and key discovery. After this point a failed run resumes toward the same identity.
8. Validate initial Organization evidence. Use the selected legal-form adapter without allowing registration to imply trust or authority.
9. Issue a proof-bound steward claim. The claim is short-lived, recipient-bound, single-use, revocable, and replay-safe.
10. Create first human authority. Establish the Account, Member, passkey, Organization membership/role edges, and personal Ally as separate commands.
11. Seal Genesis. Append the final Genesis Record, close bootstrap-only capabilities, and require normal command paths thereafter.

### Profile attestation versus Genesis seal

Two milestones resolve an otherwise dangerous ambiguity. Profile attestation publishes the infrastructure identity and makes recovery continuity externally observable. Before it, a failed installation can discard partial state and start again. After it, a rerun must reuse the same profile digest and Ecosystem identity. Genesis seal closes the completed bootstrap after the first human authority and personal Ally exist.

A bootstrap ledger records each completed step and its digest so reruns are resumable and idempotent. Partial creation cannot silently produce a second public Ecosystem identity. Break-glass recovery requires a separately logged human threshold ceremony; it is not a privileged Mage API.

### Four independent roots

Genesis does not place every future participant beneath one administrator. Kiduna composes four roots that remain independent:

Network root protocol and registry configuration; upgrade governance
Ecosystem root Genesis Profile, Mage, stewards, hosting and recovery policy
Command evaluation accepts only the proofs relevant to the requested command; applies narrowing policy and explicit denials
no root may impersonate or own another
Member root controller keys, passkeys, guardians, and Source authority
Organization root legal evidence, governing principles, Forum policy, treasury authority
Figure 11Mage administers an Ecosystem’s services; it is not a Member, cannot vote, and cannot use Member capabilities. Member and Mage recovery are different ceremonies.

### Ki, Mage, and the first Member

Mage is intentionally nonconversational. It can maintain hosting, routes, quotas, schemas, service health, backup, and Ecosystem recovery within explicit policy. It must not become a super-admin that can impersonate Members, vote in Organizations, use personal grants, or browse personal content through normal application capabilities. Claims about protection from the human operator still depend on actual encryption and custody design and must be tested rather than assumed.

Ki provides the first conversational experience without becoming the source of authority. It can explain the ceremony, draft configurations, prepare ACTIONS, show evidence, and instantiate a personal Ally from the approved template. The first human steward supplies the binding instruction and approvals. Once Genesis is sealed, Ki continues as a bounded host function, not a hidden root Member.

### Recursive Ecosystem creation

A sealed Ecosystem may issue a time-limited spawn Code describing compatibility and lineage for a proposed peer. The recipient installation generates independent custody, keys, stewards, profile, and local authority. When both sides complete signed acceptance, the new Ecosystem becomes a peer. The Code proves provenance and a form of endorsement; it does not grant the parent administrative access, automatic trust, or transitive authority.

10 · Protocol and Network

## KAP and federated home authority

Federation is not the absence of authority. It is the disciplined placement of authority among independently operated domains.

The Kinship Agency Protocol (KAP) is the proposed versioned contract between clients and Ecosystems and among Ecosystems. It covers identity resolution, capability proof, named requests, Records, registration, revocation, receipts, migration, and federation. A chain program or registry is one adapter behind KAP, not the protocol itself.

KAP can reuse established mechanisms rather than inventing every cryptographic primitive. Decentralized Identifiers provide a model for identifiers, controllers, and verification methods.[2] JSON Web Tokens provide a compact claims format, while Demonstrating Proof of Possession can bind bearer-like authorization to a presenting key.[3][4] WebAuthn supplies phishing-resistant public-key authentication for Member Accounts.[5] These standards are ingredients; KAP still needs its own canonical serialization, domain semantics, version negotiation, denial taxonomy, revocation, replay controls, and conformance suite.

### One current home per mutable aggregate

Each mutable aggregate has one current authoritative home Ecosystem and one ordered authority stream. A Member can authenticate through any compatible ingress, but the object’s home resolves and commits the command. Public state may be replicated under controller policy. Protected state travels only under explicit grant. Caches and replicas never become co-writers merely because they hold a copy.

This choice intentionally centralizes the commit point for a given object while federating the system as a whole. It avoids a global private database and avoids pretending that conflicting sovereign writers can be made harmless by eventual consistency. Migration is a separately evidenced saga that changes controller and current-home attestations while preserving the stable protocol identifier.

Ecosystem A · ingress
Member session KAP edge local objects independent keys
not authoritative for Project P
signed request⇄signed receipt
Ecosystem B · current home
Project P command service Record + outbox independent keys
sole ordered writer for Project P
Ecosystem A may issue a spawn Code to Ecosystem C ⇢ lineage and compatibility, never a parent-control edge.
Figure 12Identity can enter anywhere, but mutable authority remains at the object’s current home. Cross-Ecosystem work uses signed requests and Records, not a distributed database transaction.

### The signed envelope

An illustrative federation envelope contains a message identifier, KAP version, sender Ecosystem DID, recipient, message type, resource identifier, issue and expiry times, nonce, body hash, signing-key identifier, and signature. The recipient verifies canonical bytes, current key status, replay state, audience, expiry, route, capability narrowing, and command support before considering the body. The same message identifier and body hash make retries idempotent.

A peer exchange produces evidence on both sides. The offering Ecosystem records what it requested and under which local authority. The accepting Ecosystem records what it accepted, rejected, or settled under its own policy. No peer can claim that a remote act completed merely because it sent a message.

### Partitions, migration, and conflict

During a partition, each Ecosystem may continue operations for aggregates for which it is authoritative and for which local policy permits offline progress. Remote operations remain pending. Clients can read verified snapshots and prepare drafts, but they cannot queue signatures, grants, money movement, registration, or authoritative acceptance for later blind replay.

If two hosts claim authority for the same aggregate, discovery data alone does not pick a winner. KAP needs a controller-signed migration chain, effective version, revocation state, and deterministic conflict procedure. Until resolved, consequential remote writes fail closed. Historical Records remain verifiable against the key state and software versions valid at their recorded time.

### Open protocol versus Network admission

An implementation can be open and KAP-compatible while a particular named Network remains permissioned for enrollment through spawn Codes or registry policy. These are different claims. KAP should be judged as a protocol only when it has a published schema, version policy, error model, conformance suite, and at least one independent implementation beyond the first Kiduna Server.

Existing federated systems demonstrate useful patterns. AT Protocol repositories and synchronization separate signed repository state from service-specific indexing and transport.[6][7] Model Context Protocol separates host, client, and server roles for tool and context exchange.[1] Kiduna’s additional burden is institutional: representation, directional grants, organizational authority, commands, and durable evidence of consequence.

### Minimal public anchoring

Only accountability roots that benefit from independent verification should be public or on-chain: selected network configuration, controller and key references, verified legal bindings, governance outcomes, public hash anchors, and external settlement references. Private chat, context, Relationships, grants, Projects, policies, prompts, Scene layouts, and personal artifacts remain off-chain and permissioned. Solana programs can provide verifiable program and account behavior for an adapter, but they do not replace KAP policy or the private graph.[10]

11 · Security and privacy

## Bounded agency under hostile conditions

Kiduna assumes that models can be manipulated, tools can fail, peers can equivocate, operators can make mistakes, keys can be compromised, and external systems can return ambiguous outcomes.

The system does not try to make probabilistic components trustworthy by declaration. It reduces what they can reach, makes consequential transitions deterministic, separates key classes and contexts, records evidence, and represents uncertainty as state rather than as confident prose.

Prompt and context injection

Non-Source input is context only; it cannot widen graph traversal, tool scope, or command authority.

Confused deputy

One member-facing Ally uses isolated Organization, Project, credential, provider, budget, conflict, and retention contexts.

Secret enumeration

Search, counts, embeddings, errors, caches, timing, object storage, and federation are tested for existence leakage.

Overpowered Actors

Immutable manifests bound reads, Tools, commands, models, budgets, escalation, and stop conditions.

Replay and duplicate effect

Proof-bound Codes, nonces, idempotency keys, expected versions, expiry, reservation, and revocation fail closed.

Untrusted return

Packages return to quarantine for scanning, manifest diff, provenance checks, and human-authorized acceptance.

Fabricated completion

Pending, submitted, settled, failed, and reconciled states remain distinct throughout the UI and Record chain.

Administrative bypass

Mage, operations, migrations, backups, and projectors have no alternate Member-command path.

### Context isolation inside one Ally

“One Ally per Member” is a relationship invariant for v0, not a shared security context. The runtime creates isolated working contexts for Organizations, Projects, model providers, credentials, conflicts, budgets, and retention domains. An Ally can help Mara across two Organizations without presenting one Organization’s secret material to the other, without reusing its Tool credentials, and without carrying an instruction from one context into another.

Context assembly is a capability-scoped service call. The Ally receives the minimum authorized material needed for the current purpose, with object identifiers and citations. Model output is untrusted until parsed, validated, and, for consequence-bearing behavior, converted into a named command preview.

### Custody and key separation

Ecosystem recovery, Mage service operation, KAP federation, Code issuance, Member authentication, Organization governance, external wallets, and protocol-program upgrade are separate key classes. Compromise of one should be containable without granting another. Recovery rotates the affected class, publishes revocation, preserves historical verification, and requires the correct human threshold or principal ceremony.

WebAuthn passkeys are the proposed default for Member authentication because they use origin-bound public-key credentials rather than reusable passwords.[5] Authentication still does not grant Organization membership or command authority. Session and capability tokens are short-lived, audience-bound, proof-bound where feasible, and narrowed at every hop.

### Privacy posture

The graph can enforce that Mage has no ordinary application capability to read personal material, but that alone does not prove confidentiality from the infrastructure operator. The threat model must document where plaintext exists, which model providers receive it, what metadata is visible, how keys are held, and which operational emergencies permit access. Member-controlled encryption should be used where computation and recovery requirements allow it; claims stronger than the implemented custody model should not be made.

A proposed Profiler may prepare invitation context only with notice, source and purpose disclosure, recipient binding, expiry, correction, objection, deletion, limits on sensitive inference, and bystander rules. It must not create a permanent pre-account dossier. A proposed Sentinel should launch observe-only and consented, without person scores or autonomous intervention.

### Failure is explicit state

Failure | Required behavior
--- | ---
Duplicate command | Return the prior result for the same key and payload; never repeat the effect.
Stale state | Reject, explain only visible change, and require a fresh consequence preview.
Outbox failure | Keep the committed local transition; retry delivery idempotently.
Model/provider failure | Fall back to deterministic views and drafts; never fabricate completion or cross a provider boundary silently.
External ambiguity | Remain submitted or awaiting external; reconcile from a deterministic provider reference.
Peer partition | Allow only local-authoritative work; keep cross-peer work pending.
Projection loss | Rebuild derived views from explicitly designated canonical state and evidence sources.
Key compromise | Freeze and rotate the affected key class without conflating Member, Mage, Organization, Code, or protocol recovery.
Legal-status change | Mark evidence stale, preserve history, and block only commands whose preconditions require current status.

### Security properties are tests, not slogans

A conforming release must demonstrate negative properties: non-Source text cannot become an Ally instruction; prompt content cannot widen reachability or Tool scope; secret existence cannot be learned through alternate paths; simulation capabilities cannot resolve onto production rails; Actors cannot alter their own manifests; offline clients cannot commit consequential acts; returned Packages remain drafts; receipts round-trip to executed parameters; and federation rejects replay, equivocation, and conflicting home claims.

Deterministic authorization does not eliminate manipulation, bad recommendations, social engineering, data poisoning, or confirmation fatigue. It constrains execution authority and leaves evidence for inspection and correction. That narrower claim is both more credible and more useful.

12 · Products and proof

## One semantic system across every surface

Kiduna’s products differ by attention, device, and responsibility. They do not fork the object model or create privileged authority paths.

Kiduna Live is the mobile participation surface for Members: conversation with the Ally, timely ACTIONS, lightweight Scene navigation, presence, capture, approvals, receipts, and safe offline reading. Kiduna Studio is the desktop creator and builder surface: Genesis, Organization and Project creation, graph inspection, Actor manifests, Tool connections, Packages, diffs, governance, access, custody, and conformance evidence.

Account & Registry handles authentication, recovery, custody choices, payment authorization, protocol registrations, and migration without conflating those functions with the person or their organizational memberships. Kiduna Express provides web provenance and a Member-authorized handoff into the Field. The Server, KAP, and Network are infrastructure products. Third-party clients may participate through KAP while preserving object, command, Record, and consequence semantics.

KIDUNA STUDIO Community Solar Filing · Project P-104
FIELD
Projects
Actors
Packages
Records
Access
Graph
Solar Filing same object P-104
Return #72 draft Records
1 manifest difference
ACTIONAccept selected configuration?
Creates 2 Records · supersedes 1 draft
KIDUNA LIVE P-104
Community Solar Filing

##### Your Package has returned.

Accept configuration?2 Records will become authoritative. One draft will be superseded.
Review Later
Figure 13Studio exposes construction and provenance; Live protects attention. Both show the same Project identifier, ACTION, consequence, versions, and eventual Record.

### A complete first-member path

1. Claim. The first steward opens Studio from the proof-bound Genesis claim, verifies the Ecosystem identity, creates an Account with passkey and recovery, and explicitly creates the Member principal.
2. Meet the Ally. Ki explains the Source contract, privacy boundaries, and current Organization role. The Member instantiates a personal Ally from the approved template and reviews its binding-instruction rule.
3. Enter the Field. The initial Scene shows only the Organization, the Member, their Ally, the Genesis evidence they may see, and the next valid ACTIONS. Nothing is inferred as consent.
4. Create real work. The Member asks the Ally to create a Project. Studio or Live shows the typed preview; the command service resolves the role and commits the Project and Scene.
5. Add bounded capability. In Studio, the Member drafts an Actor manifest or connects a Tool through a grant. The system shows exact reads, commands, provider, budget, expiry, and stop conditions.
6. Dispatch and inspect. A Package leaves with a manifest, returns to quarantine, and appears as drafts. The Member inspects provenance and a diff before accepting selected Records.
7. Invite the next Member. The Organization issues a recipient-bound invitation. Account creation, Member creation, Organization membership, role, and Ally creation remain distinct confirmations.
8. Participate daily. Live presents current work and consequence-ranked ACTIONS; Studio remains available for construction, audit, and complex acceptance.

The path intentionally proves that ordinary work can begin without revealing server internals. It also proves that the same work can be inspected deeply when the Member needs to understand authority, provenance, or change.

### Initial implementation shape

The recommended v0 is a modular monolith around the graph command service plus isolated workers. This keeps transactional authority legible while allowing model calls, embeddings, scanning, external operations, notifications, and projection work to fail or scale independently.

Clients and ingress Live · Studio · Account · Express KAP edge · sessions · signatures peer federation ingress
Modular constitutional core identity and reachability policy and grant evaluation named commands and Records PostgreSQL typed nodes/edges + pgvector artifact references + transactional outbox
Isolated workers and adapters models · context assembly · embeddings package scanner · projectors registry · DID · wallet · payment reconciliation · notification
Figure 14The v0 deployment favors one auditable transaction boundary and isolated failure domains. A later service split must preserve the same command contract.

Typed node and edge tables in PostgreSQL provide transactional consistency, familiar operations, and an explicit schema. pgvector supplies semantic candidate search inside authorized scopes.[8] Apache AGE remains an optional graph-query layer to evaluate after representative policy traversals are benchmarked.[9] Encrypted object storage holds large artifacts, but access always resolves through short-lived, scoped delivery rather than permanent public URLs.

### Create from Within

The implementation strategy is to build the smallest true system capable of creating the next legitimate participant, unit of work, and independent host from inside itself. This is a recursive core, not a disposable demo. Each slice must exercise identity, policy, command, Record, Field projection, and recovery together.

Constitutional core Source checks · permission-first reads · commands · Records
Genesis profile · custody · Mage · Ki · first Member
Real Project Scene · Package · quarantine · accepted Record
Next Member invitation · membership · role · personal Ally
Independent peer spawn · separate custody · KAP conformance
Figure 15The proof is recursive. Each stage must produce the authority and evidence needed to create the next stage without operator-only edits.

### Falsifiable v0 gates

The release should be judged by properties rather than screen count: no Source spoofing; authorization before retrieval; one command path for first- and third-party clients; exact receipt round-trip; inaccessible secret existence; package quarantine; safe offline refusal; accessible semantic parity; resumable Genesis; separate recovery roots; and two independently controlled Ecosystems completing signed KAP exchange without shared administration.

Operational targets for latency, availability, recovery time, staffing, and calendar remain hypotheses until measured. The architecture is credible only when conformance, negative security, accessibility, restore, compromise, and partition exercises make its claims reproducible.

13 · Objections and open work

## What the architecture claims—and what it does not

Kiduna is strongest when its trust boundaries are explicit and its unresolved questions are visible.

### Why not OAuth, existing applications, and a conventional database?

They remain useful ingredients. OAuth-style delegation can grant an application access to a resource; a relational database can store Kiduna’s graph; collaboration applications can render documents and workflows. The missing layer is a common institutional contract that joins representation, directionality, organizational policy, named consequences, durable evidence, and federation. Kiduna’s contribution is not the claim that every component must be new. It is the way their authority is composed and made inspectable.

### Does the graph command service recreate centralization?

For one mutable aggregate, it deliberately creates a single deterministic authority boundary. That is a consistency and accountability choice. The broader system is federated because different aggregates and Organizations may be authoritative in different independently controlled Ecosystems. Kiduna is not “authority-free”; it is designed to make authority bounded, attributable, migratable, and unable to hide inside a model or integration.

### Is KAP already an Internet protocol?

No. It is a proposed protocol architecture. It becomes credible as an interoperable protocol when canonical schemas, signature bytes, capability semantics, version negotiation, errors, revocation, replay handling, migration, conformance tests, and independent implementations exist. A first-party API with one server is not sufficient evidence.

### Why use a blockchain at all?

Only when independent public verification or settlement warrants it. A chain can anchor program identifiers, controller references, selected public digests, governance outcomes, or settlement references. It cannot establish that a resource is safe, a legal filing is valid, a model output is true, or a private grant should exist. Moving private institutional state on-chain would undermine the privacy and correction model rather than strengthen it.

### Does a signed Record establish truth?

It establishes what a particular Kiduna authority resolved, authorized, and recorded at a particular time. It may incorporate verifiable external evidence. It does not turn an assertion into objective truth. Registration similarly establishes traceability to a controller, not safety, quality, endorsement, liability, or current legal standing.

### Does one Ally become a surveillance system?

It could if implemented as one global prompt and context lake. The proposed architecture instead treats one Ally as one Member-facing relationship backed by compartmentalized contexts, credentials, providers, budgets, retention, conflicts, and grants. The actual operator and model-provider visibility must still be documented, measured, and constrained. The architecture does not make that risk disappear.

### Can append-only evidence coexist with correction and deletion?

Only by separating the integrity of a transition from indefinite retention of its plaintext. Supersession, tombstones, field redaction, encryption-key destruction, aggregate deletion, legal hold, and public hash anchors have different privacy effects. The exact Record retention and erasure model remains a protocol and counsel decision; “immutable” must not be used as an excuse to ignore lawful deletion or correction.

### Open decisions for ratification

Area | Recommended v0 position | What remains open
--- | --- | ---
Mage | Control-plane service principal; no Member impersonation, vote, personal grant, or ordinary personal-data path. | Threshold design, break-glass scope, operator-visible plaintext, audit and recovery mechanics.
Ki | Genesis Host Actor plus versioned Ally template until a human Source exists. | Final product language, lifecycle after Genesis, public concierge boundaries.
Graph engine | PostgreSQL typed nodes/edges and pgvector behind a stable graph service. | Representative benchmarks, AGE or other query layer, rebuild source completeness.
Home authority | One current home and ordered authority stream per mutable aggregate. | Migration rollback, controller conflict, cache rules, public replication policy.
Organization | Jurisdiction-neutral object with West Virginia DUNA as first legal-form adapter. | Additional adapters, evidence freshness, membership thresholds, counsel review.
Compute | Fixed, nontransferable prepaid usage credits if required for v0 operations. | Economic, accounting, consumer, tax, governance, and securities analysis.
External collaboration | Manifested Package exchange; no ambient remote-machine control. | Capability-safe interactive sessions and stronger sandbox attestation.
Profiler / Sentinel | Consent-limited Profiler; observe-only Sentinel; no person scores. | Necessity, privacy impact assessment, bystander rules, deletion and appeal.
KAP | Versioned client-server and server-server contract with signed requests and Records. | Wire schema, canonicalization, negotiation, revocation, error taxonomy, independent implementation.
Record privacy | Append corrections and preserve minimal integrity evidence. | Erasure, cryptographic deletion, public anchors, legal hold, retention policy.

### Claims deliberately deferred

The paper does not claim global adoption, model truthfulness, complete legal compliance, proof that the home-authority scheme is final, proof that the Field remains comprehensible at planetary scale, or proof that the proposed economics are legally and socially sound. It also does not settle Ally NFTs, transferable tokens, multilevel commissions, autonomous governance by agents, ambient listening, or remote execution. Those ideas are not required to validate the core architecture and should not complicate v0.

Legal and standards posture

This document is an architecture proposal, not legal advice or a published Internet standard. Legal form, privacy, payments, compensation, tax, governance, custody, and public claims must be reviewed against the implemented facts and the jurisdiction in effect at the time.

14 · Conclusion

## An Internet of acts that can answer for themselves

The Web became a general medium because common protocols separated participation from any one application or operator. Agentic systems need a comparable separation, but their central object is not a document or message. It is an act performed under delegated authority.

Kiduna’s central claim is that consequential agentic work can remain governable if four things stay joined: a human Source, a bounded agent, a deterministic authority boundary, and a durable Record. The typed graph makes that structure enforceable. The Field makes it legible without binding it to one visual form. KAP makes it portable across independently operated Ecosystems. Genesis makes the first authority reproducible, while peer spawning tests whether propagation can occur without inherited control.

The architecture does not ask people to supervise every token a model emits. It asks them to retain authority over consequences. An Ally can carry continuity and interpret intent. Actors can specialize and work asynchronously. Tools can extend reach. None of them can manufacture the standing, grant, role, policy, or settlement that would make a consequential claim true.

Kiduna should therefore be judged less by how human its agents sound than by harder tests. Can a Member delegate real work without surrendering sovereignty? Can every protected retrieval and consequential side effect identify its authority? Can secret existence remain undiscoverable outside its grant? Can drafts remain drafts until legitimate acceptance? Can a receipt show exactly what the system committed without overstating external outcome? Can two independently controlled Ecosystems collaborate without sharing a root? Can the first Ecosystem create the second without becoming its administrator?

If those tests pass, the agentic Internet stops being a metaphor. It becomes an interoperable architecture in which people, agents, and organizations can act together—and answer for what they do.

Appendix A · Glossary

## Core terms

Account
  Authentication, custody, recovery, and terms relationship. It is not the human principal or Organization membership.
Member
  A human principal in Kiduna; the Source of a personal Ally.
Source
  The authenticated human authority origin for binding instructions to a personal Ally.
Ally
  A member-representing agentic identity. One logical relationship may use isolated runtime contexts.
Actor
  A functional agent governed by an owner, immutable manifest, grants, budget, lifecycle, and closed command set.
Worker
  A deterministic implementation process, such as a scanner or projector, that represents no participant.
Mage
  The noninteractive Ecosystem service principal for bounded control-plane work.
Ki
  The Genesis onboarding presence; proposed technically as a Host Actor plus the initial Ally template.
Field
  The current permission-filtered subgraph rendered for a principal, context, device, and preferences.
Scene
  A bounded projection of a Project or context inside the Field; not a separate authority object.
HUD
  The contextual interface posture through which conversation, documents, diffs, tables, ACTIONS, and consequences become focal.
Organization
  A jurisdiction-neutral container for governance, members, policies, Projects, Actors, and legal-form evidence.
Project
  A durable unit of work with participants, Items, Packages, ACTIONS, Records, and one or more Scene projections.
Package
  Bounded correspondence with an explicit manifest, destination, allowed operations, and inspectable return.
ACTION
  A durable consequence-bearing request awaiting a person or Actor, distinct from a command.
Command
  A named, typed, versioned domain transition with explicit authority, preconditions, effects, idempotency, and evidence.
Record
  Member-visible, provenance-carrying evidence of an accepted fact, transition, correction, return, or settlement.
Receipt
  A deterministic presentation or signed subset of the committed Record, derived from executed parameters.
Kiduna Server
  The deployable software distribution used to instantiate an Ecosystem.
Ecosystem
  A logical administrative, security, data, and federation domain that may span multiple processes and replicas.
Network
  The live federation of compatible Ecosystems and shared public protocol state, not a global private store.
KAP
  The proposed Kinship Agency Protocol for client-Ecosystem and Ecosystem-Ecosystem semantics.
Current home
  The one Ecosystem currently authoritative for a mutable aggregate and its ordered command stream.
Registered
  Traceable to an issuer or controller under a registry contract; not necessarily trusted, safe, true, or authorized.

Appendix B · Challenge-to-architecture map

## How the implementation answers the problem

Challenge | Architectural response | Status and caveat
--- | --- | ---
Ambiguous agent authority | Authenticated Source, explicit authority classes, and sole deterministic command boundary. | Core invariant.
Context becomes instruction | Only the Source binds a personal Ally; all other input is context or a scoped request. | Core invariant; requires end-to-end input labeling and tests.
Identity trapped in platforms | Portable protocol IDs, controller keys, and one current home per mutable aggregate. | Design goal until rotation, migration, and independent conformance work.
Global agent memory threatens privacy | Typed graph, permission-before-retrieval, compartmentalized Ally contexts, explicit replication. | Core direction; operator plaintext threat model remains implementation-dependent.
Agent output loses provenance | Package lineage, derivative edges, Records, corrections, and generated receipts. | Core invariant; factual truth still needs external evidence.
Distributed action is overreported | Intent, local command, submission, and external settlement are separate states. | Proposed v0 saga model.
Work becomes invisible | Field projections, consequence-ranked ACTIONS, Records, and accessible semantic parity. | First-party experience invariant; exact HUD behavior is proposed.
Federation recreates a super-admin | Independent Ecosystem custody, peer KAP, and spawn provenance without parent control. | Core federation goal; must be proven by a second implementation.
Organizations become app configuration | First-class Organization, membership consent, roles, Forum policy, legal evidence, Projects, and Records. | Protocol-neutral Organization is a proposed canon correction.
Retries and failures fabricate success | Idempotency, optimistic versions, outbox, explicit uncertainty, and recovery ceremonies. | Core implementation property requiring fault injection.

References

## Primary technical and legal sources

1. Model Context Protocol. “Architecture,” specification dated 18 June 2025. modelcontextprotocol.io/specification/2025-06-18/architecture.
2. W3C. Decentralized Identifiers (DIDs) v1.0, W3C Recommendation. w3.org/TR/did-core.
3. IETF. RFC 7519, JSON Web Token (JWT). rfc-editor.org/rfc/rfc7519.
4. IETF. RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP). rfc-editor.org/info/rfc9449.
5. W3C. Web Authentication: An API for accessing Public Key Credentials — Level 3. w3.org/TR/webauthn-3.
6. AT Protocol. “Repository,” protocol specification. atproto.com/specs/repository.
7. AT Protocol. “Repository Synchronization,” protocol specification. atproto.com/specs/sync.
8. pgvector. Official project documentation. github.com/pgvector/pgvector.
9. Apache AGE. “Overview.” age.apache.org/overview.
10. Solana. “Programs,” core documentation. solana.com/docs/core/programs.
11. West Virginia Legislature. West Virginia Code §36-13-2, definitions governing decentralized unincorporated nonprofit associations. code.wvlegislature.gov/36-13-2.
12. West Virginia Legislature. West Virginia Code §36-13-14, dissolution provisions. code.wvlegislature.gov/36-13-14.
13. Kiduna Kit v1.4, dated 11 July 2026, and Kiduna: A New Architecture for the Agentic Internet — Product Architecture Specification v0.1. Internal design sources used as the baseline for this proposal.

Source precedence

Kiduna design sources establish intended architecture. Technical standards establish reusable mechanisms. Primary legal sources establish external constraints. None of these sources by itself proves that an implementation is secure, interoperable, compliant, or operationally complete.