---
name: design-kiduna-realm
description: Design or refine a Kiduna Realm as an intelligent, trustworthy experience rather than a collection of screens. Use when defining a new Realm, making an existing Realm useful, specifying its default experience, or determining whether its Wisdom, Stance, Actors, Abilities, Connections, authority, records, and exceptional states are ready for design.
---

# Design a Kiduna Realm

Use this workflow to turn a Realm's purpose into a focused experience that helps an Actor achieve an outcome. Read [realm-contract.md](references/realm-contract.md) before starting.

## 1. Establish the evidence boundary

- List inherited requirements and cite their sources.
- List proposals separately and label their confidence.
- Record contradictions and missing evidence. Do not silently resolve them.
- Use canonical Kiduna terms. If a source uses legacy language, preserve it only as a quoted alias.

## 2. Define the Realm contract

Complete the contract in the reference file. At minimum define:

- purpose, audience, promised outcomes, and non-goals;
- Wisdom, Stance, Abilities, Automations, and Connections;
- participating Actors and their visible or delegated roles;
- important Elements and their provenance;
- privacy, visibility, authority, permissions, policies, and gates;
- default state, attention conditions, and recovery behavior;
- Records produced by meaningful Actions;
- Compute and Treasury implications when applicable.

Do not represent every contract field as permanent interface. The contract governs behavior; the experience reveals only what the current intention requires.

## 3. Compose the default experience

Design one calm default scene with:

- one active Realm;
- one current Focus or intention;
- one dominant conversation/work surface;
- a small number of relevant next moves;
- contextual Elements that can be summoned, expanded, or returned to the background.

Then define the Realm Lens: the expanded view that explains purpose, intelligence, state, authority, recent Records, and available Actions without turning the taxonomy into navigation.

## 4. Prove useful intelligence

Test at least three representative intentions. For each, show how Realm intelligence changes the result—not merely the visual styling. Include one intent that uses connected context without exposing a conventional dashboard unless requested.

Test at least three exceptional conditions chosen from missing connection, insufficient authority, conflicting Stance, privacy boundary, low Compute, stale Wisdom, unavailable Actor, failed Action, or recovery from interruption.

## 5. Deliver the Realm definition

Return:

1. evidence and proposal ledger;
2. completed Realm contract;
3. default scene and Realm Lens descriptions;
4. intent-to-instrument flows;
5. gates, Records, recovery, and exceptional states;
6. readiness gaps and open decisions;
7. prioritized user stories with measurable acceptance criteria.

Keep technical implementation details out unless explicitly requested.
