# Gate 2 Activation Prompt

Use the prompt below on the next turn to begin Gate 2A. It deliberately starts with taxonomy reconciliation and Realm behavior, not interface production.

## Copy-ready activation prompt

> Gate 1 is accepted. Activate Gate 2A — Realm Intelligence and Collective Agency. Do not begin Gate 2B or production engineering.
>
> ### 1. Read and establish the evidence base
>
> Before acting, read:
>
> - `START_HERE.md`
> - `DECISION_LOG.md`
> - `OPEN_DECISIONS.md`
> - `CONTRADICTION_REGISTER.md`
> - `WORKING_PLAN.md`
> - `REALM_EXPERIENCE_MODEL.md`
> - `DESIGN_EXPERIMENTS.md`
> - the complete `references/canonical-taxonomy-v1.3.2.md`
> - the applicable `design-kiduna-realm` skill and its complete Realm Intelligence Contract
> - `/Users/moto/Documents/Claude/Projects/Kidunaverse/Dragoon Base 2nd Cavalry Trooper_Veteran_Connection_Concept_Paper.docx (1).pdf`
> - `/Users/moto/Downloads/SADUNA_Backbrief_for_David_2.docx`
> - `/Users/moto/Documents/Claude/Projects/Kidunaverse/Service Alliance Market Research and Opportunity Report.docx`
> - `/Users/moto/.codex/attachments/4f4570b4-509a-4e09-9564-6fb5ea7ada00/pasted-text.txt`
>
> Inspect the supplied PDF and DOCX files completely, including their visual structure. Record each source with filename, document title, stated date or status, confidentiality, page count, file hash or other stable local version identifier, and inspection date. Preserve the `CONFIDENTIAL` status of the SADUNA backbrief. Do not expose confidential planning in public-facing scene briefs or treat it as settled public fact.
>
> Classify every material assertion as one of:
>
> 1. **Canonical inherited requirement** — supported by the accepted taxonomy or decision log.
> 2. **Accepted design decision** — approved at Gate 0 or Gate 1 but not necessarily canonical taxonomy.
> 3. **Source-backed domain evidence** — supported by a recorded source but not automatically a Kiduna requirement.
> 4. **Owner direction for this gate** — supplied in the commentary and activation instructions.
> 5. **Working proposal** — a design hypothesis that still requires review.
> 6. **Contradiction, ambiguity, or missing evidence** — unresolved and not to be silently reconciled.
>
> Do not turn legacy product language, planning assumptions, market estimates, entity structures, or source-document claims into canonical truth merely because they appear in the source pack. For example, preserve and investigate the conflicting public/member counts in the 2nd Cavalry materials instead of selecting one. Map legacy terms to the current taxonomy explicitly and flag uncertain mappings.
>
> ### 2. Create Canonical Taxonomy Version 1.3.3 first
>
> Create a complete `references/canonical-taxonomy-v1.3.3.md` before producing the Gate 2A contracts. Start from Version 1.3.2; do not create a fragment or overwrite prior versions. Add a dated change log and a source/provenance note for every change.
>
> Version 1.3.3 must incorporate the owner's now-established clarification that:
>
> - Studio is the primary desktop/laptop Surface into the Field.
> - The Field is the complete living environment of Realms, activity, agency, Wisdom, memory, relationships, members, work, and play.
> - The Field is always present as context, but it does **not** have to be continuously visible or represented as a map.
> - A focused Realm or Panel may dominate the Surface while quiet signals indicate activity requiring attention and make return to a larger context easy.
> - **Atlas** remains a working name for a possible broad-orientation presentation within the Field, not a synonym for the Field and not yet a fixed interface.
> - The relationships among Field, Realms, Panels, Scenes, Portals, and the possible Atlas are active design questions. Canonical definitions must establish semantic distinctions without dictating one visual or interaction solution prematurely.
> - Kiduna is a system of collective agency. Realms and their authorized Actors can remain active, relate, contribute, request attention, and respond to people and other Realms. It must not collapse into a project-management tool, communication tool, content-management system, dashboard, or conventional website.
>
> Do not canonize an untested interface hypothesis. When a finding is not ready for canon, record it as a working proposal or open taxonomy question. Update `DECISION_LOG.md`, `OPEN_DECISIONS.md`, and `CONTRADICTION_REGISTER.md` so Version 1.3.3 and all unresolved questions agree. From this gate onward, every design turn must include a taxonomy-impact check and either update the current taxonomy with provenance or explicitly record “no taxonomy change.”
>
> ### 3. Preserve the accepted Gate 1 constraints without freezing the wrong ontology
>
> Preserve the accepted Gate 1 one-center behavior:
>
> - one active Realm;
> - one current Focus;
> - one dominant conversational work surface;
> - one continuous conversation;
> - no more than three elevated objects at once;
> - contextual Elements and instruments that appear when useful and recede when complete; and
> - the accepted espresso-black, warm, precise visual hierarchy as a constraint for later interface work.
>
> Treat these as behavioral constraints, not proof that the current labels, panel names, or spatial relationships are final. In particular, investigate what the main conversational Panel is called, how Ki relates to it, how attention from elsewhere in the Field is signaled, when a user asks for broader context, when Ki recommends it, and when a Scene is more useful than a Panel or Lens.
>
> ### 4. Define the shared collective-agency model
>
> Before writing the three Realm contracts, create a source-backed shared model explaining:
>
> - what can remain active in a Realm when the person is focused elsewhere;
> - how a Realm, Ki, an Ally, another Actor, an Element, or another Realm may contribute, respond, propose, or request attention;
> - how the person understands who or what is acting, for whom, from which Source of authority, and within which limits;
> - how attention is prioritized without turning the Studio into a notification dashboard;
> - how work and Wisdom move across personal, Community, Alliance, Organization, Realm, and public scopes;
> - how attribution, provenance, consent, confidentiality, authority, freshness, and reversibility travel with those contributions;
> - how Ki may reflect collective Wisdom without exposing private speech, inventing consensus, creating a surveillance channel, or implying that the Organization can inspect a person's relationship with Ki; and
> - what must persist as a Record after a contribution, synthesis, decision, Action, Scene, or cross-Realm exchange.
>
> Show the semantic relationship among Field, Realm, Panel, Element, Lens, Stage, Scene, Portal, and the provisional Atlas. A diagram or matrix is welcome, but do not design the Atlas or a production interface. Explicitly identify what remains unresolved.
>
> ### 5. Produce three worked Realm systems
>
> Do not merely rename the Gate 1 scheduling example. Model each Realm as a living, durable system with different purpose, Wisdom, Stance, agency, contribution patterns, authority, and trust conditions.
>
> For each worked Realm, produce a complete source-backed Realm Intelligence Contract covering:
>
> - purpose, outcomes, and audiences;
> - structural location and nested Realms, Communities, Alliances, Organizations, Institutions, Programs, and Projects where applicable;
> - Wisdom, contribution pathways, provenance, freshness, uncertainty, disagreement, and canonical status;
> - Stance;
> - Abilities;
> - Automations and ongoing agency;
> - Connections;
> - Ki, Allies, Actors, and their Sources of authority;
> - native Elements, Artifacts, Records, instruments, Scenes, and Portals;
> - Roles, Permissions, privacy, visibility, and contextual Trust;
> - Action authorization levels and governance gates;
> - lifecycle/readiness, current Focus, Pulse, and attention conditions;
> - failure, recovery, correction, appeal, reversal, and preservation; and
> - Compute or Treasury only where materially relevant.
>
> For every important contribution, state: contributor; Source; receiving scope; visibility; review/acceptance authority; canonical effect; attribution; retention; correction path; and resulting Record.
>
> #### Realm A — Inner Clinic
>
> Model **Inner Clinic** as a research and health Alliance within the Bihome Organization, with nested Communities and participating Institutions—not as an appointment workflow. Use the owner's examples as domain inputs requiring verification and structural clarification: Decker's Blueprint and muscular-dystrophy fundraising; the Inflammatory Breast Cancer International Consortium; the Gallbladder Cancer Foundation; and Communities concerned with weight loss, biohacking, and other health interests.
>
> Work through how patients, donors, clinicians, doctors, researchers, institutions, and Community participants receive current research, ask questions, contribute evidence or lived experience, and update Wisdom. Distinguish personal medical information from Community, Alliance, Organization-wide, institution-controlled, and public Wisdom. Specify who may validate or canonize which contributions.
>
> Include a carefully bounded patient-specific medical-record use case: after gallbladder surgery, authorized records may support a clinician-reviewed animated Scene showing findings, infection, stents, disease extent, possible treatment effects, and progress. Define when this Scene is necessary, what it may clarify, what remains uncertain, what requires clinician review, and why it is a Scene rather than a Panel, Lens, Stage, Portal, or general Field view. Do not invent diagnosis, treatment, prognosis, or clinical certainty. Require consent, minimum-necessary disclosure, source visibility, uncertainty, correction, emergency escalation boundaries, and an explicit statement that Kiduna does not replace professional medical care.
>
> Representative intentions should cover at least:
>
> 1. a patient and clinician understanding a complex record through a reviewed Scene;
> 2. a patient or donor receiving a current, comprehensible research synthesis and asking follow-up questions; and
> 3. a researcher, doctor, patient, or Institution contributing knowledge at the correct scope.
>
> Essential exceptions should address substantive trust failures such as conflicting clinical evidence, missing or withdrawn consent, improper scope or disclosure, uncertain clinician validation, or a request that exceeds safe medical authority. Do not use calendar permission as the defining exception.
>
> #### Realm B — The Nature of Work
>
> Model **The Nature of Work** as an Organization containing a major organizational-development and transformation Program or Project, including leadership development and work at multiple levels. Its intelligence should help people act, reflect, learn, coordinate, and develop while the work is happening. It must not become another project-management interface, engagement dashboard, corporate chatbot, or analytics product.
>
> Work through how deep organizational-development resources and professional practice inform the Realm; how participants, leaders, teams, facilitators, and practitioners contribute; which Wisdom is personal, confidential, small-group, Program-level, or Organization-wide; and how local learning becomes shared intelligence only through legitimate consent and governance.
>
> Define how each person's relationship with Ki remains private and trustworthy while Ki can still help the collective learn. Prevent “think pipe,” invented consensus, re-identification, performance scoring, covert sentiment monitoring, managerial access to private conversations, and other forms of corporate surveillance. Make aggregation, anonymization, attribution, confidentiality, expiry, withdrawal, facilitation, authority, and contestability explicit.
>
> Representative intentions should cover at least:
>
> 1. a leader or participant receiving contextual coaching during a real transformation moment;
> 2. a team contributing and synthesizing insight at an intentionally chosen scope; and
> 3. the Organization learning across work without exposing individuals or flattening disagreement.
>
> Essential exceptions should address substantive trust failures such as collective learning that could identify a person, pressure to disclose private Ki conversations, authority conflicts over a synthesis, minority views erased by aggregation, or a requested Action that exceeds the consented scope. Do not use participant availability as the defining exception.
>
> #### Realm C — 2nd Cavalry living history and Service Alliance ecosystem
>
> Expand beyond a single Palo Alto event decision. Model a durable **2nd Cavalry living-history, service, and connection system** informed by the supplied Dragoon Base concept paper, the Service Alliance market research, and the confidential SADUNA backbrief. Preserve Palo Alto as one possible Project or Scene within the larger system, not the whole Realm.
>
> Work through the relationships—without prematurely collapsing them—among the 2nd Cavalry Association, Dragoon Base, Service Alliance LLC, SADUNA, Kiduna Club, relevant veteran Communities and Groups, historical Projects, service Programs, and other Organizations or Institutions named in the evidence. Show which relationships are evidenced, proposed, confidential, legally unverified, legacy, or still structurally ambiguous in the current taxonomy.
>
> The Realm system should support lasting, contributive history and current service: veterans adding oral histories and photographs; historians and present-day troopers exploring primary sources, maps, memories, and interactive historical Scenes; contested accounts remaining attributable; anniversaries and gatherings becoming moments in a persistent archive; veterans finding benefits, mutual aid, leadership connection, or human support; and carefully governed links between service history and health topics such as Gulf War illness. Treat trauma-informed support and health information as bounded support, never a replacement for human or professional care.
>
> Address migration and preservation of the existing archive, contributor rights, data ownership, veteran verification, privacy, sensitive service and health information, provenance, moderation, consent, memorial dignity, AI-generated reconstruction, contested memory, correction, continuity across surfaces, volunteer capacity, and durable Records. Flag numerical and structural conflicts in the source material rather than silently resolving them.
>
> Representative intentions should cover at least:
>
> 1. a veteran contributing an oral history with durable provenance, rights, and chosen visibility;
> 2. a veteran, historian, family member, or current trooper exploring a documented historical event through an interactive Scene; and
> 3. a veteran seeking a trustworthy connection among service history, benefits, health information, peer support, and appropriate human help.
>
> Essential exceptions should address substantive trust failures such as conflicting eyewitness accounts, missing rights or consent, sensitive operational or medical disclosure, unverifiable identity or provenance, a reconstruction that exceeds the evidence, or disagreement over memorial representation. Do not use event attendance or calendar permission as the defining exception.
>
> ### 6. Compare the Realms and prepare Gate 2B
>
> Define three representative intentions and three substantive exceptional conditions for each Realm. Write a concise experience flow for all nine intentions and all nine exceptions, but storyboard only one primary intention and one essential exception per Realm. These are written behavioral storyboards, not new high-fidelity screens.
>
> Create a cross-Realm behavior matrix showing how the same accepted one-center shell would produce genuinely different:
>
> - intelligence and language;
> - contribution models and Wisdom boundaries;
> - Ki and Actor behavior;
> - instruments and Scene criteria;
> - authority, privacy, Trust, and Action gates;
> - attention signals and cross-Realm relationships; and
> - resulting Records, recovery, and correction.
>
> The differences must arise from Realm purpose, Wisdom, Stance, authority, Connections, and relationships—not decorative themes. Keep calendars, integrations, configuration, analytics, and operational plumbing hidden unless an actual trust, authority, or exception state makes them relevant.
>
> Recommend exactly three primary and three exceptional Gate 2B scenes—one pair per Realm. Each scene brief must state the user intention, current Focus, active Realm, what remains active elsewhere in the Field, dominant conversational surface, elevated Elements, Ki/Actor behavior, attention signal, relevant Trust or Action gate, persistent Record, and the specific hypothesis the scene tests.
>
> ### 7. Deliverables
>
> Deliver reviewable Markdown files inside the design-system program for:
>
> 1. complete Canonical Taxonomy Version 1.3.3 plus change log;
> 2. updated source register and provenance notes;
> 3. inherited-requirement / accepted-decision / evidence / owner-direction / proposal / contradiction ledger;
> 4. shared collective-agency and contribution model;
> 5. Field–Realm–Panel–Scene–Portal–Atlas semantic relationship model, including unresolved questions;
> 6. Inner Clinic Realm Intelligence Contract;
> 7. The Nature of Work Realm Intelligence Contract;
> 8. 2nd Cavalry / Service Alliance ecosystem Realm Intelligence Contract;
> 9. nine intention flows and nine exceptional-condition flows;
> 10. cross-Realm behavior matrix;
> 11. six Gate 2B scene briefs with measurable acceptance criteria; and
> 12. updated `DECISION_LOG.md`, `OPEN_DECISIONS.md`, `CONTRADICTION_REGISTER.md`, `WORKING_PLAN.md`, and taxonomy-impact record.
>
> ### 8. Gate 2A completion audit
>
> Gate 2A is ready for review only when every item below is answered with evidence or explicitly marked unresolved:
>
> - Each Realm behaves differently because of its purpose, Wisdom, Stance, authority, and relationships.
> - Each Realm demonstrates useful intelligence before machinery is configured.
> - Collective agency and ongoing activity are explicit without requiring the Field to be continuously visible.
> - Cross-Realm attention and contribution are understandable without becoming a notification or project dashboard.
> - Every important contribution has scope, provenance, consent, authority, visibility, retention, and correction rules.
> - Personal Ki relationships and collective learning coexist without surveillance or invented consensus.
> - Medical use cases meet the defined source, consent, uncertainty, clinician-review, privacy, and escalation safeguards.
> - Historical use cases preserve provenance, rights, contested accounts, dignity, correction, and long-term continuity.
> - Confidential, proposed, legacy, and legally unverified Service Alliance/SADUNA material remains distinguishable from canonical structure.
> - Field, Realm, Panel, Element, Lens, Stage, Scene, Portal, and provisional Atlas have distinct semantic purposes; unresolved visual relationships remain open rather than being silently fixed.
> - Each proposed Gate 2B scene has binary or observable acceptance criteria and tests one named product hypothesis.
> - All deliverables are internally consistent with Taxonomy Version 1.3.3 and the registers.
>
> Do not modify the accepted Gate 1 prototype. Do not create Gate 2 interface screens, design the Atlas, begin Gate 3, write production code, prescribe Flutter/Flame implementation, or add engineering architecture. Stop for my review after the Gate 2A deliverables and completion audit are complete.

## Why this Gate is split

Gate 2A establishes what each Realm knows, how it contributes, whom it serves, how it exercises agency, and where its authority ends. Gate 2B can then express those accepted behaviors through the one-center shell without inventing product logic while styling screens.
