Mission Control & the Mission Board

Companion docs:

• mission-objectives.md — the goal/bounty/reward model: objectives as Lisp cells, multi-currency rewards, the defcontract-schema :objectives clause. Fills OQ-1 / OQ-2 / OQ-3 below. (Draft)
• orchestration.md — capability model, cart contribution, phase-chain semantics
• deck-state.md — UDS struct, cartridge_history bitfield (the registry’s persistent backing)
• repl.md — Mission Runner mode (REPL bindings on contract acceptance)
• cipher-voice.md — CIPHER affect on contracts; new event types added by this doc
• bare-deck-terminal.md — board entry point (MISSIONS / LINK tabs)
• cartridge-lifecycle.md — insertion / Hot Swap state machine (registry’s transient input)
• ../cartridges/authoring/campaign-economy.md — narrative archetype catalog, reframed as worked schema examples Related ADRs: ADR-0028 (Mission Control & Capability Registry), ADR-0029 (Mission Runner), ADR-0005 (FFI surface — capability-call result struct), ADR-0006 (cart format — schema generators), ADR-0011 (UDS persistence), ADR-0015 (CIPHER-LINE)

---

1. Overview

Mission Control is the nOSh runtime subsystem responsible for contract generation, capability registration, and the operator-facing mission board. It is not a static list of missions — it is a procedural function manager that synthesizes contracts from registered capabilities, deck state, and entropy, presenting them as a live, decaying board of opportunities.

Mission Control owns three concerns:

1. Capability Registry — tracking which capabilities are available for contract composition
2. Contract Generation — synthesizing contracts procedurally from schemas, seeds, and the operator’s Universal Deck State
3. Mission Board — presenting contracts to the operator with decay/TTL, managing selection, and handing off to the Mission Runner

After the operator accepts a contract, Mission Control hands the mission struct to the Mission Runner (a Lisp REPL/nEmacs environment loaded with current-mission, mission-params, phase-chain, and load-capability). See §5 and repl.md Mission Runner mode.

---

2. Capability Registry

2.1 Registration

When a cartridge is inserted for the first time, it registers its capabilities with Mission Control via its (cart-init) declaration:

(register-capabilities
  :module     :ice-breaker
  :bit        0x01
  :provides   '(:network-penetration :network-extraction
                :network-sabotage :network-surveillance)
  :affinities '(:digital :network)
  :seeds      '(network-topology ice-placement encryption-depth))

Registration is permanent — it persists in the UDS cartridge_history bitfield (see deck-state.md). A capability registered once is always available to Mission Control for contract generation, regardless of whether the cartridge is currently inserted.

The :bit, :provides, :affinities, and :seeds metadata is recovered at runtime from the cart’s static-data block on every insertion (per ADR-0006 §Cart-Capabilities Block). The bit alone persists in UDS; the rest is a re-loaded view.

2.2 Registry Tiers

Mission Control’s Capability Registry is a four-tier model. The full set of tiers, in order:

Tier	Meaning	Backing	Mission Control behavior
System	Runtime-shipped baseline modules (TERMINAL, GRID, AUDIT, SONAR — see ADR-0030); always present, never decay	System image (not deck-state-tracked)	Composes; bounded by per-module :threat-cap; single-phase only
Inserted	Cartridge is physically present right now	Cartridge slot watcher (per-boot, transient — see cartridge-lifecycle.md)	Composes; preferred (no Hot Swap prompt); inherits cart’s :threat-cap
Recent	Inserted within the recency window (decay-model ADR; forward-compatible)	UDS cart_last_seen per-cart timestamps (see decay-model ADR)	Composes; contracts marked with Hot Swap indicator
Historical	Ever loaded but past the recency window	cartridge_history bit set, cart_last_seen aged out	Invisible to composition; visible to operator as memorial / re-insert affordance

The four tiers compose unambiguously: any module in System ∪ Inserted ∪ Recent is eligible to contribute to contract synthesis. Historical is excluded from composition. The cart’s reappearance in any non-Historical tier is what brings it back.

