# Kiduna Studio Prototype V0 — Approval Scope

**Status:** Proposed Gate 1 scope; implementation has not begun  
**Prepared:** 2026-07-17  
**Branch/worktree:** `agent/kiduna-studio-v0` at `/Users/moto/Documents/Kidunaverse/work/2026-07-17-kiduna-studio-v0`  
**Baseline:** `63bb38006ecfb7a579042ea95dd0dcabcc9bb18d`

## 1. Authorization and source hierarchy

The owner’s 2026-07-17 `/goal Build, validate, archive, and deploy…` instruction explicitly authorizes a scoped prototype after Gate 1 approval. It supersedes only the earlier “implementation not authorized” status in `PROJECT_BRIEF.md`, Decision D-031 and Document 08 §11. It does not supersede any privacy, authority, simulation, provenance, terminology, economic-conflict or acceptance boundary.

Authoritative inputs, in order:

1. The current `/goal` and subsequent owner decisions.
2. `/Users/moto/Documents/Kidunaverse/work/2026-07-17-kiduna-studio-definition/DECISION_REGISTER.md`.
3. The Definition Pack models, journeys, interaction specification and acceptance contract.
4. The 282-row capability catalog and pinned source evidence.
5. Existing prototype behavior as implementation evidence, never as authority over the Definition Pack.

The Definition Pack itself remains unchanged during this prototype branch. New decisions or discovered contradictions are recorded here and in the prototype’s review evidence until a separately authorized canon/pack revision.

## 2. V0 outcome

V0 is one connected, high-fidelity browser design lab in which David and Matt can move through:

`personal Ally → mediated Relationship → shared Project → sourced Formation Package → independent exact-version acceptance → simulated authorization → simulated treasury purchase → Organization activation → simulated registry Record`

The experience is a web application with the presence and continuity of a desktop application. The Field remains the interface; conversation, spatial objects and object-linked state carry the work. V0 is not a dashboard, static screen gallery, production backend replacement or claim that the entire Studio catalog is functional.

## 3. Release boundary

| Priority | Meaning for this prototype | Review promise |
|---|---|---|
| P0 — demonstrated | Functional, deterministic behavior required for the first preview and production candidate | Runs through the three connected journeys in independent David/Matt sessions; selected exceptions and all P0 tests have evidence |
| P1 — represented now, demonstrated later | Visible and honestly described in V0, but not required to be a complete working path in the first preview | Remains traceable in the capability atlas and backlog; receives later functional/test iteration |
| Deferred/catalog-only | Part of complete Studio 1.0 or another product surface, but intentionally absent from V0 behavior | Never implied functional; rationale and source/status remain inspectable |

No catalog capability disappears. Each of the 282 rows must be labeled `demonstrated`, `represented`, or `catalog-only` in the V0 capability atlas.

## 4. P0 connected experience

### Journey 1 — Relationship to collaboration

V0 demonstrates:

- separate David and Matt sessions;
- private Ki Genesis conversations that produce separately confirmed Ally identities and Stance versions;
- the five persistent anchors and Clear/Context/Focus rests;
- Find/approach bringing Matt near without creating a Relationship;
- direct-feeling conversation with visible David Ally → Matt Ally mediation when it matters;
- a purpose- and scope-limited approach, acceptance/decline and protected rationale;
- a safe unregistered-person invitation/Code path, including prospect-not-Persona and expired/mismatched Code behavior;
- reversible Gather of approved Service Alliance Sources;
- explicit sharing/grant confirmation with public/private/secret/personal treatment;
- a Relationship in Kinship Duna with separate trust, grants and authority;
- a Project invitation and Matt’s independent acceptance of role/grants;
- a shared Service Alliance Formation Project as the actual input to Journey 2.

### Journey 2 — Shared Project to accepted artifact

V0 demonstrates:

