# Field–Realm–Panel–Scene–Portal Relationship Model

**Status:** Canonical semantics from Version 1.3.3 plus clearly labeled Studio proposals  
**Out of scope:** final navigation, Atlas design, production UI, Flutter/Flame architecture

## 1. The model has three different kinds of relationship

Confusion occurs when semantic context, device presentation, and visual treatment are treated as the same thing.

### Semantic context

- **Field** — the complete living Kidunaverse environment.
- **Realm** — a persistent semantic and agentic context within the Field.
- **Element / Artifact / Action / Presence / Agent** — things represented, created, related, or acting within those contexts.

### Access and bounded experience

- **Surface** — device-specific access to the Field; Studio is the desktop/laptop Surface.
- **Scene** — bounded independently designed environment that runs within a Surface.
- **Portal** — explicit connection into, out of, or between Scenes.

### Presentation and attention

- **Panel** — canonical organized group of Elements over the current Field/Realm context.
- **Lens** — proposed inspection treatment; not canonical.
- **Stage** — proposed dominant-Element treatment; not canonical.
- **Atlas** — provisional name for a possible broad-orientation presentation within the Field; not canonical.
- **dominant conversational surface** — neutral Gate 2 design phrase; not canonical.

## 2. Smallest correct relationship

```mermaid
flowchart TD
    Field["Field — complete living context"]
    Surface["Studio Surface — desktop/laptop access"]
    Realm["Active Realm — semantic and agentic context"]
    Panel["Panel — focused Elements over context"]
    Scene["Scene — bounded environment"]
    Portal["Portal — explicit entry/return"]
    Atlas["Atlas — provisional orientation presentation"]

    Field --> Surface
    Field --> Realm
    Surface --> Panel
    Realm --> Panel
    Realm --> Portal
    Portal --> Scene
    Scene --> Portal
    Surface -. "may present" .-> Atlas
    Atlas -. "orients within" .-> Field
```

This diagram is semantic, not a wireframe. It does not require the Field to be drawn behind the Panel, Atlas to be a map, or a Scene to occupy the full window.

## 3. Purpose and boundary table

| Concept | Exists to | Persists? | Has agency/authority? | Typical exit or return | Must not be confused with |
|---|---|---:|---|---|---|
| Field | Provide the complete context of participation and relationship | Yes | Contains agency; does not itself erase Realm authority | Never “exit” while participating; change Surface or context | Atlas, map, desktop, website |
| Surface | Present and control Field access for a device | Session/device | No independent authority | Continue on another Surface | Separate Kidunaverse |
| Realm | Hold persistent context, purpose, Wisdom, Stance, Roles, policy, relationships, and agency | Yes | Yes, through valid Sources, governance, and Agents | Enter another or containing Realm while preserving context | Screen, folder, visual boundary |
| Panel | Organize Elements over current context | Temporary or persistent | No authority of its own | Dismiss, collapse, replace, or keep | Realm, permission, navigation destination |
| Element | Represent something system-native and interactive | Representation varies | No new authority merely by appearing | Collapse, move, copy, reference, Lens, Stage, or Action | Underlying object or permission |
| Artifact | Persist information, media, evidence, code, or work product | Yes | No; may carry authoritative evidence | Version, reference, transform, archive | Element representation |
| Scene | Provide a bounded visual/interactive environment with its own behavior | State may persist | Uses Realm/Presence/Agent authority; does not create universal authority | Portal back or onward | Field, Atlas, enlarged Panel |
| Portal | Govern explicit entry, exit, continuity, and allowed transformation | As connection/policy | Carries authority context; does not originate it | Defined source/target route | Decorative doorway or generic link |
| Lens | Proposed deep inspection of an object or Realm | Temporary | No | Return to work with context intact | New Realm or permanent settings page |
| Stage | Proposed state where an Element becomes dominant work | Temporary | No | Commit, save, return, or preserve draft | Scene unless bounded environment is necessary |
| Atlas | Proposed broader orientation within Field | On demand | No | Enter/return while preserving current Focus | Field itself or mandatory task interface |

## 4. Dominant conversational surface

The Gate 1 behavior can be described without naming a new canonical object:

- It is most likely a highly opaque or visually dominant Panel containing conversation and current Elements.
- Ki remains available across the Studio Surface and is not “owned” by the Panel.
- The active Realm supplies the semantic context, Wisdom, Stance, Roles, and policies.
- The current Focus organizes what is elevated; Focus remains a design term.
- The larger Field may be visually quiet while continuity and one material Attention Thread remain available.