Capability Registry as derived view. Apart from the new System tier (runtime-shipped, not in UDS), the registry remains a derived view over cartridge_history (persistent) plus the currently-inserted cart (transient) plus the cart_last_seen timestamps (when the decay model lands). It is not a new persistent UDS field. See deck-state.md §Capability Registry.

Contracts can appear on the board that require an Inserted-or-Recent but not currently inserted capability. This is intentional — it creates contracts the operator knows they can reach via Hot Swap. Mission Control marks these contracts with a capability indicator so the operator understands a swap will be required. Contracts requiring a Historical-tier capability are not generated — that’s the decay model’s whole purpose.

2.3 The :supersedes mechanic (per ADR-0030)

A cartridge may declare :supersedes :baseline-name in its register-mission-contributions form. When the cart is in any non-System tier (Inserted or Recent), Mission Control drops the named baseline’s schema selection weight to 5% (variety floor only — keeps the baseline composable for variety, but cart-tier schemas dominate). When the cart leaves all non-System tiers (cart removed and aged out, or never registered), the baseline returns to full selection weight.

The four launch carts each supersede a baseline:

Cart	:supersedes	Baseline lives in
ICE BREAKER	:terminal	software/runtime/baselines/terminal.md
NEONGRID	:grid	software/runtime/baselines/grid.md
BLACK LEDGER	:audit	software/runtime/baselines/audit.md
DEPTHCHARGE	:sonar	software/runtime/baselines/sonar.md

Supersession is one-directional: cart supersedes baseline; baseline never supersedes anything. Future cart domains do not get baselines (see §6 No-Precedent Rule).

---

3. Contract Generation

3.1 Generation Inputs

Mission Control generates contracts by sampling from registered capability schemas, filtered and weighted by:

• Universal Deck State — reputation tier, credit balance, cartridge history bitfield
• Operator skill signal — derived from recent run outcomes (threat levels attempted, trace levels, speed bonuses earned)
• Entropy pool — cipher_seed advanced on each mission completion and power cycle
• Opportunity windows — time-sensitive conditions that open briefly and may never recur

3.2 Contract Schema

Each contract is generated from a schema that declares:

(defcontract-schema :encrypted-cache-recovery
  :required-capabilities '(:underwater-navigation :network-penetration)
  :threat-range          '(2 4)
  :phase-count           2
  :noun-generators       '(target-name network-topology depth-profile)
  :condition-generators  '(encryption-class ice-placement cargo-type)
  :payout-formula        contract-payout-standard
  :ttl-range             '(1800 7200)     ; 30 min to 2 hours real time
  :opportunity-weight    0.3)             ; lower = rarer

The schema selects required capabilities, then uses seeds and registered generator functions to produce the nouns and structures: network topologies, target names, financial account trees, ICE placements, depth profiles — whatever the domain calls for. The schema is the skeleton; the generators are what gives it flesh.

Schemas ship as a sub-section of the cart’s static-data block (per ADR-0006). The cart’s cipher-grammar and mission-contributions blocks remain the authoritative homes for vocabulary and verb/affinity contributions; schemas reference them by symbol. System-tier baselines (per ADR-0030) ship their schemas in the system image as Lisp virtual carts — same defcontract-schema form, just preloaded rather than read from SD.

3.2.1 Threat-cap inheritance (per ADR-0030)

Each module that contributes to a contract — System-tier baseline or registered cart — declares a :threat-cap integer in its register-mission-contributions form. The composed contract’s threat ceiling is the highest cap from any contributing module:

contract.threat_ceiling = max(module.:threat-cap for module in contract.contributors)

Practical effect:

Composition	Effective threat ceiling
System-only (no cart contributing)	2 (1 for GRID-only)
One cart contribution (e.g., ICE BREAKER alone)	Cart’s :threat-cap (e.g., 6 for ICE BREAKER)
Multi-cart compositions	Highest cart cap (e.g., ICE BREAKER + BLACK LEDGER → 6)

Per-module caps for the four launch domains:

Module	:threat-cap
TERMINAL (System)	2
GRID (System)	1
AUDIT (System)	2
SONAR (System)	2
ICE BREAKER (cart)	6
NEONGRID (cart)	3
BLACK LEDGER (cart)	5
DEPTHCHARGE (cart)	5