- compatible but permission-filtered Project projections in two sessions;
- asynchronous handoff and synchronous overlap without cursor surveillance;
- Source provenance, permissions, current/historical/conflicted status and reversible Incoming Material;
- one coherent Service Alliance Organization Actor with inspectable internal contributions;
- Project Compute allocation, estimate, reservation, consumption, release, limits and low-Compute behavior;
- deterministic Actor progress, cancellation/failure, partial output and Source-revocation behavior;
- Formation Package v0.1, human/Actor contributions, a requested change and successor v0.2 diff;
- immutable version identity, hash, citations, permissions, Compute and unresolved variables;
- David and Matt independently accepting the same exact v0.2;
- “accepted” as an authoritative but explicitly non-executing state that becomes Journey 3 input.

### Journey 3 — Accepted artifact to consequential action

V0 demonstrates, entirely in simulation:

- launch request preparation from the exact accepted Formation Package;
- exact consequence previews, authority chain, parameters and non-effects;
- Kinship Duna authorization kept separate from founder acceptance;
- changed authorization parameters invalidating prior confirmation as required;
- treasury purchase authorization kept separate from launch authorization;
- pending and settled simulated Compute purchase with balanced ledger evidence;
- legal-evidence verification and Organization activation as another distinct truth;
- registry submission and settlement as another distinct truth;
- partial completion where purchase settles and registry fails;
- uncertain outcome, idempotent retry, reconciliation and immutable/superseding Records;
- a final Field projection linking Service Alliance, Kinship Duna, founders, Project, Sources, Compute and Records.

## 5. P0 capability families

The functional slice is governed by these catalog families. A listed range does not mean every row in the range is functional; the per-row atlas classification remains authoritative.

| Family | P0 functional emphasis | Representative catalog trace |
|---|---|---|
| Persona and Ally | Separate Personas; Ki Genesis; one Source-directed Ally each; confirmed Stance | `ID-010`, `ID-013–016`, `AG-001–004` |
| Invitations and Relationships | Purpose-limited approach, Code safety, delivery control, Relationship, trust/grants | `REL-001–018`, selected exception behavior from `REL-021–022` |
| Project and collaboration | One accountable Organization, roles, Sources, async/live work, object-linked Attention | `PRJ-001–029`, `COL-001–014` as journey-relevant |
| Sources and artifacts | Incoming Material, privacy, provenance, citations, immutable versions, review and acceptance | `SRC-001–019`, especially `SRC-004–013` and `SRC-015–019` |
| Actors and orchestration | Unified Organization Actor, typed contributors, visible scope, deterministic progress/failure | `AG-005–010`, `AG-016–018`, `AG-025–029` |
| Compute | Balance, Project allocation, reservation, use, attribution, limits and simulated treasury purchase | `CMP-001–015`, `CMP-023–025`; disputed fields constrained below |
| Organization and authority | Formation Package, authorization, simulated treasury action, verified status and registry | `ORG-003–012`, `GOV-010–014` as needed by J3 |
| Field and conversation | Three distances, three HUD rests, five anchors, Gather, conversation and exact Commit objects | `UX-001–026` as selected by P0 tests |
| Records and safety | Default deny, exact Commands, sovereign gates, simulation isolation, Records and recovery | `SYS-001–015`, `SYS-019–020`, `SYS-024`, `SYS-026` as journey-relevant |
| Service Alliance grounding | Support, Connection, History and eight programs visible in context/atlas; formation is the deep path | `DOM-013–025`; only formation-related behavior is deeply demonstrated |

## 6. Inherited requirements versus V0 proposals

