ADR-0028: Mission Control & the Capability Registry

Context

The Capability Model spec (software/runtime/orchestration.md) established that nOSh orchestrates the platform and cartridges register capabilities by setting bits in cartridge_history. It treated contract generation as “the runtime reads mission template structures from the cart’s static-data section and produces 4–8 contracts.” That model is sufficient for a 4-cart launch library where every meaningful contract pair can be hand-authored (six pairs at 4 carts; 91 pairs at 14 carts is not tractable).

The Mission Composition Grammar working draft (plans/post-v0.1/2026-04-25-mission-composition-grammar.md) recognized this scaling problem and started designing a procedural composition layer with verb vocabulary, affinity tags, and sanctioned cross-affinity transitions. It remained a working draft because the higher-level architecture — what is the runtime subsystem that owns contract generation, how is it named, what’s its contract with the cart and with the operator — was still implicit.

Form KN86-MCMB-001 (Josh, 2026-05-03) names that subsystem Mission Control and adds three concepts the implicit model lacked: an explicit Capability Registry that distinguishes registered-but-not-inserted from inserted, schema-driven contract generation with TTL/decay, and Opportunity Contracts (one-shot rare conditions). These are not refinements — they reshape what carts ship, what UDS reads mean to the runtime, and what the operator sees on the board.

Forcing functions

14-cart library doesn’t fit hand-authored pairs. Composition has to be procedural at scale; the spec must commit to a generator architecture before more cart specs harden against the wrong assumption.
TTL is undocumented. Operators have no urgency signal beyond explicit countdowns we don’t want to render, and campaign-economy.md ships a 72-hour campaign timeout with no equivalent for single-phase contracts.
The “registered vs inserted” gap is felt, not named. Module specs say “Mission Board immediately gains access to X templates” — but the next sentence assumes the cart is inserted. Players quickly realize a cart they haven’t physically inserted in months still gates their board, but the docs never said why.
Companion ADR-0029 (Mission Runner) needs a host subsystem to live in. Without naming Mission Control, the Mission Runner has no parent.

Constraints

No new persistent UDS field. Adding a top-level UDS field is expensive (deck-state struct version bump, migration, flash-region pressure). The registry must be derivable from existing UDS state.
Cart format compatibility. The .kn86 v2.0 container (ADR-0006) is shipped; the registry must use existing section types or an additive amendment, not a v3.
No backsliding on Lisp authoring. Mission Control is a runtime subsystem. Cart-side contributions remain Lisp, on the Fe VM, per ADR-0001.
CIPHER-LINE only for voice. New event types land on the auxiliary OLED (ADR-0015), not the main grid.

Decision

Adopt Mission Control as a named nOSh runtime subsystem owning capability registration, schema-driven contract generation, and the operator-facing mission board. Specifically:

Promote software/runtime/mission-control.md to canonical (the doc landed alongside this ADR). It is the authoritative spec for the Mission Board, contract lifecycle, and Mission Runner handoff.
Capability Registry is a derived view. Mission Control composes :registered (from cartridge_history bitfield, persistent) and :inserted (from the cart slot watcher, transient) into a runtime registry. No new UDS field. Cart capability metadata (:provides, :affinities, :seeds) is recovered from the cart’s static-data block on every insertion.
Cartridges declare capabilities explicitly. Cart (cart-init) issues (register-capabilities :module :bit :provides :affinities :seeds). The bit is the persistent identity; the lists are the vocabulary Mission Control composes against.
Contract generation is schema-driven. Carts ship defcontract-schema forms in their static-data section (sub-section type defined in ADR-0006 amendment, see below). At generation time, Mission Control selects a schema, runs its noun/condition generators against the LFSR seed and UDS, and produces a fully-realized contract.
Every contract carries a TTL. TTL classes: Standard (2–8 h), Urgent (15–45 min), Opportunity (one-shot), Episodic (persistent until accepted). TTLs are wall-clock target timestamps and survive power cycles.
Opportunity Contracts are flagged but unlabeled. Mission Control marks them internally; the operator infers rarity from CIPHER affect (:opportunity-detected event, :anomalous tag, drift/annotate mode bias).
The Mission Runner (ADR-0029) is the post-acceptance environment. Mission Control’s responsibility ends when (complete-mission ...) or (abandon-mission) resolves the active contract.
Bare-deck bounties flow through the same registry. DIAGNOSTIC, LFSR EXERCISE, LFSR SYNC, ECHO TEST, DECK COMPARE are runtime-registered schemas keyed off a :bare-deck capability bit. They are not LINK-specific specials.