Open question C-014 remains: whether this surface should ultimately be called Chat, Work, something combined, or something new.

## 5. When to use each treatment

### Stay in conversation

Use conversation when language, choice, explanation, or a small number of attached Elements is enough. The person should not leave conversation merely to see metadata.

### Show an inline instrument

Use a Widget or compact Element when structured comparison, input, selection, or progress materially reduces ambiguity. Hide source machinery until trust or exception handling requires it.

### Open a Lens

Use the proposed Lens when the person asks “why,” “where did this come from,” “who can act,” “what changed,” or “what are the limits?” The Lens inspects; it does not become the enduring work itself.

### Move an Element to Stage

Use the proposed Stage when a document, image, source set, proposal, model, or other Element needs sustained editing, close comparison, or decision. The same conversation and Realm persist.

### Enter a Scene

Use a Scene only when at least one necessity is present:

1. **Spatial necessity** — position, anatomy, geography, or relationship in space changes understanding.
2. **Temporal necessity** — sequence, progression, before/after, or causality must be experienced over time.
3. **Simulation necessity** — the person must test scenarios or see consequences dynamically.
4. **Embodied/performative necessity** — participation, role, rehearsal, memorial, or gathering changes the outcome.
5. **Game necessity** — rules, state, challenge, or play are part of the purpose.
6. **Independent visual-system necessity** — the Realm's normal Elements cannot responsibly express the material.

A Scene fails the test when it merely decorates information, enlarges an Artifact, replaces clear prose, or creates false realism.

### Seek broader orientation

Broader orientation is warranted when:

- the current work depends on another Realm;
- more than one material relationship needs comparison;
- an out-of-focus activity requests legitimate attention;
- the person asks where something belongs or what contains it;
- the person wants to discover related Realms, work, or relationships; or
- return context after a Scene or cross-Realm exchange is unclear.

This behavior may eventually be expressed through Atlas, but Gate 2 does not select its form.

## 6. Two Scene applications

### Patient-specific gallbladder Scene

Use a Scene only when clinician-reviewed source records can support a spatial/temporal representation of anatomy, surgical findings, stents, infection, documented disease extent, or treatment progression more clearly than a record summary. It must:

- distinguish observed facts, clinician interpretation, and illustrative anatomy;
- show the date and Source for each represented finding;
- avoid inferring an unseen diagnosis or prognosis;
- label simplification and uncertainty;
- require the correct patient consent and clinician review;
- provide a Portal back to conversation and the source record; and
- preserve a versioned Scene-generation/review Record.

If those conditions are absent, use a Panel, Lens, or clinician-authored Artifact instead.

### 2nd Cavalry historical Scene

Use a Scene when geography, movement, chronology, testimony, and primary sources materially improve historical understanding or memorial participation. It must:

- distinguish primary evidence, attributed memory, scholarly interpretation, and reconstruction;
- preserve contested accounts rather than merge them;
- avoid synthetic eyewitness authority;
- show where evidence is missing;
- respect contributor rights and sensitive material;
- provide a Portal to original Sources and back to the living-history Realm; and
- preserve the Scene version and editorial approval Record.

If it is only a gallery, timeline, document comparison, or map inspection, an Element, Lens, or Stage may be sufficient.

## 7. Attention and continuity across transitions

Every transition among Panel, Lens, Stage, Scene, and broader orientation preserves unless explicitly transformed:

- active Realm;
- current Focus;
- continuous conversation;
- selected Elements and source set;
- relevant Role and permissions;
- pending Action/Gate;
- out-of-focus Attention Thread;
- drafts and progress; and
- a clear return destination.

An explicit transformation states what changes, why, under whose policy, and whether it can be reversed.

## 8. Unresolved questions retained for later gates

1. Is Atlas a needed term and, if so, what is its smallest useful form?
2. Are Lens and Stage durable patterns or Panel/Element states?
3. How is Field activity signaled in Studio without permanent navigation or a dashboard?
4. Can more than one Realm ever be active, or is one active Realm plus referenced/contributing Realms sufficient?
5. What should the dominant conversational surface be called?
6. Does a Portal always require explicit visible representation, or can some transitions be conversational while still producing a Portal Record?
7. How does broader orientation work on Live and TV without copying Studio?

No answer in this document determines the Gate 4 Atlas design.