| Status | Requirement or choice | V0 treatment |
|---|---|---|
| Inherited | The whole screen is the Field at Constellation, Relational Terrain and Living Workbench distances | Required P0 behavior; Field remains visible in Focus |
| Inherited | Clear, Context and Focus are HUD rests rather than pages or application modes | Required P0 behavior |
| Inherited | Member, Organization, Community, Forum, Relationship, Ally, Actor, Source, Project, artifact and Wisdom are current nouns | Required Member-facing vocabulary; historical terms remain provenance only |
| Inherited | One Source-directed Ally per Persona; Ally and Actor are distinct structural families | Required identity, speech, authority and inspection behavior |
| Inherited | Public/private/secret/personal, with authorization before retrieval | Required P0 privacy behavior and Source-revocation fixture |
| Inherited | Language captures intent; only exact typed and authorized consequential acts change state | Required P0 Action/confirmation/Record behavior |
| Inherited | Every Project and consequential Action resolves to one accountable Organization | Kinship Duna remains accountable through formation; Service Alliance status changes truthfully |
| Inherited | Accepted artifact versions and Records are immutable; correction supersedes | Required v0.1/v0.2, exact acceptance and recovery behavior |
| Inherited | Compute is prepaid usage credits powering intelligent agents | Required core language; no ticker, yield, investment or invented-market presentation |
| Inherited | Every spatial action has keyboard, screen-reader, reduced-motion and non-spatial equivalents | Required P0 completion path |
| Owner direction | Five anchors: Self/Ally, context, Compute, Attention and Find | Required P0 HUD |
| Owner direction | Four action classes: Navigate, Gather, Ask and Commit | Required P0 interaction grammar; representative-tester comprehension result is P1 |
| Owner direction | Direct-feeling person/Organization conversation with light Ally mediation | Required P0 design test; not declared resolved until reviewed |
| Owner direction | One coherent Organization Actor with inspectable internal delegation | Required P0 Service Alliance behavior |
| Owner direction | David and Matt in separate synchronized sessions across three deep journeys | Required P0 narrative and acceptance spine |
| Owner direction | Dark espresso, rich, mysterious, magical, friendly and beautiful in one Kidunaverse | Required P0 visual review, with bounded Service Alliance identity |
| Owner direction | Ambient and inspectable Compute with allocations, attribution and safeguards | Required P0 within C-001 constraints |
| Owner direction | Service Alliance as the primary worked example across Support, Connection and History | Deep formation behavior plus represented program breadth |
| V0 staging proposal | First production candidate gates on 64 tests and 15 fixtures; 11 tests and five fixtures follow in P1 | Requires Gate 1 owner approval; no source test is deleted |
| V0 staging proposal | Capability atlas accounts for all 282 rows without putting breadth into the canonical journey | Requires Gate 1 owner approval |
| V0 staging proposal | Use isolated deterministic state rather than the archived prototype’s production database | Requires Gate 1 owner approval; protects private data and replayability |

## 7. P0 acceptance contract

The source acceptance contract currently contains **75 identifiable test rows**. The Definition Pack audit says 72; that count mismatch is a recorded internal contradiction and is not silently corrected here. V0 selects 64 tests for the first production candidate and carries 11 into P1.