Options Considered

Option A: Promote KN86-MCMB-001 as written; add procedural generation, TTL, Opportunity Contracts, derived Capability Registry. (ACCEPTED)

What it is. The Form-001 spec verbatim, polished into mission-control.md and codified by this ADR plus its companion ADR-0029 for the Mission Runner.

Chosen because it gives the runtime a name, explicitly names the registered-vs-inserted gap, codifies TTL as a first-class concept (with operator-UX rules: never render countdowns), and creates an extension point (schemas) that the Mission Composition Grammar work can land into. The Capability Registry being a derived view avoids a deck-state version bump.

Option B: Keep static templates; add a “freshness” timestamp per template; never name the subsystem.

What it is. Patch the existing orchestration.md model — give templates a TTL-like freshness, leave generation as “select a template and produce a contract,” and skip the Capability Registry concept.

Rejected because the unnamed-subsystem problem doesn’t go away — it just moves the contradictions between docs (registered-vs-inserted, opportunity vs scheduled, bare-deck bounty source) into the gaps between sections. Static templates also can’t compose multi-cart contracts at the 14-cart scale; we’d hit the same wall in six months and need this ADR anyway.

Option C: Defer to Mission Composition Grammar; let it grow into the runtime owner.

What it is. Land the MCG plan as the architecture; let “Mission Control” emerge as documentation when the algorithm ships.

Rejected because ordering matters. Cart specs are being written now against the wrong contract surface. ICE Breaker says (cart-init) “marks the deck”; it should say (register-capabilities ...) with vocabulary Mission Control can compose. Waiting for MCG implementation means continued doc drift in the cart specs and another harmonization PR later. Naming the runtime first lets MCG land into a defined slot.

Trade-off Analysis

Dimension	Option A (chosen)	Option B (templates+TTL)	Option C (defer to MCG)
Scaling to 14-cart library	✓ schema-driven generation handles long tail	✗ still O(N²) in hand-authored pairs	✓ eventually, when MCG ships
Doc drift right now	✓ this PR fixes it	◐ partial — registered/inserted still implicit	✗ continues
UDS schema cost	✓ none (registry is derived)	✓ none	✓ none
Cart format cost	◐ ADR-0006 amendment for schema sub-section	✓ no change	✓ no change
Affordance for ADR-0029	✓ Mission Runner has a parent subsystem	✗ still floating	✗ still floating
Operator clarity	✓ TTL named; opportunity rarity legible via CIPHER	◐ TTL but no opportunity concept	✗ deferred

Cost: schema authoring is now a cart-author concern. We accept this — schemas are short, authoring tooling is a known follow-on (OQ-5 in mission-control.md), and the alternative is hand-authoring O(N²) cart pairs forever.

Consequences

Positive

Runtime subsystem has a name; ADR-0029 (Mission Runner) has a parent.
Capability Registry concept replaces the implicit registered-vs-inserted gap with explicit vocabulary.
TTL is first-class; CIPHER carries urgency without UI countdowns.
Opportunity Contracts give Mission Control a rare-event surface that wasn’t representable before.
The 14-cart library composes procedurally rather than via hand-authored pairs.

Negative / Accepted costs

Cart authors now learn schema authoring (small grammar, but new). Mitigated by campaign-economy.md’s reframed archetype catalog as worked examples.
ADR-0006 needs an amendment to clarify the static-data sub-section tag for defcontract-schema forms. Landed in this PR.
Runtime cost of evaluating a schema’s generators on every board refresh. Bounded — schemas are small Lisp forms; refresh is event-driven, not per-frame.
The Mission Composition Grammar working draft becomes a schema-authoring layer rather than a parallel architecture; it absorbs cleanly but the working draft needs a status update (follow-on).

Follow-on work this ADR creates

ADR-0029 lands in this PR — Mission Runner architecture.
ADR-0005 amendment lands in this PR — capability-call result struct.
ADR-0006 amendment lands in this PR — defcontract-schema sub-section tag and capability-block reconciliation.
Mission Composition Grammar working draft (plans/post-v0.1/2026-04-25-mission-composition-grammar.md) gets a status note in a follow-up PR — it now operates under Mission Control, not parallel to it.
Schema validator tool (OQ-5 in mission-control.md) — desktop emulator companion that lints defcontract-schema forms.
Module-spec sweep — the 17 cart specs under software/cartridges/modules/ carry “On First Load” prose that hasn’t yet been rewritten to the Capability Registry vocabulary; a follow-up PR sweeps them. Launch-title bibles are updated in this PR.
bare-deck-terminal.md schema migration — DIAGNOSTIC, LFSR EXERCISE, LFSR SYNC, ECHO TEST, DECK COMPARE need explicit schema definitions; cross-referenced in this PR, implementation tracked separately.

