ADR-0030: Runtime-Tier Launch Baselines (System tier + TERMINAL / GRID / AUDIT / SONAR)

Context

ADR-0028 introduced the Capability Registry as a derived view over cartridge_history (persistent) plus the currently-inserted cart (transient). Two states: Registered and Inserted. A deck with no cart in slot, and no cart ever loaded, has nothing in either state — Mission Control composes only from the bare-deck bounty pool (DIAGNOSTIC, LFSR EXERCISE, LFSR SYNC, ECHO TEST, DECK COMPARE, per bare-deck-terminal.md LINK tab).

That bounty pool is intentionally narrow — diagnostic + link-cooperation training. It teaches the input grammar but does not represent the deck’s intended gameplay. An operator who buys the device and inserts no cart, or who removes a cart, or who loses a cart, has nothing recognizable as the device’s gameplay floor. The four launch-cart domains — network intrusion (ICE BREAKER), spatial navigation (NEONGRID), forensic accounting (BLACK LEDGER), maritime sonar (DEPTHCHARGE) — are the deck’s identity. Without the corresponding cart in slot, that domain is entirely unavailable.

This ADR introduces a System tier in the Capability Registry and ships four baseline modules — TERMINAL, GRID, AUDIT, SONAR — one per launch-cart domain. Each baseline is bounded (single verb, threat cap 2, single-phase only, training-tier rewards). Each cart, when registered, supersedes its baseline and unlocks the domain’s full depth.

Forcing functions

Out-of-box experience. A deck purchased without bundled software must be substantially playable across the four foundational domains, not just the bare-deck bounty pool.
Cart-loss recovery. An operator whose flagship cart is lost / sold / damaged / borrowed-and-returned must retain the domain’s training-tier capability. Today they lose the domain entirely.
Training-tier bridge. Every operator needs to learn each domain’s mechanics before the cart’s depth becomes worthwhile. Today the cart must teach itself; baselines absorb that role.
Cart-amplification clarity. “Cart upgrades a capability the deck already has” is a sharper product story than “cart unlocks a capability the deck does not have.”

Constraints

No new persistent UDS field. System-tier modules are runtime-shipped; their presence is not deck-state-tracked. The existing cartridge_history bitfield governs cart registration only.
Cart format unchanged at the byte level. ADR-0006 amendments add a vocabulary token (:supersedes) to the CART_CAPABILITIES allowlist; no structural change.
No slippery slope. Only the four launch-cart domains get System-tier baselines. Future cart domains do not. The justification is identity, not generality.
Cartridge model stays canonical. Carts remain the primary path for full-fidelity gameplay. Baselines are bounded by design.

Decision

Add a fourth tier to the Capability Registry: System. System-tier modules are runtime-shipped, always present, never decay, never demote, are not represented in cartridge_history. The full registry tier set becomes: System / Inserted / Recent / Historical. (Inserted is from ADR-0028. Recent and Historical come from a sibling decay-model ADR; this ADR is forward-compatible with that decision and does not depend on it.)

Ship four System-tier baseline modules in the system image. Each maps 1:1 to a launch cart’s domain:

Baseline	Cart	Verb	Threat cap	Patterns shipped	Schemas shipped
TERMINAL	ICE BREAKER	`:penetrate`	2	STATIC FIREWALL, REACTIVE FIREWALL (3-strike alert), SLOW HUNTER (1 cell per 4 player actions)	`terminal/probe`, `terminal/sweep`
GRID	NEONGRID	`:grid-calibration`	1	STATIC SENTRY (blocking), STATIC PATROL (2–3 cell fixed cycle), TRIGGER ZONE (invisible alert)	`grid/calibration`
AUDIT	BLACK LEDGER	`:audit-trace`	2	CLEAN TXN, OBFUSCATED TXN (decoded with EVAL), FLAGGED TXN (the target)	`audit/trace`
SONAR	DEPTHCHARGE	`:sonar-sweep`	2	WRECK (large signature, ID only), CARGO POD (small signature, payout), NULL CONTACT (rep penalty if EVAL’d)	`sonar/sweep`

Each baseline is single-phase only. Each provides a single verb (the simplest from its cart’s set). Reputation/credit rewards are training-tier (200–800¤ for TERMINAL/AUDIT/SONAR; reputation only for GRID, matching NEONGRID’s training-tier reward model in launch-titles-capability.md).

