Status: Canonical working taxonomy
Version: 1.3.3
Date: July 19, 2026

Supersedes: Version 1.3.2
Scope of this revision: Clarifies the Field as an always-present but not necessarily continuously visible context; makes ongoing and collective Realm agency explicit; clarifies focused Panels and Scenes without prescribing a fixed Studio layout; and identifies current design terms that remain non-canonical.

The Kidunaverse is a unified agentic environment composed of:

1. the Field;
2. Surfaces;
3. Realms;
4. Presences;
5. Agents;
6. Agent Capabilities;
7. Elements;
8. Panels;
9. Scenes and Portals;
10. Artifacts;
11. Actions;
12. Roles;
13. Authority and Permissions;
14. Privacy and Visibility;
15. Trust;
16. Lifecycle Status;
17. Governance;
18. Offerings;
19. Treasuries; and
20. Compute.

These are the primary elements of the Kiduna Canon, Graph, protocol, and interface.

1. The Field

The Field is the complete living and navigable environment of the Kidunaverse.

It includes the network’s Realms, activity, agency, Wisdom, memory, relationships, Presences, work, play, and other forms of participation.

The Field is always present as the context of participation, but it does not need to be continuously visible or represented as a map. A Surface may focus attention on one Realm, Panel, Scene, conversation, or body of work while the Presence remains within the Field.

It is the way a Presence perceives, enters, explores, and acts across the network.

Anyone participating in Kiduna is participating in the Field.

The Field provides a continuous context in which:

• Realms can be entered and explored;
• Presences and Agents can be encountered;
• Artifacts and relationships can be understood;
• Actions can be initiated;
• Elements can be moved, copied, opened, or transformed;
• Panels can be placed over the current context;
• Scenes can be entered through Portals; and
• Ki remains available through voice, chat, and direct interaction.

The Field also provides continuity while:

• other Realms and their authorized Actors remain active;
• Automations and long-running Actions continue within their authority;
• Realms contribute, respond, relate, or request attention;
• changes elsewhere become relevant to the current Presence or Focus; and
• a Presence moves between focused work and broader orientation without losing context.

A Surface should make material activity or attention needs understandable and make broader context reachable. This does not require the Surface to expose every active Realm, relationship, or process at once.

The Field is not a desktop, file manager, website, or collection of disconnected applications.

It is a living, navigable, contextual environment.

A Presence does not need to navigate rigid menus or manually arrange every object. The system generates useful representations based on the Presence’s:

• current goal;
• current Realm;
• Role;
• relationships;
• permissions;
• recent activity;
• available Wisdom; and
• immediate context.

Visual interaction feeds the same agentic system as conversation.

Tapping an Element, typing into a box, moving an object, pressing a button, or speaking to Ki are all ways of providing context and initiating Actions.

The Field contextualizes everything in relation to:

• where it belongs;
• what it contains;
• what contains it;
• who may access it;
• how it is related to other things;
• what may be done with it; and
• which Agents may act within or upon it.

The Field must not imply that a Presence is the only active center of the environment. Other Realms and Presences may possess their own agency, goals, relationships, commitments, and authorized activity. Their activity remains subject to authority, permissions, privacy, visibility, policy, Trust, and the production of appropriate Records.

2. Surfaces

A Surface is a device-specific way of accessing the Field.

The Field is one environment. Surfaces are the different windows through which it is experienced.

A Surface determines how the Field is displayed and controlled, but it does not create a separate version of the Kidunaverse.

2.1 Kiduna Studio

Kiduna Studio is the primary Surface for desktop and laptop computers.

It is optimized for:

• building;
• creating;
• organizing;
• researching;
• coding;
• designing;
• operating complex workflows;
• managing large collections of Artifacts;
• working across multiple Realms; and
• supervising long-running work.

Studio may connect with desktop agentic systems such as:

• Claude Cowork;
• Claude Code;
• ChatGPT;
• Codex; and
• other compatible development or knowledge-work environments.

These connections may operate through:

• plugins;
• APIs;
• MCP servers;
• local services;
• command-line tools; or
• other approved interfaces.

These systems extend Studio but do not replace Ki, the Field, or Kiduna’s authority and permission model.

2.2 Kiduna Live

Kiduna Live is the primary mobile and tablet Surface for iOS and Android.

It is expected to be the way most people interact with the Kidunaverse.

Live is optimized for:

• conversation with Ki;
• navigation of the Field;
• communication;
• approvals and confirmations;
• governance participation;
• payments;
• Presence management;
• controlling other Surfaces;
• interacting with nearby Realms and Scenes; and
• receiving contextual updates.

Kiduna Live may control Kiduna TV, projectors, installations, and other connected Surfaces.

2.3 Kiduna TV

Kiduna TV is the Surface for:

• connected televisions;
• projectors;
• large displays;
• stages;
• festivals;
• concerts;
• public installations; and
• other large-screen environments.

Kiduna TV is normally controlled through Kiduna Live rather than through a conventional television remote.

It may display:

• shared Realms;
• performances;
• community gatherings;
• governance sessions;
• presentations;
• public information;
• interactive environments;
• live Agents; and
• Scenes.

Kiduna TV is not limited to conventional television interfaces. It may operate on:

• ultra-short-throw projectors;
• stage displays;
• projection mapping systems;
• installations;
• interactive walls; and
• other large-format visual systems.

2.4 Kiduna Express

Kiduna Express is the browser Surface, initially delivered through a Chrome extension with a persistent sidebar.

Express allows a Presence and Ki to navigate and act across the open internet.

It can:

• identify registered Realms and Institutions;
• display trust and verification context;
• detect relevant Kinship Codes;
• communicate with Agents operating on other websites;
• communicate through social-media accounts;
• interact with external services;
• connect browser activity to the Field;
• support safe agentic commerce;
• preserve context across websites;
• identify possible scams, impersonation, phishing, or prompt injection; and
• make Kiduna functionality available without leaving the current webpage.

Express is not a separate Kidunaverse.

It extends the Field into the browser and the open internet.

3. Realms

A Realm is anything that can be entered, explored, addressed, acted within, or communicated with.

A Realm may:

• contain Presences;
• contain Agents;
• contain Artifacts;
• contain Elements;
• contain other Realms;
• possess Wisdom and Stance;
• establish Roles and Permissions;
• conduct governance;
• hold resources;
• maintain a Treasury;
• make Offerings;
• act through Agents; and
• maintain relationships with other Realms.

A Realm may remain active while a Presence is focused elsewhere. Through authorized Agents, Automations, policies, and relationships, a Realm may:

• continue bounded work;
• receive and evaluate contributions;
• maintain state;
• respond to changes;
• make Proposals;
• request attention;
• coordinate with another Realm; and
• produce Records.

