Skip to content

SONAR — System-Tier Sonar Sweep Baseline

Verb provided: :sonar-sweep Threat cap: 2 Superseded by: DEPTHCHARGE (:supersedes :sonar, threat cap 5) Implementation: system-image/baselines/sonar.lsp Companion docs: mission-control.md (§2 registry tiers, §3.2 composition rules), ../../cartridges/design-bibles/launch-titles-capability.md §4 DEPTHCHARGE (the cart that supersedes this baseline)


SONAR is a runtime-tier minimum-viable maritime-sonar capability. It ships in the system image (Lisp virtual cart at system-image/baselines/sonar.lsp) and registers automatically at nosh_init. It is the deck’s identity floor for the maritime / acoustic domain.

SONAR is bounded to shallow water, static contacts. No depth profiles (no pressure mechanics), no moving targets (no currents, no fleeing), no salvage (no hardware recovery). The operator sweeps a search arc, locates a single static contact, identifies it. The DEPTHCHARGE cart adds depth, motion, salvage, evasion, relay-station deployment.

SONAR uses the BITMAP display mode for its sweep arc rendering (per ADR-0014’s 960×600 logical framebuffer). This is the only baseline that uses bitmap mode — TERMINAL, GRID, AUDIT all run text-mode only. Engineering implication: SONAR’s Lisp module exercises gfx-circle, gfx-line, gfx-pixel per ADR-0005’s Tier 1 graphics primitives.


The display splits: a sonar arc rendered in bitmap mode (top portion) showing a radial sweep over a search area, with text-mode status lines below (Row 18+ for status, Row 24 for action bar).

The sweep is a single-axis line that rotates clockwise from a center point (the operator’s surface vessel position). Each rotation completes in ~2 seconds wall-clock at threat 1, ~1.5 seconds at threat 2.

When the sweep crosses a contact:

  • A bright pulse appears at the contact’s bearing/range
  • A PSG ping plays (Channel A, ~1500 Hz, 100 ms; per ADR-0017 the audio is marshaled to the Pico 2 coprocessor)
  • A signature classification appears in the status area: WRECK, CARGO POD, or NULL

The operator’s job: identify the contact and [EVAL] to confirm classification before submitting via [NIL].

Operator interaction:

KeyAction
[CDR]Cycle through detected contacts (when multiple have been pinged in a sweep, this scrolls the inspector)
[CAR]Inspect current contact (signature strength, depth band, bearing)
[EVAL]Classify the current contact: :wreck, :cargo, or :null (operator chooses)
[NIL]Submit current classifications

Operator state:

  • Sweep count: how many full rotations have completed. Schema sets a budget (e.g., 3 sweeps); after the budget, the contract auto-submits with whatever classifications the operator has confirmed.
  • Classifications confirmed: a list of (contact-id, classification) pairs the operator has [EVAL]-d.

Submission accuracy:

  • All contacts correctly classified: :result-success
  • Wrong classification on any contact: :result-failure
  • Failed to classify a contact (timed out without [EVAL]): :result-partial if the missed contact is :cargo; :result-failure if a :wreck was missed (wrecks are mission-critical — operator must confirm them)

SONAR ships three contact types. The cart (DEPTHCHARGE) ships moving contacts, fleeing targets, depth-stratified contacts, encrypted hardware, relay stations, multi-contact swarms.

Large signature, easy to find. Identification only — no payout. Contributes reputation and contract completion.

PropertyValue
Signature strengthHigh (visible on first sweep)
Depth bandShallow only (SONAR baseline = no depth mechanics)
Confirmation[EVAL] with :wreck
On correct IDReputation +2; no credit
On wrong ID:result-failure; reputation −2

Small signature, harder to detect (may take 2–3 sweeps to locate). Confirms-out for credit payout.

PropertyValue
Signature strengthLow (harder to spot at long bearing)
Depth bandShallow only
Confirmation[EVAL] with :cargo
On correct ID200–400 ¤ + reputation +2
On wrong ID:result-failure; reputation −2

False positive. Sweep returns a signature, but the contact is acoustic noise — a thermal layer, a rock outcrop, fish schools. Classifying it as anything other than :null is a mistake.

PropertyValue
Signature strengthMid (looks like a real contact at first glance)
Confirmation[EVAL] with :null
On correct IDReputation +1 (the operator correctly disqualified it)
On wrong ID:result-failure; reputation −3 (operator misclassified noise as cargo or wreck)

NULL CONTACTs are how SONAR teaches discrimination. The operator learns to [CAR] and inspect signature strength + bearing pattern before classifying — sloppy :cargo calls on every blip are punished.


SONAR ships one defcontract-schema form. Single-phase, threat 1–2, payout 200–600 ¤.

(defcontract-schema :sonar/sweep
:required-capabilities '(:sonar-sweep)
:threat-range '(1 2)
:phase-count 1
:noun-generators '(search-area-bounds vessel-position contact-positions)
:condition-generators '(contact-mix sweep-budget signature-noise-floor)
:payout-formula contract-payout-baseline ; 200-400¤ at threat 1; 400-600¤ at threat 2
:ttl-range '(7200 28800) ; 2-8 hours (Standard tier)
:opportunity-weight 1.0)

