Kiduna: A New Architecture for the Agentic Internet

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.

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

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.

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

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.

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.

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.

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:

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.

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.

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.

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.

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.

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

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.

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:

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

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.

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.

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.

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:

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.

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.

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]

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

How the implementation answers the problem

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.