The Build · Functional Specification · v2.0 standalone · 2026-08-01

Initial Release — Functional Specification

What the first release does, Scene by Scene and Surface by Surface — a standalone document: one careful read gives the whole scope. v2.0 supersedes v1.0 (the estimation frame and exclusions list moved out; the release explained whole).

← Kiduna — home Surfaces Orchestration Foundation Protocol Organizations Actions Roles Sentinel Legal Institutions Integrations
AI-native, not app-shaped — and done means done: the release is judged complete when the Scenes work across the Surfaces as written here, not when a minimum slice survives contact with users.

1. What Kiduna is

Kiduna is the creation engine for the agentic internet, owned and operated by Kinship Duna — the genesis organization, registered with the West Virginia Secretary of State (Org ID 628407). It is one application in which people and their intelligent agents create allies, build alliances, launch organizations, and shape a reciprocal economy where value stays inside the system.

A member joins by invitation: a Kinship Code from a current member, sealed with a Handshake — a single-use word the two people agree outside the system. The inviter is the verification; there is no email confirmation, no phone number, no third-party identity check. The new member brings in one hundred dollars as their initial Compute purchase, receives their wallet, and from then on lives in one application: they discover organizations and communities in the Atlas, give their Realms character in the Studio, meet and organize people in the Commons, build their own capabilities in the Workbench, govern and allocate in the Forum, settle in the Exchange, use what everyone builds in the Garden, and hold and move value in the Vault.

One intelligence — Ki — runs through all of it. Context follows location: Ki in a veterans Realm speaks from that Realm’s knowledge and character; Ki in a cricket Realm speaks from that one’s. Ki speaks in the third person, is proactive by default, and everything a member can do by touching, they can do by saying.

Two ground rules govern the whole release. First, the experience is AI-native, not app-shaped: there are no fixed menus and no procedural navigation — the member acts in the Field and talks to Ki, and the system composes what is needed. Nobody has shipped this before; we do not ship something short of it. Second, done means done: this is not an MVP. The release is complete when the Scenes work across the Surfaces as written here.

2. The vocabulary

Everything in Kiduna is built from a small, closed vocabulary.

Eight Scenes — what you are doing. A Scene is a unique place — a room, a scenario, an area — rendered in Flutter/Flame with its sprites, tiles, and interface elements: a cohesive set of Media connected to the full Kiduna stack. The eight canonical Scenes are the launch set; Builders create more. Scenes connect through Portals — that is how you navigate from Scene to Scene: a plain tap to enter, an abortable crossing, with press-and-hold reserved for real signatures.

Four Surfaces — what device you are on. A Surface is a form factor, not a product: Desktop web, Mobile, the Chrome Sidebar, and CTV. Every Scene reaches every Surface except the Vault, which is web-only. A basic version of all four Surfaces ships in the initial release — depth varies by surface, presence does not.

Seven Elements — what things are: Realms (what can be entered), Actors (all agents that are not Allies — an open-ended class including Operators, Envoys, Sentinels, Workers, and Supervisors), Media (stable stored content — files, images, documents, structures, some of which feed the knowledge stores), Allies (the members’ representatives — the visible identity of a person, with the human Source standing behind it), Resources (what things cost and how they are paid for), Actions (the deterministic, reserved operations intelligence is never allowed to improvise — moving money, issuing tokens, finalizing votes), and Offers (what is put forward for others to take up).

Ten Realm types — the closed set: Ecosystem · Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell. Every Realm nests inside Kinship Duna, the Ecosystem, and every Realm has the same parity of capability: it can be shaped, connected, entered, and governed.

Six Capacities — how any agent is built, each a verb and the thing it creates: Inform with Wisdom (the vector knowledge base — what it knows), Instruct for Presence (the system prompt — how it carries itself), Empower with Connections (integrations — what outside systems it can reach), Enable with Automations (deep agents and triggers — what it keeps doing without being asked twice), Impart Abilities (skills, defined in markdown — what it knows how to do), and Align for Coherence (Sentinels and values — what watches the work and keeps it true). An Ally and a Realm’s intelligence are both built from these same six.