Add a :supersedes field on register-mission-contributions. When a cart’s contribution declares :supersedes :baseline-name, Mission Control drops the baseline’s schema selection weight to 5% (variety only) for as long as the cart is in any non-System registry tier (currently Inserted; future Recent once the decay-model ADR lands). The baseline returns to full weight when the cart leaves all non-System tiers.
Threat-cap inheritance. Mission Control honors :threat-cap per contributing module. A composed contract inherits the highest cap from any contributing module. A composition drawing only from System-tier modules caps at threat 2 (or 1, in GRID’s case). 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. The System tier teaches the deck; it does not carry it. Two baselines cannot compose into a 2-phase contract. The four System baselines do not compose with each other.
Implementation shape: Lisp virtual carts in the system image. Each baseline lives at system-image/baselines/{terminal,grid,audit,sonar}.lsp, using the same register-mission-contributions and defcontract-schema machinery as cart code. The runtime registers them at nosh_init after deck-state hydration. No new code paths — baselines are virtual carts loaded from system image rather than SD. Storage cost: ~2–5 KB per baseline (estimated), 8–20 KB total in the system image.
No-precedent rule. Only the four launch-cart domains get System-tier baselines. Future capability 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 baselines. Justification: the four launch-cart domains define the deck’s identity floor; everything else is genuine cart territory.
No publisher splash on System-tier modules. Cart-tier modules retain publisher_splash per ADR-0006 / orchestration.md §Software Publishers. System-tier modules do not. The visual-and-audio difference at registration time is one of the operator-felt distinctions between tier and cart.

Options Considered

Option A: System-tier baselines for all four launch-cart domains. (ACCEPTED)

What it is. Ship TERMINAL, GRID, AUDIT, SONAR in the system image. Each cart supersedes its baseline. Bare deck has substantially playable gameplay across all four foundational domains.

Chosen because it delivers an out-of-box experience matching the deck’s positioning, recovers gracefully from cart-loss across every launch domain, gives every operator a training-tier bridge to cart depth, and sharpens each cart’s identity as “the upgrade.” Engineering cost (4× baseline modules) is mitigated by the virtual-cart implementation.

Option B: System-tier baseline only for ICE BREAKER → TERMINAL.

What it is. Ship TERMINAL only. NEONGRID, BLACK LEDGER, DEPTHCHARGE remain cart-gated.

Rejected because it fixes one of four domains. An operator without ICE BREAKER’s cart still has training-tier network intrusion; an operator without NEONGRID’s cart cannot do spatial training at all. The asymmetric out-of-box experience is worse than either uniform direction. If TERMINAL is worth the engineering, the other three are too.

Option C: No System-tier baselines; expanded bare-deck bounty pool only.

What it is. No tier addition. Add more bare-deck bounties — additional diagnostic exercises, additional link-cooperation challenges, perhaps scripted-mission tutorials.

Rejected because it doesn’t recover cart-loss scenarios (the lost domain stays gone), doesn’t bridge to cart depth (bounties are mechanically narrow — diagnostic + link), and doesn’t represent the deck’s foundational domains. An operator running expanded bare-deck bounties is doing diagnostics, not running terminals.

Option D: Pack-in cart with explicit recovery path.

What it is. Cartridges remain canonical for all gameplay. Address cart-loss with a Relay-mediated recovery utility that re-flashes a blank cart from a master image stored in the firmware partition.

Rejected because every operator must own four cartridges to access the deck’s foundational domains. Out-of-box experience without a cart inserted is bare-deck bounties only — the same problem Option C has. Recovery utility solves loss but not the fundamental “deck is unenjoyable without cart” problem. Preserves cart purity at the cost of the product story.

Trade-off Analysis

Dimension	Option A (chosen)	Option B (TERMINAL only)	Option C (bounties)	Option D (recovery)
Out-of-box gameplay across four domains	✓	◐ one of four	✗ bounties only	✗ bounties only
Cart-loss graceful degradation	✓ all domains	◐ one of four	✗	◐ requires utility flow
Training-tier bridge to cart depth	✓ all domains	◐ one of four	✗	✗
Cart-amplification clarity	✓ “cart upgrades existing capability”	◐ for one cart	✗	✗
Cartridge model preserved	✓ baselines are bounded	✓ same	✓ unchanged	✓ unchanged
Engineering cost	4× baseline modules	1× baseline	content only	recovery utility
Spec-doc maintenance	4× baseline specs	1× baseline spec	minimal	recovery doc
Slippery-slope risk	Bounded by no-precedent rule	Bounded	None	None
Marketing story	”deck plays out of the box"	"ICE BREAKER built in, others require cart"	"deck has training mode"	"deck requires carts; carts replaceable”

Cost we accept: 4× baseline engineering and 4× spec docs. Mitigated by the virtual-cart implementation reusing existing machinery — no new runtime code paths, just additional Lisp modules in the system image.

Consequences

Positive

Out-of-box experience is substantially playable across four foundational domains (network intrusion, spatial, forensic, sonar) without any cart inserted.
Cart-loss recovery is graceful: domain reverts to baseline until cart returns; reputation and credits accrued during cart-tier play are unaffected (they live in UDS, not the cart).
Each cart’s identity sharpens: the cart is the upgrade, not the prerequisite. Cart-amplification is operator-felt — when the cart is registered, the threat ceiling jumps, additional verbs become composable, multi-phase contracts unlock.
Operators learn the four domains’ mechanics at training tier before investing in cart-tier depth. Cart purchases follow exposure rather than prerequisite gating.
The supersedes mechanic gives Mission Control a clean way to handle the cart-arrives / cart-leaves transitions without registry churn.

Negative / Accepted costs