Ongoing Realm activity does not create independent authority. Every Agent Action must remain traceable to a Source of authority, current permissions, applicable policy, and the Realm in which the authority applies.

Realms are where work is organized and carried out.

They are generated automatically from the Canon and Graph. A Presence may organize and move things within a Realm, but the Realm is not defined by a fixed visual arrangement.

A Realm is a semantic and agentic context before it is a visual space.

Realms may be nested.

A Presence may move:

• across the Field;
• into a Realm;
• from one Realm into a nested Realm;
• between related Realms; or
• from a Realm into a Scene through a Portal.

Elements may be moved, copied, or referenced across Realms, subject to:

• authority;
• permissions;
• privacy;
• visibility;
• custody;
• provenance; and
• Realm policy.

3.1 Realm Types

Ecosystem

An Ecosystem is a broad Realm within which other Realms coordinate through shared:

• infrastructure;
• protocols;
• standards;
• markets;
• services;
• identity systems;
• trust systems; or
• governance.

An Ecosystem may contain:

• Institutions;
• Organizations;
• Alliances;
• Communities;
• Projects;
• Offerings;
• relationships;
• shared Agents;
• shared Treasuries; and
• shared resources.

Institution

An Institution is a particularly significant Realm representing an established external legal, civic, educational, commercial, financial, or social entity.

Examples include:

• governments;
• universities;
• corporations;
• foundations;
• courts;
• banks;
• standards bodies;
• public agencies; and
• other recognized legal or institutional entities.

An Institution may:

• control verified domains;
• issue credentials;
• exercise legal authority;
• maintain authoritative records;
• enter agreements;
• delegate authority; and
• interact with other Realms through authorized Agents.

Organization

An Organization is a coordinated Realm with its own:

• identity;
• membership;
• governance;
• Treasury;
• policies;
• Agents;
• Offerings; and
• operations.

A DUNA is one legal form an Organization may take.

Alliance

An Alliance is a Realm in which multiple Presences or Realms coordinate around a shared objective without necessarily forming a new Organization.

An Alliance may be:

• temporary;
• recurring; or
• permanent.

An Alliance may have:

• members;
• Roles;
• Agents;
• Artifacts;
• a shared Treasury;
• lightweight governance;
• agreements; and
• projects.

Community

A Community is a Realm formed primarily around shared:

• identity;
• affinity;
• interest;
• practice;
• experience;
• place; or
• relationship.

Project

A Project is a Realm organized around a defined body of work, goal, problem, or outcome.

A Project may contain:

• participants;
• Roles;
• tasks;
• Agents;
• Artifacts;
• budgets;
• milestones;
• decisions;
• Automations;
• Offerings;
• a Treasury; and
• related Projects.

Relationship

A Relationship is a Realm representing a persistent connection among two or more Presences or Realms.

A Relationship may contain:

• history;
• commitments;
• conversations;
• permissions;
• shared Artifacts;
• obligations;
• agreements;
• Agents;
• memories;
• goals; and
• accumulated context.

Member Realm

Every known member may have a personal Realm.

A Member Realm may contain:

• the member’s Presence;
• Ki’s context for that member;
• private and secret Artifacts;
• personal relationships;
• connected accounts;
• goals;
• memories;
• Automations;
• permissions;
• a personal Treasury; and
• nested Realms.

The Member Realm is distinct from the Presence through which the member appears.

Offering

An Offering may itself be represented as a Realm.

This allows a Presence to enter the Offering and:

• explore its terms;
• communicate with its Agents;
• inspect related Artifacts;
• make selections;
• negotiate;
• purchase;
• subscribe; or
• participate.

Other Realm Types

Additional Realm types may include:

• events;
• gatherings;
• agreements;
• campaigns;
• funds;
• properties;
• causes;
• products;
• services;
• domains;
• public spaces;
• games;
• performances; and
• programs.

A new Realm type should be created when something requires persistent:

• context;
• containment;
• relationships;
• communication;
• authority;
• identity;
• resources; or
• agency.

4. Presences

A Presence is the way a person, group, or Realm appears and participates in a particular context.

Presence replaces the general use of terms such as “user” or “persona.”

A Presence may be:

• singular;
• plural;
• identified;
• unidentified;
• public;
• private;
• cloaked;
• temporary; or
• persistent.

A person may maintain continuity across contexts while appearing differently within each Realm.

A Presence may have different:

• Roles;
• permissions;
• names;
• visibility;
• attributes;
• representations;
• relationships; and
• trust levels

in different Realms.

A Presence is not necessarily a separate underlying identity. It is the contextual manifestation of an identity or collective within the Field.

4.1 Singular Presence

A Singular Presence represents one person or independently acting entity.

4.2 Plural Presence

A Plural Presence represents multiple people or entities acting together.

Examples include:

• a team;
• an Organization;
• an Alliance;
• a household;
• a delegation;
• a council; or
• another coordinated group.

A Plural Presence may act through:

• an authorized Agent;
• a designated Role;
• delegated authority;
• governance; or
• the combined authority of its participants.

4.3 Visitor

A Visitor is a Presence whose underlying identity has not been authenticated.

A Visitor may enter through:

• a public website;
• a chatbot;
• email;
• social media;
• a public Scene;
• Kiduna Express; or
• another external channel.

The system should treat a Visitor as a continuing Presence when continuity can be established safely and legitimately.

Continuity may be based on:

• a social-media account;
• an email address;
• a browser or device identifier;
• a prior conversation;
• a cryptographic identifier;
• an IP address;
• answers to identifying questions; or
• other available signals.

The purpose of continuity is to improve support, context, and capability—not to build advertising profiles or target the Visitor for marketing.

Information associated with a Visitor remains subject to:

• privacy;
• consent;
• retention rules;
• disclosure restrictions; and
• applicable law.

4.4 Guest

A Guest is an identified and authenticated Presence that is not a member of the current Realm.

A Guest may be permitted to:

• view;
• ask questions;
• communicate;
• attend;
• purchase;
• use designated services; or
• contribute in explicitly authorized ways.

A Guest has no inherent right to add Artifacts, Elements, Wisdom, context, or other material to the current Realm.

The Realm may grant a Guest limited contribution permissions through:

• a Role;
• an invitation;
• a policy; or
• a specific authorization.

A Guest does not receive the baseline rights, privileges, or governance authority granted to Members of the Realm.

4.5 Member

A Member is a Presence recognized as a member of the current Realm.

Membership provides the baseline rights established by the Realm.

These may include:

• voting;
• proposing;
• participating in governance;
• adding to the Realm;
• creating Artifacts;
• using Agents;
• holding Compute;
• receiving distributions; and
• assuming additional Roles.

A Member’s actual authority is determined by the Realm’s policies rather than by a universal definition of membership.

4.6 Cloaked Presence

A Cloaked Presence is a Presence whose underlying identity is concealed from one or more audiences.

A Cloaked Presence assumes a Persona and appears under an Alias.

The Persona may include:

• an Alias;
• an image or visual form;
• a voice;
• a profile;
• selected credentials;
• selected relationships;
• a history;
• a reputation; and
• context-specific disclosures.

The connection between a Cloaked Presence and its underlying identity is governed by a Mask.

The Mask determines:

• who may know the underlying identity;
• which attributes may be proven without disclosure;
• whether trust or reputation carries across contexts;
• what Actions may be taken;
• what records are linked;
• when the Cloaked Presence expires; and
• under what authority the Presence may be unmasked.

A Cloaked Presence should not be treated as a different person unless it represents a genuinely distinct legal or collective identity.

5. Ki and Agents

An Agent is a software entity capable of:

• perceiving context;
• reasoning;
• communicating; and
• taking Actions.

Every Agent acts from a Source of authority.

5.1 Ki

Ki is the Ally.

There is one coherent Ally across the Kidunaverse rather than a collection of fictional personal assistants presented as unrelated characters.

Ki is available to every Presence.

Ki’s relationship, context, permissions, memories, Stance, and available Wisdom differ according to:

• the Presence;
• the Realm;
• the current Role;
• privacy;
• permissions;
• relationships;
• active goals; and
• available Connections.

A member may shape how Ki works with them by changing:

• Ki’s Stance as it applies to them;
• their personal context;
• available Wisdom;
• memories;
• preferred interaction patterns;
• connected accounts;
• permissions;
• goals; and
• Automations.

These changes personalize the relationship without creating the illusion that each configuration is a completely separate Ally.

Ki knows what is:

• public;
• private;
• personal;
• secret;
• Realm-specific;
• relationship-specific; and
• unavailable in the current context.

Ki must not disclose or use information outside the permissions and context through which it was obtained.

Ki may reflect Wisdom contributed by multiple Presences or Realms only within the permissions, purpose, and disclosure rules that govern that Wisdom. Ki must not reveal private or personal contributions, imply access that an Organization or administrator does not possess, invent consensus, erase attributable disagreement, or convert a person’s relationship with Ki into a surveillance channel.

Ki may communicate through every Surface and may help a Presence:

• understand information;
• make decisions;
• communicate;
• coordinate with others;
• operate tools and accounts;
• participate in governance;
• manage long-running work;
• supervise Actors;
• navigate the Field; and
• move between Realms and Scenes.

5.2 Actors

Every Agent other than Ki is an Actor.

Actors perform defined functions for Presences or Realms.

Envoy

An Envoy represents a Presence or Realm in:

• deliberation;
• negotiation;
• governance;
• voting;
• decision markets;
• diplomacy; or
• other interactions.

An Envoy exercises delegated authority but does not originate that authority.

Operator

An Operator operates systems, services, infrastructure, accounts, workflows, or resources.

Sentinel

A Sentinel observes:

• relationships;
• risks;
• permissions;
• system integrity;
• trust;
• safety;
• coherence; and
• compliance with policy.

A Sentinel may:

• advise;
• intervene;
• restrict;
• redirect; or
• escalate

within its assigned authority.

Worker

A Worker performs bounded productive work such as:

• research;
• drafting;
• analysis;
• coding;
• design;
• administration;
• moderation; or
• production.

Supervisor

A Supervisor coordinates, evaluates, directs, or approves the work of other Actors.

Integration Actor

An Integration Actor represents or operates an external service or communication channel.

Examples include:

• Gmail Actor;
• Bluesky Actor;
• Calendar Actor;
• Browser Actor;
• GitHub Actor;
• Payment Actor; and
• Research Actor.

An Integration Actor remains subject to the same authority and permission model as any other Actor.

6. Agent Capabilities

Every Agent may possess five primary capability layers.

6.1 Wisdom — What the Agent Knows

Wisdom is the information and context available to an Agent.

It may include:

• documents;
• memory;
• conversations;
• structured records;
• knowledge graphs;
• vector databases;
• relationship history;
• policies;
• Realm context; and
• current situational context.

Wisdom informs the Agent.

6.2 Stance — How the Agent Approaches Its Work

Stance defines the Agent’s:

• mission;
• values;
• priorities;
• obligations;
• loyalties;
• boundaries;
• operating principles;
• professional standards;
• system instructions; and
• prohibited behavior.

Stance instructs the Agent.

6.3 Abilities — What the Agent Knows How to Do

Abilities are reusable capabilities, tools, procedures, and skills.

Examples include:

• research;
• writing;
• negotiation;
• coding;
• design;
• financial analysis;
• governance participation;
• communication;
• planning; and
• operating external applications.

Abilities enable the Agent.

6.4 Automations — What the Agent Can Continue Doing

Automations are:

• triggers;
• schedules;
• loops;
• harnesses;
• workflows;
• recurring processes;
• condition watches; and
• long-running Actions.

Automations sustain and trigger activity.

6.5 Connections — What the Agent Can Reach

Connections provide access to:

• accounts;
• APIs;
• MCP servers;
• databases;
• wallets;
• bank accounts;
• external applications;
• devices;
• communication services; and
• other systems.

Connections extend reach but do not independently grant authority.

Every use of a Connection remains subject to:

• permissions;
• privacy;
• visibility;
• Role;
• Realm policy; and
• the Source of authority.

7. Elements

An Element is a system-native visual or interactive representation that may appear in:

• the Field;
• a Realm; or
• a Panel.

Elements are part of the Kiduna interaction system.

They may represent:

• Realms;
• Presences;
• Agents;
• Artifacts;
• Actions;
• relationships;
• status;
• trust;
• choices;
• information;
• controls; or
• context.

Elements may be:

• generated automatically;
• placed manually;
• moved;
• copied;
• transformed;
• grouped;
• connected;
• opened;
• collapsed;
• inspected; or
• acted upon.

An Element may be moved or copied between Realms by dragging it across the Field, subject to permission and privacy rules.

Moving an Element may change its location or context.

Copying an Element may create:

• another representation;
• a reference;
• a linked instance; or
• a new underlying object.

The system must clearly distinguish between:

• moving a representation;
• copying a representation;
• moving the underlying object;
• copying the underlying object; and
• creating a reference.

7.1 Element Types

Icon

An Icon is a compact visual symbol representing an object, Action, state, Agent, Realm, or capability.

Label