Themes — what things are about. A cross-cutting tagging layer in the Kinship Graph: twenty-six themes in six clusters (People & Care, Society & Justice, Culture & Play, Place & Planet, Work & Wealth, Knowledge & Frontier), applicable to Realms, Allies, and Offers, at most three per Realm. Themes aggregate up the Realm nesting — the system can answer “show me everything happening in Health” — and open folksonomy sub-themes live beneath the fixed spine.

3. The eight Scenes

3.1 Atlas — Discover

The navigable space of everything: Realms rendered as original icons, clustered by relation, arranged by Gravity — orbits of importance in which distance means current relevance to this member, now, never worth.

The member can see the space of Realms they are permitted to know about, clustered by relatedness — shared members, shared Themes, shared activity. They can watch relevance work: when something becomes relevant — a search, trending activity, a new connection — it comes forward and grows through five orbit positions, promotable from any position when relevance spikes. They can pan and zoom freely to any orbit, always overriding the arrangement; the member’s view is never trapped by the algorithm. They can search, and see results express themselves spatially — the found thing pulls to the front rather than rendering as a list. They can inspect anything — its true type, containment, permissions, and provenance — through the inspect affordance or by asking Ki. They can join what admits them, engaging a Realm from its inspect card. And they can filter and read by Theme, with Themes aggregating up the nesting.

Atlas is read-only. Nothing is edited, updated, or created from the Atlas.

3.2 Studio — Create

Where Realms take their character. Creation is conversational with Ki plus direct manipulation; the six Capacities are the underlying form the member fills without ever being shown a form.

The member can create a Realm and shape its identity: its name, its icon (original SVG artwork, buildable and editable in Studio — never icon libraries), its interface elements, and its Theme tags. They can attach Wisdom — uploading Media and connecting sources, with content landing in the knowledge store scoped to that Realm. They can write Presence — the system prompt that makes a veterans Realm feel different from a cricket Realm and a politics Realm. They can configure the remaining Capacities: Connections, Automations, Abilities, and Coherence — the Realm’s values statement, with Sentinel enforcement phasing in behind it. They can create and refine their Ally the same way, from the same six Capacities. And they can build Scenes — new rooms, scenarios, and areas, composed of Media and rendered in Flutter/Flame — as new ways to experience their Realms, with the code-adjacent parts of that work landing in the Workbench.

3.3 Commons — Organize

The people Scene: who to connect with, whose Wisdom to learn from, how collaboration forms. The member can see and explore the people-space of any Realm they belong to — the members, their Allies, whose knowledge is available. They can form a Relationship with another member, verified by a Handshake: one member tells Ki who the other person is and what word they agreed; the other member must enter that word, or the Relationship does not form. They can learn from and engage others’ Allies where permitted, and converse around people and their work. And they can organize — gathering people toward an alliance or organization, which is then shaped in Studio.

Commons is scoped to Realms: it presents the containers people share, deliberately, rather than a directory of everyone and everything.

3.4 Workbench — Build

The maker’s sandbox. What members build here are Abilities — the same Capacity the platform itself ships, now member-implemented — together with the agents and automations composed from them, and the working parts of custom Scenes.

The member can build and test custom Abilities, agents, automations, and Scenes in a sandbox that cannot touch real Actions until promoted. They can compose automations from what the platform already runs — deep agents, triggers, sequences — rather than writing raw code. They can hand real coding work to Claude Code or Codex through the Workbench plugin: a self-describing package goes out, the coding agent works in its own environment, and the result returns as a package that unpacks into the graph, recorded like any other work. They can deploy a custom Ability into a Realm — only into Realms where they hold the Builder role, deployment itself being a named, deterministic Action — and the Ability then operates only within the Realms where it is explicitly deployed. They can inspect any custom Ability — author, history, provenance, reach — before relying on it, and a Builder can make an Ability public, its full history traveling with it into any Realm that adopts it. As the Workbench matures, members connect their own MCP servers, add small amounts of code against a clear API, and design and sequence their own loops — Realm-scoped, role-gated, never self-authorizing.

