How We Build · Design · Working Foundation v0.1

Studio + Live — the Working Design Brief

The shared product model, surface responsibilities, non-negotiable principles, open questions, and the KDN decision log for the two working distances: Studio (desktop) and Live (mobile). Pairs with the Design Method and the Core Taxonomy.

← Kiduna — home Surfaces Orchestration Foundation Protocol Organizations Actions Roles Sentinel Legal Institutions Integrations
The working design test: does this surface make the Source more capable of sensing, deciding, acting, and learning — while preserving authorship, privacy, relationships, and the freedom to refuse, revoke, recover, or leave?

1. Product premise

Kiduna is a living ecosystem in which people and their intelligent Allies form relationships, enter Realms, organize collective activity, govern what they create, allocate Resources, and act with inspectable authority.

Kiduna is not organized around accounts, feeds, audiences, engagement, or conventional productivity objects. It is organized around agency: Sense. Decide. Act. Learn.

The system succeeds when increased collective capacity makes every participant more capable — without absorbing individual authorship, collapsing privacy boundaries, or silently centralizing authority.

The four foundational principles:

  1. Human direction
  2. Agentic capacity
  3. Personal privacy
  4. Legal standing

2. The shared product model

2.1 The ecosystem

The ecosystem is the complete living system: people, Allies, relationships, work, knowledge, agreements, Resources, organizations, decisions, and consequences. It is not presented as one centralized organization. Each person, relationship, Project, Community, and Organization retains its own purpose, memory, permissions, governance, and boundaries.

2.2 The Field

The Field is how the active Source perceives and navigates the ecosystem. It is continuous across Studio and Live; contextual to the active Source; spatial and relational; arranged by relevance, activity, distance, and current intention; a place for navigation, presence, proximity, exploration, capture, and action; alive with restrained evidence of ongoing relationships and work.

The Field is not: a complete graph of everything in Kiduna, a dashboard, a feed, a menu of applications, an admin console, a file browser, a surveillance view, or a permanent or identical view for every Source.

At the outermost distance, the Field contains only Realms. Entering a Realm reveals the Elements that belong within that context.

The Field is alive by default. Ki rearranges the Field continuously without explicit instruction — unless the Source instructs Ki not to. Most changes to the Field come from the activities of other Sources, Allies, and Actors, not from the acting Source: this is a fully immersive, interactive space, not a place where a separate Source occasionally publishes. Spatial position persists only where the Source actively anchors it; anything else may drift, and the Source can always ask Ki to restore something or bring it into focus.

2.3 Ki

Ki is the orchestration layer through which the Field becomes intelligible and actionable. Ki may: interpret current context; retrieve permitted knowledge; explain why something appeared; prepare reversible work; compare versions; coordinate Allies and Actors; surface relevant changes; propose Actions; inspect authority and consequence; carry out permitted Actions; withhold Actions when authority is insufficient; and help the Source recover, revoke, or reconsider.

Ki is not an Element inside the Field and does not become a character, avatar, or Realm object. Ki must remain contextual, legible, steerable, permission-bound, honest about uncertainty, honest about fixture versus live data, and subordinate to human or constituted collective authority.

Ki never refers to itself in the first person. Ki always speaks in the third person, referring to itself as Ki, never "I."

Ki is proactive by default. Ki represents and presents what is happening throughout the Field. Which signals Ki surfaces, and when Ki interrupts, slows, or withholds, is decided primarily in dialogue between Ki and the Source — a standing preference conversation, not a settings tree. The open design problem is focus: how a Source chooses to concentrate on one Element undistracted for a period, and when and how Ki may interrupt. "Why am I seeing this?" must always be answerable, and the required explanation depth is small.

2.4 Realms

Realms are bounded contexts in which relationships, knowledge, work, Resources, governance, and Actions take form. The canonical Realm types are: Organization · Alliance · Program · Project · Relationship · Community · Institution · Concept · Cell.

Realm identity is communicated by structure first and semantic color second. A parent Realm does not recolor or erase the identity of its children. Realms may overlap and exchange permitted knowledge without becoming one undifferentiated data pool.

2.5 Elements

The Field contains six first-class Element categories: Realms · Actors · Media · Allies · Resources · Actions.

A Source is the person in the data and governance model — literally the human. Their visible, Source-approved identity in the Field is their Ally. The Ally appears as an Element in the Field; the Source does not. Scenes are Media, not a separate first-class Element.