The threat-range a schema declares (:threat-range '(low high)) is then clipped to [low, min(high, contract.threat_ceiling)] at generation time.

3.2.2 System-tier compositions are single-phase only (per ADR-0030)

A composition that draws only from System-tier baselines is restricted to single-phase contracts. Multi-phase compositions require at least one cart contribution. Practical effect:

• TERMINAL alone → single-phase PENETRATION contracts only
• TERMINAL + ICE BREAKER (cart Inserted) → cart-tier multi-phase compositions allowed
• TERMINAL + AUDIT (both System, no carts) → rejected at composition time; multi-phase across two baselines is not allowed

This keeps the System tier honest: it teaches the deck’s domains; it does not carry multi-phase complexity.

3.2.3 Supersedes-driven schema weighting (per ADR-0030)

When a cart with :supersedes :baseline-name is in any non-System registry tier, Mission Control drops the named baseline’s defcontract-schema selection weight to 5% of its base weight (variety floor only). Cart-tier schemas dominate the active selection pool. When the cart leaves all non-System tiers, the baseline returns to full selection weight.

This produces the operator-felt cart-amplification: when ICE BREAKER is in the slot, the board fills with Zaibatsu-flavored PENETRATION / EXTRACTION / SABOTAGE / SURVEILLANCE contracts at threat 1–6; when ICE BREAKER is out, the board falls back to bounded TERMINAL :probe and :sweep contracts at threat 1–2.

3.3 Contract TTL and Decay

Every contract is generated with a TTL (time-to-live). When the TTL expires, the contract disappears from the board and is not recoverable.

TTL categories:

Category	TTL Range	Notes
Standard	2–8 hours	Baseline contracts; refresh after each run
Urgent	15–45 minutes	High payout, tight window; CIPHER marks them
Opportunity	One appearance only	Never regenerates on the same seed
Episodic	Persistent until accepted	Multi-session surveillance/implant contracts (e.g., ICE Breaker SURVEILLANCE IMPLANT)

Decay is not communicated as a countdown — the operator infers urgency from CIPHER’s commentary and the contract’s presentation on the board. A contract near expiry may have CIPHER notation: window. closing. on CIPHER-LINE (event type :contract-near-expiry; see cipher-voice.md §3 Standard Event Types).

TTL persistence across power cycles. TTLs are stored as wall-clock target timestamps in the board state. A contract with a 4-hour TTL accepted into the board at 14:00 expires at 18:00 regardless of whether the deck is powered off in between. If the deck is off when the TTL elapses, the contract is reaped at the next boot (and CIPHER may emit a :contract-expired reflection on the bare-deck idle pass).

3.4 Opportunity Contracts

Some contracts are generated by rare condition collisions — specific reputation tier, specific cartridge history combination, specific entropy state — and appear exactly once. If the operator declines or lets the TTL expire, the contract is gone.

Mission Control flags these internally but does not tell the operator they are one-shot. The operator learns to recognize patterns that suggest rarity (unusual capability combinations, anomalous payout, CIPHER affect on presentation). Opportunity contracts emit a :opportunity-detected event with :anomalous affect, biasing CIPHER toward drift and annotate modes.

---

4. The Mission Board

4.1 Board State

The board presents 3–5 contracts at any given time. Board state refreshes after every completed or abandoned run. TTL decay runs continuously — contracts can disappear between runs.

Each contract entry displays:

• Threat level (1–5)
• Base payout (¤)
• Required capabilities (icons; dimmed if not currently inserted)
• Contract class (PENETRATION, EXTRACTION, AUDIT, etc. — the player-facing names are catalogued in ../cartridges/design-bibles/mission-type-catalog.md: class = Tier-3 verb × affinity)
• Procedurally generated target name and brief

What the board does not display: TTL countdown, opportunity flags, internal seed values.

4.2 Operator Navigation

Standard board navigation via the Lisp grammar:

Key	Action
[CDR]	Cycle to next contract
[CAR]	Inspect selected contract (full briefing)
[EVAL]	Accept selected contract
[NIL]	Dismiss board (returns to Bare Deck Terminal)

4.3 Contract Briefing

On [CAR], the full briefing screen displays:

• Objective description
• Threat profile
• Required capabilities (with swap indicator if not currently inserted)
• Estimated phase count
• Payout breakdown (base + bonus conditions)
• Any CIPHER commentary on the contract

Pressing [EVAL] from the briefing screen accepts the contract and transfers control to the Mission Runner (§5).

---

5. Mission Handoff — The Mission Runner

5.1 Contract Acceptance

When the operator accepts a contract, Mission Control:

1. Runs the contract’s generator functions with the seed and UDS inputs to produce the full mission struct
2. Populates the struct with generated content: network topology, ICE placements, objectives, phase definitions, capability requirements per phase
3. Serializes the struct into the UDS phase_chain (per phase-chain-format.md)
4. Loads the struct into the REPL/nEmacs environment as a named binding
5. Emits a :mission-start event for CIPHER

;; Available in the Mission Runner after acceptance
current-mission   ; the full mission struct
mission-params    ; extracted parameters (threat, seed, objectives)
phase-chain       ; ordered list of phase requirement records

5.2 The Mission Runner

The operator now has a Lisp environment with the mission struct loaded. They can:

• REPL interactively — execute mission functions one at a time, inspect state, make decisions in real time
• Run a pre-authored script — an nEmacs script that handles coordination, data processing, and capability sequencing automatically

Scripts authored in nEmacs provide:

• Automation of repetitive decision sequences
• Data processing across capability results
• Capability coordination (sequencing Hot Swaps, handling phase transitions)
• Conditional logic based on mission outcomes

Scripts are always optional. Every mission is completable via direct REPL interaction. Scripts raise the ceiling for experienced operators; they do not gate the critical path.

The Mission Runner shares the unified ADR-0016 input subsystem with the standalone REPL (repl.md). The difference is the bound environment: Mission Runner mode adds current-mission, mission-params, phase-chain, and the load-capability builtin; it inherits all snippet-library and history machinery from the REPL.

5.3 Capability Calls

When a mission condition requires a specific capability, the Mission Runner invokes it:

(load-capability :ice-breaker :seed (mission-params :network-seed))

This call:

1. Verifies the required cartridge is registered (errors with :capability-not-registered if not)
2. Checks if the cartridge is currently inserted; if not, prompts Hot Swap
3. Transfers execution to the cartridge’s gameplay loop
4. Runs the capability to completion (success, failure, or abort)
5. Returns a result struct to the Mission Runner

;; Result struct returned by a capability call
{:outcome   :success         ; :success | :failure | :partial | :abort
 :trace     22               ; final trace level
 :extracted '(:network-map :target-data)
 :turns     14
 :bonuses   '(:speed :stealth)}

The mission program branches on results, sequences further capability calls, and ultimately resolves the contract. A complex multi-phase mission is a Lisp program that calls multiple capabilities, processes their results, and drives toward a final objective.

The result struct is exposed at the FFI layer per ADR-0005 §Mission-context primitives.

5.4 Phase Completion and Economy

When all phases are satisfied, the Mission Runner calls:

(complete-mission current-mission)

nOSh processes the result: calculates final payout from the phase outcomes, applies reputation delta, updates UDS, records the run in the cartridge’s provenance chain (event type MISSION per orchestration.md §Cartridge Provenance), and returns to the mission board.

If the operator abandons mid-mission, calling (abandon-mission) (or pressing [NIL] from the Mission Runner) emits a :mission-end with :result-failure affect, applies the reputation penalty, and returns to the board with the abandoned contract replaced by a lower-threat alternative.

---

6. Design Principles

Contracts are synthesized, not stored. Mission Control generates contracts from schemas and seeds at runtime. The cartridge provides the generator functions and vocabulary; Mission Control provides the seed, the UDS context, and the composition logic. There is no static “list of missions” the cart ships.

Capability registration is permanent; insertion is transient. The board can show contracts requiring capabilities the operator has registered but not currently inserted. This makes the full library visible and creates strategic motivation for Hot Swap planning.

The Mission Runner is the operator’s space. Once a contract is accepted and the struct is loaded, the operator owns the execution. Scripts they author are first-class mission tools — not a power-user feature, but a designed part of the experience for operators who want it.

Missions should always be fun. Complexity in mission structure (multi-phase, multi-capability, scripted coordination) serves engagement, not friction. Every mission resolves into something that feels like an elegant operation, not a procedure.

No-precedent rule for System-tier baselines. Per ADR-0030, only the four launch-cart domains receive System-tier baselines (TERMINAL ↔ ICE BREAKER, GRID ↔ NEONGRID, AUDIT ↔ BLACK LEDGER, SONAR ↔ DEPTHCHARGE). Future cart domains — Shellfire’s electronic warfare, Drift’s signal tracking, Pathfinder’s route planning, Nodespace’s network strategy, Cipher Garden’s cryptography, Takezo’s tactical analysis, SynthFence’s market operations, The Vault’s knowledge index, and any future cart — do not get System-tier baselines. The justification is identity: the four launch-cart domains define the deck’s identity floor; everything else is genuine cart territory. The rule is documented here to prevent re-litigation as future cart specs are written.

---

7. Open Questions

Tracked here as the canonical list. Resolution lands in follow-on ADRs or spike docs; this section is updated when an item closes.

• OQ-1. Exact shape of the mission struct (field names, types, serialization format). Initial work in phase-chain-format.md; the Mission Runner-visible Lisp shape is a separate concern. Advanced by mission-objectives.md §2/§8 (draft) — the objective portion is defined there; closes on its promotion + the companion ADR.
• OQ-2. What a capability call returns on partial success — is there a richer result type than {:outcome :trace :extracted :turns :bonuses}? Specifically: does :partial carry a structured “what’s missing” list? Advanced by mission-objectives.md §5 (draft) — partial success = the snapshot of goals not :done, with state.
• OQ-3. How nOSh reconciles partial phase completions into the economy. Current model is “the mission program branches”; this leaves the reputation/credit accounting per-phase undefined. Advanced by mission-objectives.md §5/§8 (draft) — banked :on-complete rewards + resolve-time escrow settlement.
• OQ-4. Whether Mission Runner scripts can register reactive handlers (e.g. (on-hunter-spawn ...)) that fire during capability execution, or whether capability calls are fully opaque to the runner. The opaque model is simpler; the reactive model is more expressive.
• OQ-5. Schema authoring tooling — do we ship a validate-schema tool with the desktop emulator that lints defcontract-schema forms against the registered capability set?

---

8. Migration Notes

This doc supersedes the prior treatment of these concepts in earlier revisions of orchestration.md and campaign-economy.md. The migration shape:

• Mission templates → schemas. Older docs spoke of “mission templates shipped as cart static-data type=4.” That structure persists at the byte level (per ADR-0006), but the runtime contract is now schema-driven generation, not pre-baked template selection. ADR-0006 §Cart-Capabilities Block clarifies the section tag.
• Phase handler dispatch → capability calls. Older docs described the runtime dispatching directly to a cart’s phase handler when a phase advanced. The Mission Runner replaces this: the runtime dispatches to a Lisp environment, which then calls (load-capability ...) to invoke the cart’s gameplay loop. Cart-side handler registration is unchanged at the FFI layer — only the caller changes. See ADR-0029.
• Implicit registration → Capability Registry. “On First Load” prose in module specs (e.g., ../cartridges/design-bibles/launch-titles-capability.md) is reframed as registry vocabulary (:provides, :affinities, :seeds). Existing bitfield mechanics are unchanged; the vocabulary is new.
• Campaign archetypes → worked schema examples. campaign-economy.md catalogs eight archetypes (Corporate Espionage, Maritime Intelligence, etc.). Under Mission Control these are not the canonical generation set — they are narrative seed examples. The schema-driven generator covers the long tail; the archetypes serve as documented reference shapes and authoring inspiration. See that doc’s “Reframed under Mission Control” section.