The trust model, in one line: Realm containment plus the Builder role plus inspection — if you trust the Realm you are in, you can trust the Ability deployed there — with the plugin checking the Builder’s credentials at hand-off and return, and Sentinels running the acceptance protocol on every returning package: checks for prompt injection, malicious code, and bugs, handshaking with the coding-agent plugin on flagged items. A returning package lands as a draft; nothing deploys until acceptance passes; violating packages are quarantined as evidence.

3.5 Forum — Govern

Governance for every Realm that has any. The member can raise a proposal in any Realm where their role permits, deliberate, and vote. Votes are equal-weight, never weighted by money or holdings — every member, the same weight, in every Realm. They can allocate a Realm’s Resources — treasury spending, grants, budgets — through proposals whose passage executes the corresponding deterministic Actions. And every governance act produces a Record whose plain-language receipt is generated from the command’s own parameters, so the sentence a member reads and the command that executed can never disagree.

Releasing a duna’s own token is a later Forum capability; at launch, everything runs on $KIDUNA.

3.6 Exchange — Settle

Deliberately simple. The member can buy Compute with $KIDUNA, and move between $KIDUNA and USDC, wallet to wallet. Prices and balances are always honest, and three Resource facts stay visible everywhere: units of $KIDUNA held, wallet value in dollars, and the current price of one $KIDUNA. Liquidity is deliberately unified: at launch there is one currency, and other duna tokens join when ready.

3.7 Garden — Enjoy

Where built things get used — the Scene the whole system exists for. A veteran arrives as a veteran, not as a platform user. Someone takes a course, gets help getting elected, runs a rideshare, guides tourism, navigates medical care, opens a store.

Each app in the Garden is a deployed Scene, entered through a Portal, and each renders its own experience through the composition grammar: a small vocabulary of interface primitives — cards, panels, lists, maps, schedules, tiles, chips, action cards, on the order of fifteen and ruthlessly held there — with rules for combining them. Studio (and Ki) author app experiences by composing these primitives, and a deterministic renderer draws them. The launch apps ship as authored compositions in the grammar — real, usable apps drawn from the real organizations: the veterans’ connection, the course, tourism, the store — not placeholders. After launch, Ki composes arrangements generatively within the grammar: it arranges primitives, never invents them, and Actions always render as deterministic chips and action cards, so no composition can misstate a consequence.

The member can enter any app their Realms offer and use it; move between apps by Portal, Scene to Scene, without leaving the system, with identity, permissions, Compute, and Records carrying; and find apps by Theme in the Atlas and enter them in the Garden.

3.8 Vault — Store

The wallet-shaped Scene, web-only — one place to go for value at rest and value crossing the boundary. The member can bring fiat in (the one-hundred-dollar joining step and everything after — card payment, a connected wallet, or a direct USDC transfer) and receive $KIDUNA; convert back out within the standing redemption policy; and hold $KIDUNA, USDC, and badges, seeing balances, history, and earnings plainly. The member’s custody rights are stated in plain language: what is theirs is theirs, and they can export it.

4. The Surfaces

Desktop web is the working distance: the Field on the left, Ki beside it on the right, roughly seventy-thirty. Density, inspection, governance, commitment. Designed for 1280 pixels and up, functional to 1024 with Ki collapsible; below that the mobile rendering takes over.

Mobile is the human distance: presence, capture, coordination, bounded decisions, with Ki as a collapsible bottom sheet. iOS 16 and Android 10 and up, portrait primary. Mobile can confirm most consequential Actions — many members will never touch a desktop, and the product is whole for them.

The Chrome Sidebar is the extension: the agentic internet alongside the ordinary one. It reads what the member reads and filters everything through Kinship Codes — registered things light up with what they are and what they trace to; unregistered things stay what they always were, a stranger, not a threat.

CTV is the shared big screen — Flutter/Flame on Android TV at 1080p, driven by the mobile devices in the room, several people at once. The Garden’s communal form: the first surface where a household or a room full of people uses what their organizations built, together.

Everything is Flutter/Flame wherever it renders; the web versions are the same build served remotely. The two modes — Chat and Live — remain available on every surface. The formal accessibility baseline is WCAG 2.2 AA: screen-reader names, visible focus, non-color status, reduced motion, 200% text scaling, 44-pixel touch targets.