| P0 test family | Included test IDs |
|---|---|
| Breadth and narrative | `AT-COV-01`, `AT-JRN-01`, `AT-SA-01` |
| Field, HUD and Gather | `AT-UX-01`, `AT-UX-02`, `AT-UX-04`, `AT-UX-05`, `AT-UX-07`, `AT-HUD-01`, `AT-GAT-01`, `AT-GAT-02` |
| Allies, Actors and mediation | `AT-AG-01`, `AT-AG-02`, `AT-AG-03`, `AT-AG-04`, `AT-SEC-01`, `AT-SEC-02` |
| Invitations, Relationships, privacy and baseline safety | `AT-INV-01`, `AT-INV-02`, `AT-REL-01`, `AT-REL-03`, `AT-REL-04`, `AT-PRIV-01`, `AT-PRIV-03`, `AT-PRIV-04`, `AT-SEC-04`, `AT-SEC-05`, `AT-SEC-06` |
| Project, collaboration and artifacts | `AT-PRJ-01`, `AT-COL-01`, `AT-COL-02`, `AT-COL-03`, `AT-COL-04`, `AT-ART-01`, `AT-ART-02` |
| Action, sovereignty and Records | `AT-ACT-01`, `AT-ACT-02`, `AT-ACT-03`, `AT-ACT-04`, `AT-SOV-01`, `AT-SOV-02`, `AT-SOV-03`, `AT-REC-01`, `AT-REC-02` |
| Compute | `AT-CMP-01`, `AT-CMP-02`, `AT-CMP-03`, `AT-CMP-04`, `AT-CMP-05` |
| External operations and simulation | `AT-EXT-01`, `AT-EXT-02`, `AT-EXT-03`, `AT-SIM-01`, `AT-SIM-02`, `AT-SIM-03` |
| Organization | `AT-ORG-01`, `AT-ORG-02` |
| Visual, motion and accessibility | `AT-VIS-01`, `AT-VIS-02`, `AT-VIS-03`, `AT-MOT-01`, `AT-A11Y-01`, `AT-A11Y-02`, `AT-A11Y-03` |

P0 also inherits the browser/viewports, input modes and performance budgets in Document 08 §6. Quantitative comprehension tests that require representative human participants are evaluated during owner/engineering review; they cannot be claimed from automated checks alone.

## 8. P0 deterministic exception fixtures

The first production candidate includes 15 of the 20 named fixtures:

1. `recipient-declines-approach`
2. `code-expired`
3. `code-recipient-mismatch`
4. `private-source-overshare`
5. `project-low-compute-before-start`
6. `actor-limit-mid-run-partial`
7. `source-revoked-mid-run`
8. `actor-tool-timeout`
9. `stale-version-acceptance`
10. `second-founder-declines`
11. `authorization-changes-parameters`
12. `purchase-succeeds-registry-fails`
13. `external-outcome-uncertain`
14. `duplicate-submit-retry`
15. `prompt-injection-source`

Each fixture must declare the initial seed, injected event, expected David/Matt projections, Compute/ledger result, Records and valid recovery actions.

## 9. P1 after the first production candidate

The following 11 acceptance tests remain part of the approved Definition Pack but are not a first-preview production gate:

- `AT-UX-03` — full five-layer inspection on all sampled node families;
- `AT-UX-06` — context/Organization crossing during background work;
- `AT-ACT-05` — representative-tester comprehension of all four action classes;
- `AT-SEC-03` — exhaustive Actor out-of-manifest Source/tool/Command denial;
- `AT-REL-02` — representative-tester three-axis registration/trust/privacy comprehension;
- `AT-PRIV-02` — deterministic secret inference resistance across results/counts/errors/timing;
- `AT-MOD-01` — complete object distinction across Relationship, Community, Alliance, Project, Engagement and Institution;
- `AT-INT-01` — functional live-link/snapshot and external read/comment/edit proof anatomy;
- `AT-CMP-06` — full outside-context Compute behavior;
- `AT-CMP-07` — eligible settled-purchase lineage behavior;
- `AT-GOV-01` — equal ballot versus funded-position behavior.

The five remaining named fixtures are P1:

- `recipient-offline-reconnect`;
- `actor-low-confidence-conflict`;
- `treasury-threshold-declined`;
- `purchase-settlement-fails`;
- `offline-during-confirmation`.

P1 does not waive these tests from the complete prototype contract. It prevents them from delaying the first coherent experience review.

## 10. Represented and catalog-only breadth

V0 represents but does not functionally complete:

- the wider Kidunaverse Constellation and other Organizations;
- the full Service Alliance Support, Connection and History program workflows;
- Forums and Policies beyond the simulated launch-authorization path;
- Organization effectiveness, supply/demand, Agency Premium aggregation and disputed economic concepts;
- voice/audio channels;
- other DomainPackages, games, Scenes, websites and software-building workflows;
- administration and operations beyond design-lab evidence;
- all catalog rows marked `R` or `—` that are not explicitly demonstrated by P0.