A Label is a textual identifier or annotation attached to another Element or location.

A Label may display:

• name;
• type;
• status;
• Role;
• trust;
• privacy;
• ownership;
• relationship; or
• other concise context.

Shape

A Shape is a visual container or object used to represent, group, emphasize, or organize information.

Shapes may carry semantic meaning and are not merely decorative.

Connector

A Connector visually represents a:

• relationship;
• flow;
• dependency;
• authority path;
• lineage;
• communication channel;
• transfer; or
• navigation path.

A Connector should express the type and direction of the relationship it represents.

Widget

A Widget is an interactive Element that displays information or allows a Presence to provide input or initiate an Action.

Examples include:

• buttons;
• forms;
• sliders;
• voting controls;
• charts;
• media players;
• approval controls;
• message composers;
• inspectors;
• timelines; and
• status displays.

7.2 Element System

New Element types may be created and added to Kiduna, but they must conform to the system specification.

The specification may govern:

• typography;
• color;
• spacing;
• scale;
• movement;
• responsiveness;
• accessibility;
• interaction;
• trust representation;
• privacy representation;
• confirmation behavior; and
• semantic meaning.

This allows the system to expand without becoming visually or behaviorally incoherent.

8. Panels

A Panel is an organized group of Elements presented in front of the Field or current Realm.

A Panel does not replace the current context. It overlays it.

A Panel may become the visually dominant place of focused work without causing the Presence to leave the Field or current Realm. A conversational or work Panel may therefore occupy most of a Surface while the larger context remains available through continuity, context signals, and an explicit path back to broader orientation.

Panel dominance is an attention treatment, not a change in semantic containment, authority, privacy, visibility, or Realm membership.

A Panel may be:

• fixed;
• movable;
• collapsible;
• temporary;
• persistent;
• contextual;
• personal; or
• shared.

8.1 Panel Transparency

A Panel exists on a continuum between Opaque and Clear.

Opaque

The Panel visually dominates or obscures the Field or Realm behind it.

Clear

The Panel allows the Field or Realm to remain fully visible.

Translucent

The Panel partially reveals the Field or Realm while retaining its own visual organization.

The system should understand Panel opacity as part of attention and interaction.

For example:

• a highly opaque Panel indicates that the Presence is primarily working within the Panel;
• a translucent Panel indicates simultaneous attention to the Panel and underlying Realm; and
• a clear Panel may provide lightweight controls without interrupting the Field.

Opacity may affect presentation and contextual emphasis, but it must not silently change:

• permissions;
• authority;
• privacy;
• visibility; or
• data access.

9. Scenes and Portals

9.1 Scenes

A Scene is a bounded visual or interactive environment that runs within a Surface.

Scenes may use:

• isometric environments;
• tiles;
• sprites;
• game objects;
• custom interfaces;
• generated imagery;
• imported assets;
• animation;
• sound;
• spatial interaction; and
• their own visual systems.

A Scene does not need to conform visually to the general design language of the Field, Realms, Panels, or system Elements.

A Scene is used when a bounded visual, spatial, interactive, simulated, performative, or game-like environment materially improves understanding or participation. A Scene may be used frequently even when a broad visual presentation of the Field is used rarely.

A Scene is not the Field itself, a general map of the network, or merely a larger Panel. Its bounded behavior, visual system, state, and entry or exit conditions distinguish it from the surrounding Realm and Surface.

A Scene may function like a self-contained:

• application;
• game;
• simulation;
• performance;
• installation; or
• experience.

Scenes remain connected to the Kidunaverse’s:

• identity;
• Agents;
• permissions;
• Actions;
• Artifacts;
• Compute;
• Treasuries;
• governance;
• trust;
• privacy; and
• event systems.

A Scene must load within a Surface.

It does not exist as a separate access layer outside the Field.

9.2 Portals

A Portal is an explicit connection between:

• a Realm and a Scene;
• a Scene and a Realm; or
• two Scenes.

A Presence enters or leaves a Scene through a defined Portal.

A Realm connected to a Scene should provide:

• a Portal into the Scene;
• a corresponding route back;
• clear identity and authority context;
• the permissions that apply inside the Scene; and
• continuity of relevant state.

A Portal may preserve or transform:

• Presence;
• Role;
• permissions;
• representation;
• inventory;
• context;
• progress; and
• Realm relationships.

Any transformation must be explicit and governed by policy.

Leaving a Scene through a Portal should preserve the relevant conversation, selected Elements, Records, permissions, and return context unless policy or the nature of the Scene requires an explicit transformation or reset.

10. Artifacts

An Artifact is a persistent object containing information, media, code, configuration, evidence, or work product.

Examples include:

• documents;
• webpages;
• websites;
• images;
• video;
• audio;
• messages;
• social posts;
• datasets;
• software;
• proposals;
• agreements;
• Agent configurations;
• Scenes;
• maps;
• models; and
• recordings.

10.1 Artifact Origin

Generated

Created within Kiduna by a Presence, Agent, or system process.

Imported

Brought into Kiduna from an outside source.

External

Remains outside Kiduna but is referenced or accessed through a Connection.

Examples include:

• a public webpage;
• a Google Drive file;
• a GitHub repository; or
• an external database record.

10.2 Verification

Verification is a state, not an origin type.

An Artifact may be verified for:

• provenance;
• authorship;
• integrity;
• timestamp;
• custody;
• source;
• authority; or
• correspondence with an external record.

Verification may use:

• hashes;
• signatures;
• Kinship Codes;
• registry records;
• attestations; or
• other forms of proof.

11. Actions

An Action is a typed operation that:

• changes state;
• creates something;
• communicates;
• transfers value;
• exercises authority; or
• affects a Presence, Realm, Agent, Artifact, Treasury, or external system.

Examples include:

• create;
• invite;
• message;
• seek;
• research;
• build;
• publish;
• post;
• email;
• connect;
• trade;
• buy;
• sell;
• offer;
• accept;
• pay;
• transfer;
• register;
• vote;
• delegate;
• appoint;
• approve;
• enter;
• move;
• copy; and
• execute.

Actions should be expressed as specific domain commands rather than broad technical CRUD operations.

Examples include:

• enter_realm
• assume_role
• create_artifact
• move_element
• copy_element
• enter_scene
• send_email
• invite_member
• submit_proposal
• purchase_compute
• propose_treasury_payment
• sign_wallet_transaction
• delegate_authority
• request_attention
• contribute_wisdom
• relate_realms

Each Action should declare:

• the acting Agent;
• the Presence or Realm represented;
• the Source of authority;
• the current Realm;
• the applicable Role;
• the target;
• the required permissions;
• the applicable policies;
• the inputs;
• the expected effects;
• reversibility;
• risk level;
• confirmation requirements; and
• the resulting event or record.

