# Studio Design-System Brief

## Working product thesis

Kiduna Studio is a **Realm-aware conversational operating environment**.

The system should feel like one coherent intelligence organizing the user's work, not a collection of applications, modules, dashboards, or configuration pages.

The dominant hierarchy is:

1. **Current intention** — what the user wants now.
2. **Active Realm** — the context supplying purpose, intelligence, permissions, and resources.
3. **Main conversation or work** — the primary place where intent becomes structured progress.
4. **Relevant Elements** — sources, artifacts, proposals, schedules, maps, drafts, and other things called forward as needed.
5. **Supporting system state** — collaborators, agents, tools, compute, permissions, and operations shown only when consequential.
6. **Field orientation** — the wider relational system entered deliberately.

## Canonical concepts available in Version 1.3.1

The supplied Structural Summary establishes that:

- participation happens in the **Field**, accessed through **Surfaces**;
- **Realms** can be entered and explored;
- **Presences** appear and participate;
- **Ki** provides personal agency;
- **Actors** are other software entities that act;
- Agents possess **Wisdom, Stance, Abilities, Automations, and Connections**;
- **Elements** appear visually within the Field, Realms, and Panels;
- **Scenes**, entered through **Portals**, provide bounded designed experiences;
- **Artifacts** persist;
- **Actions** happen;
- **Roles, Authority, Permissions, Policies, Privacy, Visibility, Trust, and Governance** constrain participation and action;
- **Treasuries** govern financial resources; and
- **Compute** pays for intelligence, agency, contribution, and related services.

These concepts govern behavior. They should not become a permanent navigation list.

## Proposed interaction terms

The following are design-pattern names, not additions to the canonical taxonomy:

| Working term | Meaning |
|---|---|
| Focus | The single intention or task currently foregrounded. |
| Main conversation | The continuous place where the user directs Ki and contextual Actors. |
| Instrument | A structured interactive Element temporarily brought into the work: calendar choices, a draft, map, source set, proposal, or budget. |
| Lens | A temporary expanded inspection of an Element or Realm. |
| Stage | A larger focused work surface for one Element or composition. |
| Gate | A confirmation, approval, signature, vote, or governance moment. |
| Pulse | A compact status signal for work, health, attention, or Compute. |
| Receipt | The durable result of an Action, including authority and execution status. |
| Atlas | The Field-oriented view of Realms, relationships, and active work. |

## One-center rule

At any moment, one surface must carry at least 60–70% of the visual and interaction weight. Secondary surfaces may support it, but they may not compete with it.

The center may be:

- the main conversation;
- one expanded Element;
- one Scene;
- one decision or Gate; or
- the Atlas when the user explicitly asks to orient.

It may not be six equal cards, four equal organizations, or a wall of simultaneous system categories.

## Default inside-Studio frame

1. Quiet top bar: Kiduna, active Realm, mode, Pulse, profile.
2. Central main conversation/work area.
3. Context-aware input that accepts language, files, links, images, voice, and Elements.
4. Optional Element Lens or Stage that appears only when invoked.
5. Minimal attention indicators; one elevated Action at a time.
6. A broader Atlas view of the Field is available but not continuously visible.

## Conversation model

- The user speaks to Ki by default.
- Ki may route the exchange to an appropriate Realm Actor or another Presence's Ally.
- The interaction may feel direct, but the acting principal and authority source must be recoverable.
- Changing the selected Element changes conversational context without requiring a separate chat application.
- Moving an Element into the main conversation means attaching its identity and current state to the conversational context.
- The system should preserve continuity when the user moves between chat, Lens, Stage, Scene, and Atlas.

## Progressive-disclosure rule

Do not show connected calendars, integrations, vector indexes, graphs, wallets, tools, or collaborators merely because they exist.

Show them when:

- the user asks;
- the system needs consent or configuration;
- their state blocks the goal;
- their output becomes part of a decision;
- authority or privacy must be understood; or
- the user opens the Realm or Element Lens.

## Collaboration rule

After people accept invitations, collaboration should primarily be visible through shared work, proposals, edits, decisions, and presence cues—not permanent portraits or collaborator panels.

Show a collaborator prominently when:

- they are speaking;
- their approval or authority is required;
- they changed the active Element;
- the user asks who is involved; or
- trust, privacy, or attribution depends on identity.

## Completion test

The system is working when a user can enter a capable Realm, state an outcome in ordinary language, receive structured help, inspect and manipulate the relevant Elements, authorize consequential Actions, and retain a clear Record—without first learning the Studio's module map.