The capability atlas is an honesty and orientation surface, not a backlog dashboard inside the canonical Field journey.

## 11. Explicitly deferred or prohibited

- Production authentication, authorization, compliance, scalability or backend migration.
- Changes to the four Kinship repositories.
- Production database exports as prototype seed data.
- Real email, SMS, push or contact with unregistered people.
- Real payments, wallets, exchange, treasury movement, signatures, votes, legal agreements, filings, registry writes, publishing or deployment triggered from inside the prototype.
- Live AI output as a gating journey dependency; deterministic agent fixtures govern acceptance.
- Production secrets, raw credentials, private deployed Relationship Wisdom or unapproved likeness material.
- Final engineering handoff ZIP, final `AGENTS.md`/`CLAUDE.md` package or reusable Skills.

GitHub and Vercel deployment of the design lab itself is authorized by the `/goal`; “deployment” above refers to simulated Member-facing Studio Actions and third-party consequences inside the experience.

## 12. Seed-data and unresolved-input treatment

| Open item | V0 treatment unless the owner supplies approved input |
|---|---|
| David/Matt Ally names and appearance | Begin unnamed; each session produces and explicitly confirms a deterministic neutral proposal during Genesis |
| Formation Package | Clearly labeled simulated schema and prose; never presented as a legal instrument |
| Launch min/max, Compute multiple, lineage and treasury amount | Named variables in consequential previews; never plausible invented values |
| Kinship authorization policy | Clearly labeled simulated policy with exact fictional authority path |
| West Virginia ID | Visibly synthetic identifier; never a claim of registration |
| Recognition Market | “Recognition workflow” in current copy; historical term only in provenance |
| Matt biography/avatar | Public/owner-provided professional context plus synthetic private fields; consistent illustrated fallback until likeness is explicitly approved |
| Voice | Voice-compatible interaction only; no functional voice in V0 |
| Organization effectiveness | Non-calculating proposed outcome dimensions; no Member rank or financial multiple |
| Cross-Organization activity | Quiet represented signal; full behavior remains P1 |

All seed data is labeled `public`, `owner_approved`, `synthetic` or `simulated`.

## 13. Active contradictions and prototype treatment

| Conflict | V0 treatment | Not silently decided |
|---|---|---|
| C-001 Compute/economics | Functional simulated prepaid-credit balance/allocation/reservation/use ledger; USDC-equivalent location remains visible but says unavailable/pending approved policy unless an approved simulated quote is supplied | Supply/demand, investment meaning, effectiveness, live lineage and market behavior |
| C-002 directness/mediation | Matt or the Organization remains perceptual focus; light mediation cue expands to full chain when filtering/authority matters | Whether this achieves both felt directness and correct understanding; owner/tester review decides |
| C-003 historical terminology | Current Studio nouns in Member copy; historical language only in source/provenance views | Recognition Market’s eventual canonical name/semantics |
| C-004 one universe/Service Alliance identity | Shared espresso Field, node/action/avatar grammar; bounded bronze/navy/insignia atmosphere | Final token limits pending visual review |
| C-005 real identity/privacy | Approved public facts and synthetic private data; no production-derived Wisdom | Matt likeness and biography approval |
| Acceptance-count mismatch | Source acceptance table currently contains 75 IDs while audit documents say 72 | The Definition Pack count is flagged for later correction; no tests are dropped to force 72 |

## 14. Missing evidence and non-claims

The following evidence does not yet exist or is not approved. V0 uses the stated safe default and never presents the missing item as fact.