4× baseline engineering: Lisp modules, ICE/sentry/transaction/contact pattern libraries, schema definitions, mission generators.
4× spec docs to maintain alongside the four cart specs.
Mission Control gains the :supersedes machinery and threat-cap inheritance. Both are bounded extensions, not architectural shifts.
ADR-0028’s registry tier model extends from two-state (Registered / Inserted) to four-tier (System / Inserted / Recent / Historical). Consequence amendment to ADR-0028 lands in this PR’s documentation updates.
Risk: operators may not feel the cart upgrade is worth the price if the baseline is too capable. Mitigated by hard caps: baseline threat ≤ 2 (≤ 1 for GRID), single-phase only, single-verb only, no cross-module composition, no publisher splash. The cart’s value is unambiguous on every operator-felt dimension.
Risk: the “no future cart gets a baseline” rule is a policy, not a mechanism. Future maintainers may re-litigate it. Mitigated by documenting the no-precedent rule explicitly in this ADR and in mission-control.md.

Follow-on work this ADR creates

Spec docs (NEW): software/runtime/baselines/terminal.md, grid.md, audit.md, sonar.md. Each documents the baseline’s verb mechanics, pattern library, schemas, and cart-relationship.
Lisp implementations: system-image/baselines/{terminal,grid,audit,sonar}.lsp. Engineering follow-up tracked separately.
System image build: include baseline modules in the runtime image; register at nosh_init. Engineering follow-up.
ADR-0028 amendment: registry tier model extends from two-state to four-tier; introduces :supersedes machinery; introduces threat-cap inheritance.
ADR-0006 amendment: CART_CAPABILITIES allowlist gains :supersedes keyword.
mission-control.md update: §2 adds System tier; §3 adds threat-cap inheritance and supersedes-driven schema weighting; §6 references the no-precedent rule.
launch-titles-capability.md updates: each cart’s (register-capabilities ...) block adds :supersedes :baseline-name and :threat-cap N. Spelled out per cart in the Documentation Updates list.
bare-deck-terminal.md STATUS tab: System tier rendered separately from registered carts. Shows TERMINAL / GRID / AUDIT / SONAR as always-present, with a clear visual distinction (no provenance, no last-seen timestamp, no INSERT-TO-RESTORE affordance).
cipher-voice.md: new event types :cart-supersedes-baseline (cart enters non-System tier; baseline drops to variety weight) and :baseline-restored (cart leaves all non-System tiers; baseline returns to full weight). Affect: :routine for both — these are registry transitions, not gameplay events.
Decay-model ADR (sibling): the Recent / Historical tiers referenced by this ADR are forward-compatible with the brainstormed decay model; that decision lands in its own ADR. This ADR works without it (System / Inserted only) and is enhanced by it (System / Inserted / Recent / Historical).

Documentation Updates (REQUIRED — part of the decision, not aspirational)

Narrative

For its first year the spec assumed the cartridge is the only path to capability. A deck without a cart in slot composed from bare-deck bounties only — diagnostic exercises and link-cooperation challenges that taught the input grammar but did not represent the device’s gameplay. ADR-0030 introduces a System tier in the Capability Registry and ships four baseline modules — TERMINAL, GRID, AUDIT, SONAR — one per launch-cart domain. Each baseline is bounded: a single verb, threat cap 2, single-phase only, training-tier rewards. The cart, when registered, supersedes its baseline and unlocks the domain’s full depth — additional verbs, raised threat cap, multi-phase compositions, cross-module linkage. The deck out of the box is recognizable as the device it is meant to be. The cart is recognized as what makes it serious. The cartridge model remains canonical, and the baseline tier is bounded to the four launch-cart domains by an explicit no-precedent rule. Future cart domains require their cart, full stop.

Amendment — 2026-06-20 (scope clarification per ADR-0042)

Status effect: Accepted (unchanged). No decision changes; this note draws a boundary that was always implicit.

ADR-0042 charters the device’s first-party on-device programs (thirteen of them — Mission Board, Deck Hub, REPL, nEmacs, CONDUIT, Kinoshita Kommander, AmberCalc, RIPSAW, Keyring, kn9, DOSSIER, bzbx, knSALK). In doing so it observed that this ADR’s no-precedent rule (Decision item 7 / the “No slippery slope” constraint) had been read as a cap on the device’s entire first-party software set — “only four apps.”

That reading is wrong, and this note records the correction:

The no-precedent rule governs mission capability baselines — the System-tier mission generators TERMINAL / GRID / AUDIT / SONAR. It stays fully in force for them: exactly four, and no future cart domain earns a baseline.
It does not govern first-party programs — the operator’s toolkit (filesystem navigator, spreadsheet, editor, comms client, defense bundle, …). Those are a different category entirely (not mission generators, no Capability Registry presence, never superseded by a cart), and their roster is chartered by ADR-0042.

In short: baselines and programs are different things; ADR-0030 bounds the former, ADR-0042 charters the latter. Nothing in this ADR’s Decision, Options, or Trade-off analysis changes.