AUDIT — System-Tier Forensic Trace Baseline

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

1. Identity

AUDIT is a runtime-tier minimum-viable forensic-trace capability. It ships in the system image (Lisp virtual cart at system-image/baselines/audit.lsp) and registers automatically at nosh_init. It is the deck’s identity floor for the financial / investigative domain.

AUDIT is bounded to linear transaction chains — no branching graphs, no shell company trees. Operator follows a 3–5 transaction chain from origin to destination, identifies the suspicious transaction, flags it. Wall-clock time pressure adds urgency (60 seconds at threat 1, 45 at threat 2).

2. Verb mechanics — `:audit-trace`

The operator inspects a linear transaction chain rendered on the 80×25 grid as a vertical list. Each transaction shows:

TX ID — sequential, e.g., TX-001 through TX-005
Amount — currency value (visible or masked depending on transaction type)
From / To — account identifiers (8-char hex + label)
Timestamp — relative offset within the audit window
Status — clean, obfuscated, or flagged (operator must determine)

Operator interaction:

Key	Action
`[CDR]`	Move to next transaction in the chain
`[CAR]`	Inspect transaction (open detail view: full account info, related metadata, hashes)
`[EVAL]`	Apply current technique to current transaction (decode if obfuscated; flag if suspicious)
`[QUOTE]`	Mark transaction for return-inspection (used when operator wants to compare two non-adjacent entries)
`[NIL]`	Submit final flag selection

Operator state:

Time remaining: wall-clock countdown displayed on Row 24. Hits 0 → mission fails.
Decoded set: which OBFUSCATED transactions have been decoded.
Flag selection: which transaction the operator believes is FLAGGED. Submit via [NIL]. Correct → :result-success; wrong → :result-failure.

3. Pattern library

AUDIT ships three transaction patterns. The cart (BLACK LEDGER) ships shell-corp trees, branching graphs, audit signatures, reconstruction primitives.

3.1 CLEAN TRANSACTION

Legitimate transfer between two accounts. No anomalies. Visible amount, visible accounts, audit trail intact.

State	Behavior
`verified` (only state)	`[CAR]` shows full transaction details; no decode needed; flagging this transaction → `:result-failure` (wrong answer)

Operator strategy: skim past CLEAN TXs; the answer is elsewhere.

3.2 OBFUSCATED TRANSACTION

Amount and/or one account ID masked. Requires [EVAL] to decode.

State	Trigger	Transition
`obfuscated`	Operator `[EVAL]` on this transaction	→ `decoded`; reveals true amount + accounts; CIPHER emits `:observation`/`:routine`
`decoded`	(no further action)	Now displays normally; flagging it requires the operator to evaluate whether the decoded transaction is suspicious

Decoding takes a small wall-clock cost (~3–5 seconds simulated, 0 seconds real). Some OBFUSCATED transactions are CLEAN once decoded; some are FLAGGED. The operator must decode before they can correctly evaluate.

3.3 FLAGGED TRANSACTION

The target. Exactly one per chain. Visually similar to CLEAN or OBFUSCATED but contains the audit signature the operator is looking for. Flagging it → :result-success; missing it (running out of time, or flagging a different transaction) → :result-failure.

State	Trigger	Transition
`unflagged`	Operator `[EVAL]` on this transaction with intent-to-flag	→ `flagged`; visual indication; chain holds the flag until `[NIL]` submits
`flagged`	Operator `[EVAL]` again	→ `unflagged` (toggles off; lets operator change their mind)

Operator strategy: the FLAGGED transaction has a subtle anomaly — round-number amount that doesn’t match the expected pattern, account ID with one transposed character, timestamp that doesn’t sequence cleanly. The hint type varies per scenario.

4. Schemas

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

4.1 `audit/trace`

(defcontract-schema :audit/trace
  :required-capabilities '(:audit-trace)
  :threat-range          '(1 2)
  :phase-count           1
  :noun-generators       '(linear-transaction-chain account-identifiers timestamp-offsets)
  :condition-generators  '(obfuscation-density flag-anomaly-type wall-clock-budget)
  :payout-formula        contract-payout-baseline   ; 300-450¤ at threat 1; 450-600¤ at threat 2
  :ttl-range             '(7200 28800)              ; 2-8 hours (Standard tier)
  :opportunity-weight    1.0)

Objective: identify and flag the FLAGGED transaction within the time budget.

Chain length:

Threat 1: 3 transactions (1 FLAGGED, 1–2 CLEAN, 0–1 OBFUSCATED)
Threat 2: 5 transactions (1 FLAGGED, 2–3 CLEAN, 1–2 OBFUSCATED)

Wall-clock budget:

Threat 1: 60 seconds
Threat 2: 45 seconds

Bonus conditions:

:speed — flagged correctly with > 50% time remaining
:no-misdecodes — only decoded transactions that turned out to require decoding (no wasted decode attempts)
:first-look — flagged correctly without [CAR]-inspecting any non-flagged transaction in detail

5. Reward and economy

Schema	Threat	Payout range	Reputation gain (success)	Reputation loss (failure)
`audit/trace`	1	300–450 ¤	+3	−2
`audit/trace`	2	450–600 ¤	+6	−3

Bonus conditions add 25% to base payout each. Multiple bonuses stack additively (:speed + :no-misdecodes = +50%).

Failure modes:

Time out: budget hits 0 before submission → :result-failure, half reputation loss
Wrong flag: submitted a non-FLAGGED transaction → :result-failure, full reputation loss
Abandon: [NIL] without flagging → treated as wrong flag

6. Relationship to BLACK LEDGER (the cart that supersedes this)

When BLACK LEDGER is registered (Inserted or Recent tier), AUDIT’s audit/trace schema drops to 5% of base selection weight. The board fills with BLACK LEDGER’s AUDIT / RECONSTRUCTION / FORENSIC TRACE / SHELL MAPPING schemas at threat 2–5.

When BLACK LEDGER leaves all non-System tiers, AUDIT 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: BLACK LEDGER provides a phase-2 hook for ICE BREAKER SABOTAGE contracts (per launch-titles-capability.md §3: “ICE BREAKER SABOTAGE contracts now have an automatic phase 2 (financial cover-up)”). AUDIT does NOT provide this cross-module hook — the hook is cart-tier and gated by ADR-0030 §3.2.2 (System-only compositions are single-phase).

7. What AUDIT does NOT do

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

Verbs: :forensic-accounting (deep pattern matching across many transactions), :transaction-reconstruction (filling missing data from partial chains), :shell-mapping (subsidiary tree analysis) — cart only.
Branching transaction graphs: anything beyond a linear chain — cart only.
Larger chains: cart-tier scenarios run 10–30+ transactions; AUDIT caps at 5.
Audit signatures: subtle pattern-match primitives that recognize specific embezzlement / money-laundering / tax-evasion shapes — cart only.
Cross-module phase 2 hooks: ICE BREAKER SABOTAGE → BLACK LEDGER cover-up reconstruction — cart only.
Bureau 9 publisher splash: the silent typeout loader (per orchestration.md §Software Publishers, Bureau 9 section) — cart only. AUDIT boots silently.
Reputation-tier-locked content: government-sealed scenarios — cart only.

8. Implementation reference

;; system-image/baselines/audit.lsp

(register-mission-contributions
  :module      :audit
  :tier        :system
  :verbs       '((:audit-trace
                   :nouns      '(linear-transaction-chain account-identifiers timestamp-offsets)
                   :conditions '(obfuscation-density flag-anomaly-type wall-clock-budget)
                   :modifiers  '(:speed-bonus :no-misdecodes-bonus :first-look-bonus)))
  :affinities  '(:financial :investigative)
  :threat-cap  2
  :transaction-patterns '(audit/clean-txn
                          audit/obfuscated-txn
                          audit/flagged-txn))

(defcontract-schema :audit/trace ...)   ; per §4.1

;; Transaction pattern definitions, anomaly generators, payout formulas follow.

Engineering scope: ~300–500 lines of Lisp + a transaction-anomaly generator library. The wall-clock pressure mechanic uses the existing tick infrastructure; no new runtime support needed.

9. Out of scope for this spec

Cart-side BLACK LEDGER mechanics — see ../../cartridges/design-bibles/launch-titles-capability.md §3 BLACK LEDGER and ../../cartridges/modules/black-ledger.md (when authored).
Mission Control’s composition algorithm — see ../mission-control.md §3.
The Mission Runner environment (REPL bindings during an AUDIT contract) — see ../../programs/repl.md §4A and ADR-0029.
Cross-domain contracts (e.g., AUDIT → TERMINAL or AUDIT-as-phase-2) — disallowed by ADR-0030 §3.2.2.