2.6 Allies and Actors

An Ally is a Source-approved visual identity of a person inside Kiduna. It is not a legal identity, a bot, a digital twin, an inferred psychological profile, or evidence of private activity.

The canonical Ally states are Open, Engaged, Focused, and Dreaming. States describe real product context and must never be inferred from biometrics, facial expression, private conversations, or hidden activity.

An Actor is an intelligent agentic presence working within a defined purpose, context, permission set, and authority boundary. Intelligence may expand capacity. It does not independently acquire authority.

2.7 Actions

A consequential Action moves through a legible lifecycle:

  1. Intention — the Source expresses a desired outcome.
  2. Draft — Ki, an Ally, or an Actor prepares reversible material.
  3. Prepared Action — the proposed consequence is sufficiently defined for inspection.
  4. Inspection — scope, changes, authority, affected parties, cost, provenance, and recovery are visible.
  5. Confirmation — the authorized Source or collective deliberately approves the exact Action.
  6. Execution — the Action is carried out within the confirmed scope.
  7. Completion or settlement — the result, cost, and state become part of the relevant Record.
  8. Recovery, reversal, or revocation — where possible, authority or consequence can be withdrawn, repaired, appealed, or reversed.

The interface must never allow a draft to appear committed or make a prepared Action look completed.

Most Actions are single-Source. Multi-Source confirmation applies only to Actions with Alliances (Squads multi-sig wallet), with Organizations (Forums and multi-sig wallets), and wherever a Community, Project, Program, or Relationship has specifically set an Action to multi-Source confirmation.

2.8 Resources and Compute

Resources provide material capacity for collective activity. $KIDUNA is prepaid Compute usage credit. It is not an investment product, a speculative asset promise, a score, a proxy for personal worth, or a leaderboard metric.

Money and Compute are shown as facts. Interfaces must distinguish: available · reserved · pending · settled · recurring · reversed · failed · fixture data · live data.

Three Resource facts stay visible on every Studio state, and the same three on Live: available Resource (units of $KIDUNA), the value of the Resource in the wallet (USD), and the current price of a single $KIDUNA in USD.

3. The role of Studio

Studio is Kiduna's desktop working distance. Its primary purpose is to help a Source understand complex context, compose work, inspect exact changes, govern shared activity, and commit consequential Actions.

Studio is appropriate for: navigating broad and nested Field contexts; understanding relationships among Realms; inspecting Records, versions, provenance, and authoritative differences; preparing and reviewing complex Actions; working with Allies and Actors; creating and configuring Realms; reviewing permissions and delegations; governance activity; grants and package acceptance; Resource allocation; recurring commitments; publication review; complex external Actions; recovery and revocation; and work requiring sustained attention.

Studio supports structured density — significant detail when clearly organized and contextually disclosed. It should feel like a living working environment, not an administrative system.

Interaction posture. Pointer, trackpad, keyboard; continuous pan and zoom; progressive spatial disclosure; exact selection; anchored Panels; detailed inspection; version comparison; multi-step confirmation. The Source-adjustable relationship between the Field and Ki defaults to approximately 70/30, with contextual variation between roughly 66/34 and 75/25. Ki remains on the right at all supported Studio widths.

4. The role of Live

Live is Kiduna's mobile human distance. Its primary purpose is to help a Source remain present, capture what is happening, coordinate relationships, make bounded decisions, prepare work offline, and carry complex work safely into Studio.

Live is appropriate for: immediate orientation; current-Realm context; presence; relationship awareness; voice, text, photo, and Media capture; short contextual conversations with Ki; simple check-ins; lightweight coordination; bounded approvals; offline preparation; reconnection and recovery; monitoring previously confirmed work; and deferring complex inspection to Studio.

Live can confirm most consequential Actions. Many Sources will never use Studio, and the product must be whole for them. The design question is inverted from the usual mobile framing: the list of Actions that can only be performed in Studio must be very small — possibly empty — and anything on it must earn its place (the working criterion: a decision that cannot be adequately inspected on a small screen). What Live avoids is not consequence but density: full Studio workflows, dense multi-object comparison, complex grants and package acceptance, detailed governance, multi-stage authority configuration, complex Resource allocation, and ambiguous external commitments.

Live makes the immediate context clear without becoming a notification feed or engagement surface.