Objective: complete classifications for all contacts within the sweep budget.

Search area: ~20 km² (rendered as a circular sonar field on the bitmap display).

Contact mix:

  • Threat 1: 1–2 contacts. Composition: 1 WRECK or 1 CARGO POD; possibly 1 NULL CONTACT.
  • Threat 2: 2–3 contacts. Composition: 1 WRECK + 1 CARGO POD + 0–1 NULL CONTACT.

Sweep budget:

  • Threat 1: 4 sweeps (~8 seconds wall-clock)
  • Threat 2: 3 sweeps (~5 seconds wall-clock; tighter)

Bonus conditions:

  • :speed — submitted with sweep budget unused (≥ 1 sweep remaining)
  • :full-confirm — every contact classified before submission (no :result-partial outcomes)
  • :no-false-positive — never [EVAL]-d a NULL CONTACT as :wreck or :cargo (only correct or :null)

SchemaThreatPayout rangeReputation gain (success)Reputation loss (failure)
sonar/sweep1200–400 ¤+3−2
sonar/sweep2400–600 ¤+5−3

WRECK-only missions pay reputation but no credits — the operator’s reward is identification. CARGO POD missions pay credits proportional to signature strength.

Bonus conditions add 25% to base payout each.


6. Relationship to DEPTHCHARGE (the cart that supersedes this)

Section titled “6. Relationship to DEPTHCHARGE (the cart that supersedes this)”

When DEPTHCHARGE is registered (Inserted or Recent tier), SONAR’s sonar/sweep schema drops to 5% of base selection weight. The board fills with DEPTHCHARGE’s SONAR SWEEP / SALVAGE / EVASION / RELAY ACCESS schemas at threat 2–5.

When DEPTHCHARGE leaves all non-System tiers, SONAR returns to full selection weight.

CIPHER emits :cart-supersedes-baseline and :baseline-restored at the registry transitions.

A note on the cart’s cross-module value: DEPTHCHARGE enables ICE BREAKER SURVEILLANCE implants on underwater relay stations (per launch-titles-capability.md §4: “ICE BREAKER SURVEILLANCE implants can be deployed on underwater relay stations”). SONAR does NOT enable cross-module relay deployment — that’s cart-tier and gated by ADR-0030 §3.2.2.


Explicitly out of scope for the baseline. The cart owns these:

  • Verbs: :underwater-navigation (piloting the submersible at depth), :maritime-salvage (recovering hardware), :submersible-evasion (active threat avoidance from territorial defenders), :relay-access (deploying or compromising encrypted relay stations) — cart only.
  • Depth profiles: pressure mechanics, hull integrity, descent budgets — cart only. SONAR is shallow-water only.
  • Moving contacts: currents, fleeing targets, contact-velocity tracking — cart only.
  • Salvage mechanics: recovering encrypted hardware, decrypting at depth, surfacing with cargo — cart only.
  • Multi-contact dynamics: contact swarms, coordinated targets, ASW (anti-submersible warfare) defenders — cart only.
  • Cross-module relay deployment: DEPTHCHARGE’s hook for ICE BREAKER SURVEILLANCE on underwater relays — cart only.
  • Pacific Rim Dynamics publisher splash: the rotating sonar sweep with descending tones (per orchestration.md §Software Publishers, Pacific Rim section) — cart only. SONAR boots silently into the search.

;; system-image/baselines/sonar.lsp
(register-mission-contributions
:module :sonar
:tier :system
:verbs '((:sonar-sweep
:nouns '(search-area-bounds vessel-position contact-positions)
:conditions '(contact-mix sweep-budget signature-noise-floor)
:modifiers '(:speed-bonus :full-confirm-bonus :no-false-positive-bonus)))
:affinities '(:maritime :spatial :acoustic)
:threat-cap 2
:contact-types '(sonar/wreck
sonar/cargo-pod
sonar/null-contact))
(defcontract-schema :sonar/sweep ...) ; per §4.1
;; Contact-type definitions, signature generators, sweep rendering primitives,
;; PSG ping definitions follow.

Engineering scope: ~400–600 lines of Lisp. SONAR’s bitmap-mode rendering for the sweep arc is the heaviest baseline implementation (the other three are text-mode only). Uses ADR-0005 Tier 1 graphics primitives (gfx-circle, gfx-line, gfx-pixel) and Tier 1 sound primitives (sound-tone, psg-write for the ping audio routed to the Pico 2 coprocessor per ADR-0017).


  • Cart-side DEPTHCHARGE mechanics — see ../../cartridges/design-bibles/launch-titles-capability.md §4 DEPTHCHARGE and ../../cartridges/modules/depthcharge.md (when authored).
  • Mission Control’s composition algorithm — see ../mission-control.md §3.
  • The Mission Runner environment (REPL bindings during a SONAR sweep) — see ../../programs/repl.md §4A and ADR-0029.
  • Cross-domain contracts (e.g., SONAR → TERMINAL underwater relay surveillance) — disallowed by ADR-0030 §3.2.2.
  • Coprocessor protocol details for the PSG ping — see ../../api-reference/grammars/coprocessor-protocol.md and ADR-0017.