| Missing evidence | Effect on V0 | Blocking point |
|---|---|---|
| Approved David/Matt Ally names, appearances and initial Sources | Genesis produces deterministic neutral proposals that each Persona confirms | Owner review may replace them before production promotion |
| Explicit Matt likeness/biography approval | Use limited approved professional context and a consistent synthetic illustrated fallback | Before any real likeness is published |
| Authoritative Service Alliance Formation Package/legal language | Use a clearly simulated package schema with unresolved variables | Before any legal or production use; not required for design-lab behavior |
| Approved launch min/max, Compute multiple, lineage, treasury amount and authority policy | Keep named variables and simulated policy; no invented plausible values | Before functional economic semantics or real consequence |
| Approved WV Organization ID/display permission | Use a visibly synthetic ID | Before any verified public claim |
| Approved USDC-equivalence policy/quote source | HUD location stays visible but displays unavailable/pending approved policy | Before a numeric equivalent may appear |
| Representative five-person comprehension results | Record only after the preview is testable | Before claiming `AT-ACT-05`, `AT-REL-02` or broader comprehension success |
| Complete private-data retention instruction for the current production database | No database dump was made; code/schema/deployment are archived | Gate 1 owner must accept this boundary or provide secure backup instructions |
| Consistent Vercel domain-inspection result | Deployment metadata proves current aliases and source commit; one CLI domain-inspection path returned an access error | Reverify before Gate 3 production promotion |
| Reconciled acceptance-test count in the Definition Pack | V0 recognizes all 75 table IDs and flags the audit’s “72” count | Later Definition Pack correction; no V0 test is removed |

The current Vercel production deployment is now pinned to GitHub commit `63bb38006ecfb7a579042ea95dd0dcabcc9bb18d` through deployment metadata, resolving earlier source-register uncertainty for the archived build without rewriting the Definition Pack.

## 15. Deployment and data boundary

- The archived V1 commit and current Vercel production deployment remain untouched during V0 implementation.
- V0 work occurs only in `agent/kiduna-studio-v0` until review.
- The first external deployment is a Vercel preview from the V0 branch.
- `kiduna.design` promotion occurs only after explicit owner approval at Gate 3.
- V0 uses isolated deterministic prototype state and must not write into the existing production prototype database.
- The source/schema/deployment of V1 is archived. A production database dump is deliberately not part of the archive because it may contain private account and invitation data; a separate secure retention decision is required if the owner intends “archive” to include that data.

## 16. Measurable Gate 2 completion criteria

Before asking for preview review:

- the three journeys run twice from deterministic reset without hidden setup;
- David and Matt use independent sessions and cannot act as one another;
- all 64 P0 acceptance tests have recorded pass/fail evidence;
- all 15 P0 fixtures reproduce their expected projections, ledger outcomes, Records and recovery;
- all 15 required interaction state plates are captured, including structured/reduced-motion equivalents;
- at least 90% of happy-path actions originate in the Field, conversation or contextual objects;
- every sovereign act is explicit, exact-version/parameter bound and simulation-labeled;
- lint, production build and relevant automated/browser checks pass;
- Chrome, Safari and Firefox desktop walkthroughs complete, with responsive resilience at specified viewports;
- keyboard-only, reduced-motion and structured non-spatial journeys complete;
- no production rail, secret, private deployed Wisdom or existing database write is reachable;
- the capability atlas accounts for all 282 catalog rows without implying functional completeness;
- the branch is intentionally committed and pushed, and a Vercel preview is available;
- failures, P1 items, open decisions and Definition Pack contradictions are reported rather than hidden.

## 17. Gate 1 approval questions

Approval to begin implementation confirms:

1. The 64-test/15-fixture P0 boundary is the right first production candidate.
2. The 11 tests and five fixtures listed as P1 may follow after first-preview review.
3. The unresolved data inputs use the safe defaults in §12.
4. V1 archival is accepted as source/schema/deployment archival without a private production database dump, or the owner will provide a secure retention destination and data-handling instruction.
5. V0 may use the existing GitHub/Vercel project for preview deployment while `kiduna.design` remains on the archived production build until Gate 3.