Interaction posture. Touch, voice, mobile keyboard, camera and Media capture; one-handed use; short and interrupted sessions; poor or absent connectivity; explicit continuation in Studio. The Field remains present; Ki is expressed as a collapsible bottom sheet or equivalent touch-native layer. Primary orientation is portrait, with an optional horizontal mode for consuming Media and navigating the Field — particularly strong in voice mode. Tablet is a later bridge surface, not part of the Live release scope.

5. The relationship between Studio and Live

Studio and Live share: the same Field, the same Ki, the same Realm structure, the same identities, the same Actions, the same authority model, the same privacy boundaries, the same provenance, the same Resource facts, and the same state of work. They do not need to display the same amount of information or offer the same authority.

A cross-surface handoff preserves: current Realm; Realm ancestry; selected Element; draft or prepared Action; evidence already inspected; provenance; privacy classification; authority requirements; offline state; Compute or monetary consequence; and the exact next step. "Continue in Studio" opens the relevant context, never a generic landing state. Starting an Action on Live grants no additional authority when the Action reaches Studio.

6. Persona commitments

Every important workflow is evaluated against all four patterns.

Alice inspects before acting. Prioritize: exact changes, explicit authority, version comparison, recurrence, pending versus settled state, reversible preparation, calm structured density. Primary failure risk: stale or unclear authority.

Bob talks before summarizing. Prioritize: people and relationships, invitations, role agreements, clear distributions, care without surveillance, separate respectful outreach, aggregate participation rather than private activity. Primary failure risk: leaving someone behind, or turning care into monitoring.

Carol explores before confirming an exact version. Prioritize: voice, generative conversation, versioned Media, provenance, attribution, recognition, a clear transition from play or proposal to public commitment. Primary failure risk: lost attribution or accidental publication.

Danny prepares, verifies, and then commits. Prioritize: offline operation, low-noise presentation, explicit classification, sharing boundaries, recovery, Compute ceilings, reserved versus consumed cost, portable work. Primary failure risks: oversharing, failed recovery, unclear offline state.

7. Non-negotiable design principles

7.1 Human authority is inspectable

The system can always show: who is acting; whom they represent; what authority they hold; what permission is being exercised; what still requires confirmation; and what Ki or an Actor cannot do. Intelligence may recommend or prepare; it cannot silently convert capacity into authority.

Authority does not have to remain visible at all times. This is not an auditing system — it should feel natural, and in many places we want fun and suspension of disbelief. The interface stays uncluttered; what is guaranteed is that a Source can always discover and inspect the authority behind anything.

7.2 Privacy is architectural

Information remains bound to its context. Public information may circulate openly. Private information moves by permission. Secret information cannot be discovered unless deliberately revealed. Personal information remains with the individual for whom it is held. Participation in one Realm does not silently expose activity in another.

Privacy must not get in the way of usability. Private information is typically private to a Realm — inside that Realm, it is simply present. In a secret Realm, the secret information is present. Personal information is always present to you. Permissions are inspectable, but they are not obvious on the surface.

7.3 Influence is inspectable

A Source can determine: why something appeared; what information informed it; which Actor proposed it; whose purpose is being served; and what will happen if they agree. The Source can question, pause, revoke, appeal, recover, leave, or turn off an intervention wherever the product model permits it.

7.4 Care must not become control

Never: manufactured urgency, infinite feeds, engagement pressure, retention mechanics, follower counts, scores, rankings, grades, leaderboards, behavioral targeting, hidden personalization, inferred vulnerability, or inferred emotional state.

7.5 One clear next move

A state may contain substantial context, but it presents one visually dominant next Action. Suggested prompts remain quiet and conversational; they never compete with the primary Action.

7.6 Consequence before confirmation

Before confirmation, show: the exact Action; the affected Realm; affected people or systems; material changes; non-changes when relevant; authority; required confirmations; Compute or money effect; external versus simulated execution; reversibility and recovery.

7.7 Truth over spectacle

Never invent: presence, activity, authority, balances, private context, emotional state, live data, or completed execution. Fixtures and simulations are labeled honestly.

7.8 Accessibility is part of agency

All meaningful interactions support: visible keyboard focus; screen-reader names; non-color status communication; reduced motion; large text; sufficient contrast; pointer, keyboard, trackpad, and touch equivalents where relevant; and focus restoration after dismissal or navigation.

8. Known visual-system constraints

8.1 Aesthetic

Deep. Warm. Magical. Alive. The interface is dark-native, materially warm, spatially deep, and quietly luminous. It must not feel cold, sterile, corporate, neon, glossy, gamified, futuristic for its own sake, or visually muddy.