Allies are in every view. The people render wherever the member is — every Scene, every Surface — and selecting an Ally opens it: who it represents, its Presence, and how to engage.

There is no offline mode. If you are not connected, you cannot use the system. Anything available for download can be downloaded — a download is just a download, not an offline working state.

5. The systems beneath

Ki and the conversation. One chat runs through the whole application, and context follows location. Ki is proactive, rearranges the Field by default (persistence only where the member anchors it), speaks in the third person, and can always answer “why am I seeing this?” Everything a member can do by touching, they can do by saying, typed or spoken.

Identity and onboarding. Person-vouched, end to end: a one-time invitation plus the inviter-set Handshake, a Code Name, and a password. No email, no phone, no third-party validation — the inviter is the verification. Joining auto-enrolls the member in Kinship Duna; the release is invite-only.

The economic rails. The economy is on the blockchain from day one, and the intelligence — not smart contracts — runs it. Every member has a FROST wallet; every Organization, Alliance, and Institution has a Squads wallet; Communities and Relationships hold no wallets of their own. Everything the economy needs happens wallet to wallet — $KIDUNA and USDC — orchestrated by agentic AI, with every movement a named, deterministic Action that generates an honest Record. No external token platform and no new smart contracts are required: launchpad structures, governance markets, automatic liquidity mechanics, and per-project tokens are all replaced by the orchestration and database layers working over the real wallets, with enforcement decentralizing over time. Liquidity is never fragmented: at launch everything runs on $KIDUNA. The utility model is the engine — $KIDUNA pays for intelligence, and the Agency Premium lets each organization set what its intelligence costs, with part of the premium flowing to its treasury and the waterfall distributing the rest.

The Kinship Graph, Themes, and Gravity. The graph holds the world: Realms and their nesting, members and Allies, Relationships, Media, Records, and the Theme layer. Gravity consumes Themes, relations, and activity to arrange the Atlas; theme-affinity matching lets the graph route introductions — the solar-installation alliance finds the veterans’ housing organization on its own. Sub-themes accumulate as folksonomy and join the canonical spine when the Ecosystem adopts them through its regular governance.

The command boundary and Records. The graph service is the sole policy and command boundary. Intelligence proposes; deterministic code authorizes and commits. Named commands, not raw operations; receipts whose sentences are generated from the executing parameters and therefore cannot lie; four access levels enforced everywhere; simulations structurally incapable of touching real rails. Every functional statement in this document that moves money, issues tokens, or finalizes a vote is an Action behind this boundary.

The privacy hierarchy. An item may carry more privacy than its context, never less. Something marked public is only really public if it lives in a public Realm; within any Realm a member can make an item private or secret, but nothing inside a private or secret context can be more exposed than the context itself. The Realm sets the floor; members raise it item by item; no setting can lower it. Participation in one Realm never silently exposes activity in another, and an absence of information is a boundary, not a failure.

The adoption rule. Any Realm can adopt anything that is public or offered to it — the Realm decides. When the Ecosystem adopts something through its regular governance, it becomes available everywhere. One rule covers custom Abilities, custom Scenes, sub-themes, and whatever comes next: local adoption is free choice; universal standing is a governance act.

The design repository. All icons, symbols, and graphics across the eight Scenes — including the twenty-six Theme icons — are built as one consistent, growing repository that populates the universe: original artwork, cluster-organized, legible at orbit distances, buildable in Studio.

6. What complete means

The release is judged complete when: all eight Scenes work as written here; a basic version of all four Surfaces ships, CTV included — depth varies by surface, presence does not; the Garden opens with real, usable apps from the real organizations, authored in the composition grammar; a member can travel the whole journey — invitation, Handshake, one hundred dollars, wallet, Ally, Realm, Relationship, proposal, vote, purchase, app — with every consequential step behind the command boundary and every movement leaving a Record; and the whole of it is AI-native — no menus, no navigation, one Field, one Ki, eight Scenes, connected by Portals.


v2.0 · August 1, 2026 · standalone edition — supersedes v1.0. This document is self-contained by design; the Core Taxonomy remains the law behind it.