The reasoning that proposes an Action may be probabilistic.

Execution must be:

• deterministic;
• authorized;
• auditable; and
• event-producing.

An Action performed while the affected Presence is focused elsewhere must still satisfy the same authorization, audit, visibility, notification, recovery, and Record requirements as an Action performed in the foreground.

12. Roles

A Role is a contextual position held by a Presence within a Realm.

A Presence may hold:

• multiple Roles in one Realm;
• different Roles in different Realms;
• temporary Roles;
• elected Roles;
• appointed Roles;
• earned Roles; or
• paid Roles.

Roles are Realm-specific unless explicitly federated across Realms.

A Role may determine:

• goals;
• responsibilities;
• permissions;
• visibility;
• authority;
• compensation;
• eligibility;
• expectations;
• reporting relationships; and
• governance rights.

Roles do not imply access to private or secret information unless that access is explicitly granted.

12.1 Baseline Participation Roles

Visitor

A Visitor is an unidentified or unauthenticated Presence.

Guest

A Guest is an identified and authenticated Presence that is not a member of the current Realm.

Guest permissions are limited to those explicitly granted by the Realm.

Member

A Member is a Presence holding the baseline rights of membership in the current Realm.

12.2 Contribution Roles

Creator

A Creator adds or develops non-code elements of the system.

A Creator may contribute:

• Wisdom;
• Stances;
• memories;
• context;
• Artifacts;
• Agents;
• Automations;
• Connections;
• Realm content;
• visual Elements; and
• operating configurations.

Creators may build extensively within the system without changing the software codebase.

Builder

A Builder creates or modifies software.

A Builder may contribute through:

• APIs;
• MCP servers;
• plugins;
• integrations;
• applications;
• repositories;
• GitHub;
• infrastructure; or
• the Kiduna codebase.

Catalyst

A Catalyst forms or initiates a new Realm.

A Catalyst may:

• establish the Realm’s initial purpose;
• recruit initial participants;
• assign initial Roles;
• configure initial governance;
• establish initial Stance;
• initiate funding or Compute;
• appoint initial Actors; and
• guide the Realm through formation.

Catalyst is a leadership Role, but its continuing authority is determined by the Realm’s governance.

Founder

A Founder is an early member recognized under a Realm’s founding rules.

For a DUNA, Founders may be:

• the first 100 members to join; or
• where the DUNA conducts an initial Compute sale, the eligible members who join and purchase Compute before that sale closes.

The Realm must define its exact Founder qualification rule.

Founder status may provide recognition, rights, or benefits, but does not inherently provide permanent control.

Luminary

A Luminary is a Presence recognized for contributing a major work, breakthrough, body of knowledge, or other exceptional contribution to a Realm.

Luminary status may be:

• honorary;
• functional;
• compensated; or
• some combination of these.

12.3 Administrative Roles

Wizard

A Wizard has administrative authority within a particular Realm.

A Wizard may administer:

• Realm structure;
• Roles;
• Elements;
• Agents;
• configurations;
• approved Connections;
• policies; and
• operations

within explicitly granted permissions.

A Wizard cannot:

• inspect information merely because it exists in the Realm;
• override privacy;
• reveal secret information;
• bypass a Presence’s permissions;
• assume authority that has not been granted;
• override Treasury governance; or
• treat administration as ownership.

Mage

A Mage has administrative authority across an Ecosystem.

A Mage may coordinate and administer shared Ecosystem systems within explicitly granted authority.

A Mage cannot:

• override Realm sovereignty;
• inspect private or secret information without permission;
• supersede valid Realm governance;
• bypass a Presence’s authority;
• override Treasury signing or governance requirements; or
• convert Ecosystem administration into centralized control.

Neither Wizards nor Mages are superusers.

There is no universal administrative account with unrestricted access to the Kidunaverse.

The system remains:

• decentralized;
• composable;
• governed by explicit authority;
• protective of privacy; and
• resistant to invisible administrative override.

13. Authority and Permissions

Authority determines what a Presence, Realm, or Agent is legitimately empowered to do.

Permission determines whether a particular Action is currently allowed.

Authority originates with a Presence or Realm and may be:

• retained;
• delegated;
• limited;
• conditional;
• time-bound;
• revocable; or
• further delegable.

Permissions are connected directly to:

• the Presence;
• the Agent acting for it;
• the Realm;
• the Role;
• the current goal;
• the Action;
• the target;
• visibility;
• privacy;
• duration;
• conditions;
• risk;
• policy; and
• Source of authority.

A Role may grant permission to:

• create within a Realm;
• add Wisdom;
• modify Stance;
• add context;
• write to memory;
• add to a vector database;
• create or configure Agents;
• establish Automations;
• add Connections;
• invite Presences;
• publish;
• spend;
• trade;
• govern;
• appoint Roles; or
• administer specified systems.

Permissions should be explicit enough that the system can answer:

• Who may do this?
• Through which Role?
• In which Realm?
• For which goal?
• Using which Agent?
• Against which target?
• With what visibility?
• Under what conditions?
• For how long?
• Who may change or revoke the permission?

13.1 Action Authorization Levels

Autonomous

The Agent may perform the Action without asking each time.

Example: draft an email and save it to the member’s drafts folder.

Confirmed

The Agent must receive lightweight confirmation before acting.

Example: send a routine email.

Deliberate

The Action requires elevated confirmation because it is consequential, difficult to reverse, or high-risk.

The interface may require:

• press-and-hold;
• explicit review;
• a second factor;
• a delay;
• additional signatories; or
• an explanation of consequences.

Governed

The Action requires authority from:

• a Role;
• a policy;
• a Forum;
• a vote;
• a market;
• a multisignature process; or
• another governance mechanism.

Prohibited

The Action may not be performed under the current circumstances.

The interface used to authorize an Action is not itself the permission.

A button, toggle, slider, or press-and-hold control is only the means through which the underlying authority decision is expressed.

14. Privacy and Visibility

14.1 Privacy

Privacy describes how information may be accessed, used, retained, or disclosed.

Public

Available to anyone.

Private

Available only to explicitly authorized Presences, Realms, or Agents.

Secret

Highly restricted information requiring elevated protection and explicit access.

Examples include:

• cryptographic keys;
• recovery material;
• private credentials;
• protected security information; and
• highly sensitive confidential records.

Personal

Information belonging to or concerning a particular member and governed by:

• that member’s authority;
• the applicable Realm;
• relevant agreements; and
• applicable law.

Personal is not simply a stronger form of privacy.