8.2 Color

Studio Field ground: near-black deep umber, canonically #0A0604. General deep-umber brand ground: #1C140D. Cream white carries primary readable hierarchy; pure white is never used. Sky blue signals action, navigation, continuity, and consequence. Sun gold signals Resources and significant institutional material. Camel provides warm structure; moon cream provides highlight and symbolic light; mint is rarer and relational. Realm hues retain their semantic identity.

Broad blue-green, brown, or decorative gradient washes never cover the Field — color remains localized around meaningful objects and relationships. But don't be stingy with color: the Field should feel alive and magical, with hints of color frequently drawing attention toward a significant item on a periphery or something brought into focus.

The primary brand colors: Sky Blue #03CCD9 · Sun Gold #EAAA00 · Moon Cream #FFF6D5 · Camel #C19A6B · Chocolate #6F4A2E · Dark Umber #4E3629 · Espresso #1C140D · Aubergine #2A1A2B · Mint #8FE6C6 · Cream White #FFFFE6 · Cream #F9DDB7 · Gold (warning) #FFCA05 · Black #1E1F20 · Grey #9094A3.

The extended ranges — Violets: Violet Deep #3F2270, Violet #6536BB, Violet Bright #9D7BE8, Lilac #D6C7F2. Greens: Forest #1F4D38, Green #2F8C63, Jade #57C08F, Sage #BCD3A6. Oranges: Ember #A94E1C, Orange #D97B2E, Apricot #F0A85C, Peach #F8D6AA. Blues: Midnight #14203E, Indigo #33478F, Blue #2FB4E0, Powder #ABDCE8.

The full token set, preview cards, and worked examples are the design system in _ds/ (README), also packaged in downloads.

8.3 Typography

Goudy Heavyface for display; Avenir for interface and body; IBM Plex Sans for callouts. Numbers use Goudy Heavyface. Display emphasis may use one sun-gold phrase per headline — never italicize headlines or parts of headlines. Dense interfaces use restrained hierarchy rather than excessive type variation.

8.4 Realm identity

Realm identity uses: circular celestial-enamel chassis; warm-metal double rim; dark core; canonical type crest; semantic enamel hue; localized halo; anchors and orbit structure; progressive simplification at small sizes. Canonical crests are never replaced by emoji, Lucide icons, generic outline symbols, or font icons. Where older visual grammar conflicts with the newer Studio Enamel canon, the enamel canon controls visual expression while established interaction semantics remain intact.

8.5 Field behavior

Field pan responds directly; wheel and pinch zoom around the gesture center; fixed chrome does not scale with the Field; labels move with their objects; disclosure changes progressively; selection and threshold remain distinct states; Field arrangement remains stable enough to preserve orientation; motion remains local and meaningful.

8.6 Motion

Studio motion verbs: breathe · relate · gather · drift · approach · threshold · settle. Motion communicates context, activity, or change; it does not decorate the whole interface. Reduced-motion mode preserves all information without movement.

8.7 Connections

Studio may use: orbit, tether, braid, confluence, anchor, crossing, threshold, constellation, echo. Live uses a simplified vocabulary: straight camel line for resting relationship; mint dotted line for presence; sky line for consequence in motion; gold line or bead for Compute movement. Connections express a real relationship, never atmospheric decoration.

8.8 Studio layout

Field on the left; Ki on the right; approximately 70/30 default relationship; fixed orientation and Compute; selected Realm Panel anchored near the Realm; at least part of the selected object remains visible; only Realms appear at the outermost Field distance.

8.9 Live layout

The Field remains present; Ki uses a bottom sheet or touch-native layered expression; labels sit below spatial nodes; controls use at least 44px targets; filled glyphs remain legible at small sizes; Media stays within enamel tiles; complex Studio interactions are not compressed into mobile layouts. Portrait primary, with the optional horizontal mode for Media and Field navigation.

9. Rulings in force and what stays open

The questions this brief opened have been worked; the rulings below are in force. What remains genuinely open is queued, with context, on Open Questions.

Product scope. Live can confirm most consequential Actions — the Studio-only list must be very small, possibly empty, and each entry must earn its place. Tablet is a later bridge surface. Still open: the required Studio and Live journeys for first release, and whatever tiny Studio-only Action list survives scrutiny.