Documentation Updates (REQUIRED)

Narrative

For a year the KN-86 docs spoke of a “mission board” without naming the thing that owned it. The runtime read templates off cartridges and made some contracts. It worked at four carts. It would not work at fourteen, because the number of meaningful cart pairs grows quadratically and there are not enough hands to author them all. This ADR names the owner — Mission Control — and gives it three concrete pieces of architecture: a Capability Registry that distinguishes a cart you’ve ever loaded from one currently in the slot, a schema-driven generator that synthesizes contracts at runtime instead of selecting from a static menu, and a TTL system that lets contracts decay so that opportunity feels like opportunity. It also gives Mission Control a partner — ADR-0029, the Mission Runner — for what happens after the operator says yes. The change is significant enough to land as two ADRs in one PR; the docs that drift around the edges (deck state, CIPHER voice events, the launch-title bibles, the campaign-economy archetype catalog) are reframed in the same change so a future reader doesn’t land in a half-migrated corpus.

Amendment Log

Amendment 2026-05-05 — Registry tier model extended; `:supersedes` and threat-cap inheritance added (per ADR-0030)

Status effect: Accepted (unchanged). Adds the System tier to the Capability Registry; codifies forward-compatibility with the Recent / Historical decay-model tiers; introduces the :supersedes machinery and threat-cap inheritance. Original Decision items are preserved; the amendment is additive.

Rationale. ADR-0030 introduces four runtime-tier baseline modules (TERMINAL, GRID, AUDIT, SONAR — one per launch-cart domain) shipped in the system image. The original two-state registry (Registered / Inserted) cannot represent a runtime-shipped capability that is always present and never decays. The fix is a tier extension: System (runtime-shipped, never decays) joins Inserted (cart in slot) as the active-composition tiers. Two further tiers — Recent and Historical — come from a forward-compatible decay-model ADR; this ADR’s amendment is compatible with that ADR landing later but does not depend on it.

Separately, ADR-0030 introduces a :supersedes field on register-mission-contributions that lets a cart drop a named baseline’s schema selection weight to 5% (variety floor) when the cart is registered. And it introduces threat-cap inheritance — composed contracts take the highest :threat-cap from any contributing module. Both mechanics are properties of the registry / Mission Control composer; they belong amended into this ADR rather than fragmented into a new one.

Decision items added by this amendment:

Registry tier model extends from two-state to four-tier. The full set: System / Inserted / Recent / Historical. System modules are runtime-shipped, always present, never decay, not represented in cartridge_history. Inserted is from the original ADR. Recent and Historical come from a sibling decay-model ADR; this ADR’s amendment is forward-compatible.
:supersedes field on register-mission-contributions. When a cart with :supersedes :baseline-name is in any non-System tier, Mission Control drops the named baseline’s defcontract-schema selection weight to 5% (variety floor). The baseline returns to full weight when the cart leaves all non-System tiers.
Threat-cap inheritance. A composed contract’s threat ceiling is the highest :threat-cap from any contributing module. System-only compositions cap at 2; one cart contribution raises the cap to that cart’s ceiling.
System-tier compositions are single-phase only. Multi-phase / cross-module compositions require at least one cart contribution.
No-precedent rule. Only the four launch-cart domains receive System-tier baselines. Future cart domains do not. Documented in mission-control.md §6.

What did not change:

Original Decision items 1–5 (Mission Control as a named subsystem; Capability Registry as a derived view; explicit (register-capabilities ...); schema-driven contract generation; TTL / Opportunity Contracts; bare-deck bounties through the registry) — unchanged.
Original Status: Accepted (unchanged).
The Capability Registry as a derived view over cartridge_history + currently-inserted cart — unchanged for Inserted / Recent / Historical. The new System tier is runtime-shipped (system image) and is the only tier not derived from UDS state.
No new persistent UDS field — the System tier is runtime-shipped, not deck-state-tracked.

Authority trail. ADR-0030 §Decision items 1, 3, 4, 5, 7 (registry tier addition; supersedes; threat-cap inheritance; single-phase-only; no-precedent rule). software/runtime/mission-control.md §2.2, §2.3, §3.2.1, §3.2.2, §3.2.3, §6 are the user-facing prose specifications for these mechanics. Engineering follow-up: Mission Control runtime — implement :supersedes weighting and threat-cap inheritance in the contract generator.