Personal information may be public, private, or secret, but it remains associated with a human member and their rights.

Privacy may be represented through fields such as:

• classification;
• owner;
• subject;
• access policy;
• permitted uses;
• retention policy;
• disclosure restrictions; and
• deletion rights.

14.2 Visibility

Visibility determines who may discover or perceive a Realm, Presence, Agent, Artifact, Element, Action, Treasury, or relationship.

Visibility is related to permission but is not identical to it.

A Presence may be able to know that something exists without being able to open it.

A Presence may be able to view something without being able to modify it.

A Presence may be able to modify something without being able to disclose it publicly.

Visibility rules must be enforceable at the:

• Graph layer;
• Agent layer;
• Action layer;
• storage layer; and
• interface layer.

15. Trust

Trust is a contextual assessment of whether a Presence, Realm, Agent, Artifact, Connection, Action, or claim may be relied upon for a particular purpose.

15.1 Low Trust

The default when identity, authority, integrity, behavior, or provenance has not been sufficiently established.

15.2 Medium Trust

Some relevant claims have been established, but material uncertainty remains.

15.3 High Trust

The necessary identity, authority, provenance, security, and behavioral requirements have been established for the relevant Action or context.

Trust must not be treated as a single permanent reputation score.

Trust is:

• contextual;
• evidence-based;
• purpose-specific;
• revocable;
• time-sensitive; and
• subject to policy.

Something may have high trust for one Action and low trust for another.

16. Lifecycle Status

Lifecycle Status describes where something is in its operational, administrative, or legal lifecycle.

Common statuses include:

16.1 Draft

Exists but has not been formally issued, published, registered, or activated.

16.2 Published

Has been made available to its intended audience.

16.3 Registered

Has been recorded in an authoritative registry or system of record.

16.4 Active

Is currently operating and permitted to perform its intended function.

16.5 Pending

Awaiting approval, activation, verification, or another required event.

16.6 Suspended

Temporarily prevented from operating.

16.7 Archived

Retained as a historical record but no longer active.

16.8 Revoked

Previously granted status, authority, or validity has been withdrawn.

16.9 Expired

No longer valid because a defined period has ended.

16.10 Dissolved

Formally ended as an operating Realm or legal entity.

Statuses are not necessarily sequential.

For example, an Organization may be registered but not yet active.

17. Governance

Governance is the process through which a Realm creates, changes, and applies collective authority.

17.1 Forum

A Forum is the environment in which Proposals are:

• introduced;
• discussed;
• evaluated;
• amended;
• supported;
• opposed; and
• decided.

A Forum may use:

• deliberation;
• voting;
• delegated voting;
• consensus;
• decision markets;
• councils;
• appointed authority; or
• other mechanisms.

A decision market may operate inside a Forum, but a Forum is broader than a futarchy market.

17.2 Proposal

A Proposal is a proposed:

• Decision;
• Action;
• allocation;
• appointment;
• agreement;
• policy change; or
• other exercise of collective authority.

17.3 Decision

A Decision is the formally determined outcome of a Proposal or other authorized governance process.

17.4 Policy

A Policy is a persistent rule or instruction created through valid authority.

A passed Proposal may:

• create a Policy;
• authorize a one-time Action;
• allocate resources;
• appoint or remove authority;
• modify Permissions;
• modify Roles;
• authorize a Treasury transaction; or
• trigger execution.

Not every passed Proposal becomes a standing Policy.

Governance belongs to Realms.

18. Offerings

An Offering is something a Realm or Presence makes available to another Presence or Realm under stated terms.

An Offering may be represented as a Realm.

18.1 Offering Forms

An Offering may provide:

• a digital good;
• a physical good;
• a service;
• access;
• membership;
• a license;
• a subscription;
• sponsorship;
• Compute capacity;
• participation rights; or
• another defined benefit.

18.2 Payment and Eligibility Models

An Offering may use:

• one-time payment;
• recurring subscription;
• usage-based payment;
• a holding requirement;
• membership entitlement;
• earned access;
• negotiated exchange; or
• a combination of these.

A requirement to hold a specified amount of Compute is an eligibility condition, not a separate type of Offering.

19. Treasuries

A Treasury is the financial resource system of a Realm.

Any Realm may have a Treasury.

A Treasury may include:

• one or more wallets;
• one or more bank accounts;
• custodial accounts;
• payment accounts;
• token holdings;
• Compute reserves;
• receivables;
• financial commitments; and
• other governed stores of value.

A Treasury is not limited to crypto assets.

It may consist of:

• a wallet;
• a bank account;
• multiple wallets;
• multiple bank accounts; or
• any authorized combination of these.

A Treasury belongs to a Realm and is controlled according to that Realm’s:

• Roles;
• Permissions;
• Policies;
• governance;
• signing rules;
• spending limits;
• accounting rules; and
• applicable law.

19.1 Treasury Accounts

A Realm may connect multiple financial accounts to one Treasury.

Each account should declare:

• the Realm that owns or controls it;
• the account type;
• the institution or network;
• the assets it may hold;
• who may view it;
• who may propose transactions;
• who may approve transactions;
• who may execute transactions;
• applicable spending limits;
• required signatures;
• governance requirements; and
• reconciliation status.

A Treasury may aggregate information across its accounts while preserving the separate authority and operational rules of each account.

19.2 Bank Accounts

A Treasury may include one or more bank accounts.

Bank accounts may be used to:

• receive fiat payments;
• hold operating funds;
• pay expenses;
• compensate contributors;
• receive off-ramp proceeds;
• fund on-ramp purchases;
• maintain reserves; and
• interact with the traditional financial system.

Access to a bank account must remain subject to the Realm’s Permissions and governance.

A Connection to a bank account does not by itself grant authority to move funds.

19.3 Wallets

A Treasury may include one or more cryptographic wallets.

Wallets may hold:

• Compute;
• stablecoins;
• governance assets;
• market positions;
• credentials;
• tokenized assets;
• Treasury reserves; and
• other supported digital property.

Kiduna recognizes three primary wallet types.

Multisignature Wallet

A Multisignature Wallet requires approval from a defined number of authorized signers before a transaction may be executed.

Kiduna uses Squads as the standard multisignature wallet infrastructure for shared Realm Treasuries.

A Squads wallet may define:

• authorized signers;
• signing thresholds;
• spending limits;
• Proposal requirements;
• transaction queues;
• execution delays;
• emergency procedures; and
• governance Connections.

FROST Wallet

A FROST Wallet uses threshold cryptography to distribute control of a wallet across key shares.

The standard Kiduna Member wallet uses three key shares.

No single key share is sufficient to control the wallet.

The shares may be distributed across approved:

• devices;
• services;
• recovery systems; or
• custodial arrangements

according to the Member’s configuration and Kiduna security policy.

FROST wallets are the standard wallets for Members.

A Member’s FROST wallet may be used for:

• holding Compute;
• payments;
• receiving distributions;
• governance participation;
• signing Kinship Codes;
• authorizing Agents;
• connecting to Alliance governance; and
• other Member-authorized Actions.

External Wallet

An External Wallet is a wallet created or controlled outside Kiduna and attached to a Realm through a Connection.

Any Realm may attach an External Wallet.

An External Wallet may include:

• a browser wallet;
• a hardware wallet;
• an institutional wallet;
• a custodial wallet;
• a smart-contract wallet; or
• another compatible wallet.

Attaching an External Wallet does not make it native to Kiduna and does not alter its underlying signing or custody model.

Kiduna should clearly distinguish between:

• observing the wallet;
• verifying ownership or control;
• requesting a signature;
• proposing a transaction; and
• possessing authority to execute a transaction.

19.4 Realm Treasury Defaults

Different Realm types have different standard Treasury configurations.

Organization Treasuries

Every Organization has a Squads multisignature wallet as part of its Treasury.

An Organization Treasury is governed through its Forums.

Forum governance may determine:

• Treasury Policies;
• budgets;
• allocations;
• signers;
• signing thresholds;
• spending limits;
• investments;
• distributions;
• transfers;
• liquidity;
• compensation;
• protocol payments; and
• other material financial Actions.

A Forum Decision may:

• authorize a specific Treasury Action;
• create a standing Treasury Policy;
• delegate limited spending authority to a Role;
• change signer or threshold rules;
• allocate a budget; or
• trigger an executable transaction.

The Organization’s Squads wallet provides the execution and signing layer.

The Forum provides the collective authority layer.

Alliance Treasuries

An Alliance may have a Treasury and uses a Squads multisignature wallet as its standard shared wallet.

Alliance Treasuries may use simpler governance than Organizations.

Alliance governance may include:

• direct Member approval;
• signer approval;
• Role-based approval;
• threshold voting;
• budget limits;
• time-limited delegations; or
• other lightweight decision processes.

An Alliance does not require the full Forum governance system used by an Organization unless the Alliance adopts it.

Alliance Squads wallets may connect to the FROST wallets of participating Members.

These Connections allow Member wallets to participate in Alliance governance through mechanisms such as:

• signing;
• approvals;
• voting;
• delegation;
• membership verification;
• contribution tracking; and
• distribution.

The Alliance wallet remains distinct from the participating Member wallets.

A Connection does not merge custody, ownership, or balances.

Member Treasuries

A Member’s personal Treasury uses a FROST wallet as its standard native wallet.

The Member is the Source of authority for the wallet.

Ki may assist the Member with:

• understanding balances;
• preparing transactions;
• managing permissions;
• reviewing risks;
• participating in governance;
• connecting external accounts; and
• maintaining records.

Ki may not execute a transaction beyond the authority explicitly granted by the Member.

Other Realm Treasuries

Any other Realm may establish a Treasury when it needs to:

• receive funds;
• hold assets;
• pay contributors;
• make purchases;
• operate a budget;
• issue distributions;
• collect revenue; or
• participate in markets.

The Realm must define:

• who owns or controls the Treasury;
• which governance process applies;
• which wallet or account types are permitted;
• who may propose transactions;
• who may approve them;
• who may execute them; and
• how the Treasury is reconciled and audited.

19.5 Treasury Governance

Treasury governance determines how financial authority is exercised.

Treasury Actions may be:

Autonomous

An authorized Agent or Role may execute the Action within a defined Policy and limit.

Example: paying a recurring infrastructure bill below an approved threshold.

Confirmed

A designated Presence must approve the Action.

Example: approving a routine contributor payment.

Deliberate

The Action requires elevated confirmation because of its amount, risk, permanence, or sensitivity.

Example: transferring a substantial portion of a Realm’s reserves.

Multisignature

The Action requires approval from the required number of wallet signers.

Governed

The Action requires a valid Forum Decision, vote, Policy, or other Realm governance process.

These requirements may be combined.

For example, an Organization Treasury Action may require:

1. a passed Forum Decision;
2. creation of a transaction in Squads;
3. signatures from the required signers; and
4. deterministic execution by an authorized Actor.

19.6 Treasury Roles and Permissions

Treasury authority may be assigned through Roles.

Possible Treasury capabilities include:

• view balances;
• view transactions;
• create budgets;
• propose payments;
• approve payments;
• sign transactions;
• execute transactions;
• connect accounts;
• reconcile records;
• manage liquidity;
• distribute Compute;
• allocate compensation;
• manage signers; and
• modify Treasury Policies.

No Role should receive unrestricted Treasury authority by default.

Treasury Permissions should specify:

• the Realm;
• the account or wallet;
• the asset;
• the Action;
• the maximum amount;
• the time period;
• the recipient or recipient class;
• the required approvals;
• the applicable Policy; and
• whether the authority may be delegated.

19.7 Treasury Connections

Treasuries may connect to:

• Member FROST wallets;
• Realm Squads wallets;
• External Wallets;
• bank accounts;
• payment processors;
• exchanges;
• on-ramps;
• off-ramps;
• accounting systems;
• tax systems;
• governance systems; and
• liquidity venues.

Connections allow systems to exchange information or initiate authorized Actions.

A Connection does not override:

• custody;
• ownership;
• privacy;
• signing requirements;
• governance; or
• Permissions.

19.8 Treasury Records

Every Treasury Action should produce an auditable record.

Treasury records should include:

• the Realm;
• the account or wallet;
• the proposing Presence or Agent;
• the Source of authority;
• the applicable Role;
• the governing Policy or Decision;
• required approvals;
• signatures;
• asset;
• amount;
• recipient;
• purpose;
• timestamp;
• execution status;
• transaction identifier; and
• reconciliation state.

Records may be private, but their existence and use remain subject to the Realm’s governance and applicable reporting requirements.

19.9 Treasury Invariants

The following principles apply across Kiduna:

1. Any Realm may have a Treasury.
2. A Treasury may contain wallets, bank accounts, or both.
3. Organizations use Squads wallets and govern their Treasuries through Forums.
4. Alliances use Squads wallets with simpler Realm-defined governance.
5. Members use FROST wallets with three key shares.
6. Any Realm may attach an External Wallet.
7. Alliance Squads wallets may connect to Member FROST wallets for governance.
8. Connections do not merge ownership or custody.
9. Administrative Roles do not override Treasury Permissions.
10. No Wizard, Mage, Agent, or system operator has universal access to Treasury assets.
11. Every Treasury Action must have a valid Source of authority.
12. Every executed Treasury Action must be deterministic and auditable.