Field and navigation. Ki rearranges the Field by default; the Source can instruct otherwise; most Field change comes from other Sources, Allies, and Actors. Spatial persistence requires active anchoring; Ki restores on request. Still open: the default Field context on return; distinguishing current relevance from lasting structural importance; how Live preserves the Field's spatial character without desktop-style navigation.

Ki. Proactive by default; surfacing and interruption thresholds are set in dialogue between Ki and the Source; "why am I seeing this?" needs very little depth; disagreement presentation extends to Actors and Allies. Still open: the focus-protection design — how a Source concentrates on one Element and when Ki may interrupt.

Authority and confirmation. Most Actions are single-Source; multi-Source only for Alliances, Organizations, and Realms that set it explicitly (§2.7). Still open: the product vocabulary distinguishing prepared, confirmed, executing, and settled; representation of expiring, delegated, partial, or contested authority; practical reversibility windows; the escalation path when automatic recovery fails.

Privacy. Realm-scoped presence of private and secret information; personal information always present to its person; permissions inspectable, not surface-obvious (§7.2). Still open: member-selectable classifications; Realm-inherited classifications; conflict resolution; audit information without exposing protected context; communicating that an absence is a boundary, not a loading failure.

Offline. Open: which Media and Records may be stored locally; which classifications prohibit offline storage; which Actions may be prepared offline; sync-conflict resolution that never silently overwrites authority or provenance; security and recovery for a lost device.

Resources. The three always-visible facts (units of $KIDUNA · wallet value in USD · current $KIDUNA price in USD) apply to Studio and Live alike (§2.8). Still open: confirmations before Compute or money moves; the source of truth for live/delayed/estimated/fixture status; surfacing recurring commitments without financial anxiety or artificial urgency.

Platform and accessibility. Studio and Live are both native Flutter/Flame; each "web version" is the same Flutter/Flame application served for remote or limited use. Still open: minimum supported desktop width; required mobile operating systems and accessibility APIs; whether WCAG 2.2 AA is the formal baseline and whether anything exceeds it.

Validation. All taxonomy and interaction ratification goes through the product owner, working directly with the design collaborators. Still open: which real participant groups validate the four persona patterns; which governance, privacy, legal, and accessibility experts review consequential Actions; what evidence promotes a pattern to canonical.

10. The decision log

Every material decision receives a stable identifier (KDN-nnn) and a record with these fields: Decision ID · Date · Title · Status · Category (product, taxonomy, interaction, visual, privacy, authority, accessibility, engineering) · Context · Source material · Options considered · Decision · Rationale · Affected surfaces · Affected personas · Privacy impact · Authority impact · Accessibility impact · Taxonomy impact · Reversibility · Validation evidence · Owner · Revisit trigger.

The lifecycle: Proposed (a direction exists but is not approved) → Accepted (approved for design exploration) → Validating (represented in a prototype or research study) → Validated (supported by sufficient evidence for implementation), with Rejected (considered and deliberately not chosen) and Superseded (replaced while preserving the historical rationale).

The initial decisions:

IDDecisionStatus
KDN-001Studio is the desktop surface for complex understanding, composition, inspection, governance, and commitment.Accepted
KDN-002Live is the mobile surface for presence, capture, coordination, simple approvals, offline preparation, and deferral to Studio.Accepted
KDN-003The Field and Ki remain continuous across both surfaces.Accepted
KDN-004Live will not reproduce the full Studio interaction model.Accepted
KDN-005Studio will not adopt a dashboard, admin-console, file-tree, or feed model.Accepted
KDN-006Consequential Actions require inspectable scope, authority, consequence, cost, and reversibility.Accepted
KDN-007Alice, Bob, Carol, and Danny are mandatory behavioral review fixtures.Accepted
KDN-008Established taxonomy remains canonical unless a change is explicitly proposed and ratified.Accepted
KDN-009Newer Studio Enamel visual canon takes priority where older visual references conflict.Accepted
KDN-010Engagement, scoring, ranking, inferred emotion, false presence, and surveillance patterns are prohibited.Accepted

11. The working design test

Every Studio and Live concept is evaluated with one question:

Does this surface make the Source more capable of sensing, deciding, acting, and learning while preserving authorship, privacy, relationships, and the freedom to refuse, revoke, recover, or leave?

If the answer is unclear, the design is not ready to advance.


Changes: v0.1 installed 2026-07-26 as the working foundation for all Studio and Live design; its rulings folded here and into Taxonomy v1.3.7, Open Questions, and the Design Method. Full history: versions.