20. Compute

Compute is the digital capacity used to purchase intelligence, Agent operations, and related services within a Realm.

An Organization or other authorized Realm may issue or designate its own Compute.

Compute may be held, received, distributed, or managed through a Realm’s Treasury.

20.1 Realm-Defined Compute Rules

A Realm may establish:

• membership purchase requirements;
• holding requirements;
• activation thresholds;
• minimum and maximum issuance conditions;
• pricing;
• Agency Premium;
• Role-specific rates;
• lineage distributions;
• Treasury distributions;
• contributor allocations;
• transferability;
• redemption;
• conversion; and
• market access.

20.2 Raw Compute Cost

Raw Compute Cost is the underlying cost of:

• models;
• infrastructure;
• tools;
• storage;
• networking; and
• execution

required to perform work.

20.3 Agency Premium

The Agency Premium is the amount charged above Raw Compute Cost for access to a Realm’s:

• agency;
• coordination;
• intellectual property;
• infrastructure;
• community;
• context;
• relationships; and
• services.

The Agency Premium may be expressed as:

• a multiple;
• a fixed addition;
• a percentage; or
• a Role- or service-specific schedule.

20.4 Protocol Licensing

A Realm may pay Kiduna Club:

• a defined portion of the Agency Premium for use of the Kiduna stack; and
• a defined portion of Compute purchases for protocol and infrastructure licensing.

These are separate economic rules.

20.5 Compute Purchase Distribution

When Compute is purchased, the received payment may be distributed through the applicable Treasury among:

• lineage recipients;
• Kiduna Club licensing;
• the Realm Treasury;
• liquidity;
• contributors;
• sponsors; and
• other Policy-defined recipients.

A protocol default may be provided, but a Realm may change it where permitted by its governing rules.

20.6 Lineage

Lineage records the invitation or relationship path through which a Presence joined a particular Realm.

Lineage distributions may reward multiple generations of that path.

A default distribution may be:

• Generation 1: 20%;
• Generation 2: 5%;
• Generation 3: 3%; and
• Generation 4: 2%.

Lineage applies to the relevant Realm and does not automatically create a universal relationship across the Kidunaverse.

20.7 Treasury Allocations

A Realm may establish recurring or discretionary Treasury allocations for contributors such as:

• Catalysts;
• Luminaries;
• Builders;
• Creators;
• Operators; and
• other recognized Roles.

Roles may carry:

• fixed compensation;
• recurring compensation;
• bounties;
• revenue shares;
• Compute distributions;
• market-based payments; or
• other Realm-defined rewards.

21. Structural Summary

The canonical taxonomy answers these foundational questions.

Where does participation happen?

In the Field, accessed through Surfaces.

What can be entered and explored?

Realms.

Who appears and participates?

Presences.

Who provides personal agency?

Ki, the Ally.

What other software entities act?

Actors.

What do Agents know and possess?

Wisdom, Stance, Abilities, Automations, and Connections.

What appears visually?

Elements, organized within the Field, Realms, and Panels.

What creates a bounded, independently designed experience?

Scenes, entered through Portals.

What persists?

Artifacts.

What happens?

Actions.

How does a Presence participate in a Realm?

Through Roles.

Why may an Action occur?

Because of valid Authority, Permissions, Role, goal, context, visibility, and Policy.

How is information protected?

Through Privacy and Visibility.

How is reliability assessed?

Through contextual Trust.

How are collective decisions made?

Through Governance.

How are goods, services, access, and participation made available?

Through Offerings.

Where is financial value held and governed?

In Treasuries, which may contain wallets, bank accounts, or both.

How are intelligence, agency, contribution, and value paid for?

Through Compute, Treasuries, Roles, and Realm-defined economic policies.

Version 1.3.3 Canonical Boundary

Canonical clarifications added in this version

1. The Field is the complete living environment, including ongoing activity, agency, Wisdom, memory, relationships, work, and play.
2. The Field remains present as context even when a Surface does not display it continuously or spatially.
3. Realms and their authorized Agents may remain active, contribute, coordinate, respond, and request attention while a Presence is focused elsewhere.
4. Ongoing or background activity never creates authority; the same Source-of-authority, permission, policy, audit, and Record requirements apply.
5. Ki may reflect collective Wisdom only within its governing permissions and may not expose private contributions, invent consensus, erase disagreement, or become a surveillance channel.
6. A Panel may dominate attention without replacing the Field or Realm and without changing semantic containment or authority.
7. A Scene is a bounded environment used when spatial, simulated, performative, game-like, or independently visual interaction materially improves participation or understanding. It is not the Field or merely a larger Panel.
8. Portals preserve or explicitly transform relevant context and provide a defined route back.

Working design terms not made canonical

The following terms are used by the Studio design-system program but remain proposals rather than canonical taxonomy in Version 1.3.3:

• Atlas — working name for a possible broad-orientation presentation within the Field. It is not the Field and no visual form is prescribed.
• Focus — working name for the current intention or body of work organizing a Surface.
• Pulse — working name for a quiet expression of Realm activity, readiness, or constraint.
• Lens — working name for an inspection treatment that reveals deeper context, provenance, state, or authority.
• Stage — working name for a treatment in which an Element temporarily becomes the dominant work object.
• one-center shell — an accepted Studio design constraint, not a canonical Kidunaverse object.

These terms may be validated, renamed, rejected, or incorporated into a later canonical version. Their use in design documents must not imply canonical status.

Unresolved semantic questions

• Whether a broad-orientation presentation requires a canonical term distinct from the Field.
• Whether Lens and Stage are durable interaction primitives or merely presentation variants of Panels and Elements.
• How a Surface should communicate activity elsewhere in the Field without creating a dashboard or prescribing permanent navigation.
• Whether “Record” should become a distinct canonical object or remain an event-bearing Artifact or Action result.
• Whether “Program” should become a first-class Realm type rather than remain under Other Realm Types.

Change provenance

Taxonomy impact rule

Every subsequent design turn must state one of:

1. Taxonomy updated — with version, exact change, classification, provenance, and affected documents; or
2. No taxonomy change — with a short explanation of why the turn produced only evidence, proposals, or interface findings.

Prior versions remain retained as historical evidence and must not be overwritten.

2026-07-19 (third pass): v1.3.3 installed verbatim (supersedes v1.3.2 — Field always-present/not-always-visible, collective Realm agency, focused Panels and Scenes, the non-canonical design-terms boundary, the taxonomy impact rule). Source: canonical-taxonomy-v1.3.3.md. Full history: versions.