BLACK LEDGER GAMEPLAY SPECIFICATION — ROUND 1 DESIGN EVALUATION

Gold Standard: ICE BREAKER Gameplay Specification v1.0
Evaluation Scope: Structural completeness, OODA depth, system interaction, key mapping, cell architecture, sound design, screen layout, cross-module integration, onboarding, and target audience fit.

OVERALL SCORE: 44 / 50

Verdict: PASS

This is a strong, playable specification that respects the KN-86 platform architecture and delivers a compelling investigative deduction experience. The move-limited investigation loop is mechanically sound and creates genuine skill expression. Cell architecture is detailed and implementable. Cross-module integration with ICE BREAKER is well-thought-out.

However, there are 5 specific gaps that prevent this from being exemplary. Most are addressable with targeted revisions. One (cell architecture documentation for CASE_BOARD) is a minor organizational issue.

SCORING BREAKDOWN

1. STRUCTURAL COMPLETENESS — 5/5

Criterion: Does it have all 16 sections from the gold standard?

Status: COMPLETE.

Black Ledger has all 16 sections mirroring ICE Breaker’s structure:

✓ Design Philosophy
✓ 1. THE INVESTIGATION LOOP: ATOMIC UNIT OF PLAY (SCAN-ASSESS-TRACE-EXPOSE)
✓ 2. SYSTEM ONE: THE LEDGER HIERARCHY
✓ 3. SYSTEM TWO: INVESTIGATION TOOLS
✓ 4. SYSTEM THREE: CASE SCORING AND VERDICT
✓ 5. SYSTEM FOUR: SOUND AS FORENSIC TOOL
✓ 6. EMERGENT COLLISIONS
✓ 7. SESSION SHAPE: EMOTIONAL ARC
✓ 8. ONBOARDING: THE FIRST FIVE MINUTES
✓ 9. PROFICIENCY METRIC: LOGIC_INDEX
✓ 10. LINKED PLAY: ASYMMETRIC TWO-PLAYER AUDIT
✓ 11. CELL ARCHITECTURE
✓ 12. KEY MAPPING TABLE
✓ 13. MISSION TEMPLATE DEFINITIONS
✓ 14. DETAILED SCREEN LAYOUTS (ASCII WIREFRAMES) — 7 screens provided
✓ 15. CROSS-MODULE INTEGRATION
✓ 16. IMPLEMENTATION NOTES

The structure is comprehensive and parallel-capable to ICE Breaker. No sections are missing.

2. OODA / CORE LOOP DEPTH — 4/5

Criterion: Is the SCAN-ASSESS-TRACE-EXPOSE cycle defined with timing, sensory channels, and decision points? Can you feel the investigative rhythm?

Status: STRONG, but timing is imprecise.

Strengths:

The SCAN-ASSESS-TRACE-EXPOSE cycle is well-articulated and distinct from ICE Breaker’s OBSERVE-ORIENT-DECIDE-ACT. ✓
Each phase has clear sensory channels:
- Voice 1: Investigation theme (tempo accelerates under time pressure, minor-key to major resolution)
- Voice 2: Transaction tone signatures (C4=legitimate, D4=unusual, E4=suspicious, F#4=highly suspicious)
- Voice 3: Feedback (bell tones, harmonic stacks, verdict resolution)
Decision points are explicit: SCAN identifies red flags, ASSESS drills into accounts, TRACE follows money with CAR/EQ, EXPOSE constructs evidence chains with CONS.
The 45-minute session walkthrough (section 7) demonstrates emotional arc: buildup (5-15 min), confidence (15-30 min), theory refinement (30-40 min), verification (40-45 min).
Move budgets create decision pressure mirroring ICE Breaker’s tempo pressure, but through resource depletion rather than real-time threat.

Weakness:

Cycle timing is loosely specified. ICE Breaker is precise: “A single OODA cycle takes 2-5 seconds in the early game, 0.5-2 seconds in expert play.” Black Ledger says “Threat 2 cases are 20-30 minutes” but does not specify the rhythm of individual SCAN-ASSESS-TRACE-EXPOSE micro-cycles. How long does each phase take? Does the operator cycle through a 2-minute SCAN, then a 5-minute ASSESS? The spec treats the investigation as a linear 45-minute experience (section 7) rather than oscillating cycles. This is fine—it is a different game—but the cycle timing lacks the precision of ICE Breaker’s model.
Sensory channel depth is uneven. Voice 2 transaction tone signatures are brilliant. Voice 1 and Voice 3 are less detailed compared to ICE Breaker’s sound design (which specifies JUNK vs. BLACK vs. RED vs. HUNTER attack signatures). The verdict tones (major arpeggio for success, unresolved minor for failure) are good but brief.

Minor issue: The spec says “Voice 2 pitches tell them which transactions are suspicious” and “An experienced operator can work with the screen dimmed or off, relying entirely on audio.” This is aspirational but not fully developed. ICE Breaker’s sound-only play is documented in detail (section 5, “Playing by Ear as Advanced Technique”). Black Ledger mentions it once but doesn’t provide the full sensory specification for a screen-off operator. This is acceptable for a first spec, but it’s underdeveloped.

Score: 4/5 — The cycle is clear and emotionally coherent, but timing precision and sound-only play are underdeveloped compared to the gold standard.

3. SYSTEM INTERACTION — 5/5

Criterion: Do the ledger hierarchy, investigation tools, case scoring systems, and move budgets create emergent behavior? Are collisions documented?

Status: EXCELLENT.

Strengths:

Ledger hierarchy creates information asymmetry. The operator cannot see all accounts at once; they must navigate CAR by CAR. Screen real estate limits display to ~5 transactions per account view. This forces prioritization and pattern recognition—the core tension.
Move budgets create resource constraints. Unlike ICE Breaker’s tools (consumable per use), Black Ledger’s CAR/QUOTE/EQ budgets are finite pools. An operator who explores every account exhausts their CAR budget before deep investigation. This incentivizes strategic prioritization.
Four emergent collisions are documented (section 6):
1. Red Herring Collision: Large offshore transfer looks like money laundering but is actually legitimate restructuring. Teaches precision over assumption.
2. Deletion Collision: Deleted transaction inference puzzle. One wrong piece breaks the entire solution. Teaches precision.
3. Shell Network Conspiracy Collision: Operator discovers the graph is non-linear (branching, not sequential). Revises mental model. Teaches systems thinking.
4. Time Pressure Collision: Operator must choose between careful exploration (high certainty, timeout risk) vs. fast pattern recognition (speed, false flag risk). Teaches expertise = knowing when to be fast/slow.
All collisions are mechanically grounded, not narrative hand-waving. They emerge from the rule set interacting with player behavior.
Scoring is asymmetric (false flags -50 vs. missed guilty -100), creating distinct decision pressure around flagging strategy.

Specific evidence:

The failed case example (section 7) shows the operator running out of moves and time, forced into a panicked submission. This is an emergent failure state.
The evidence chain mechanic (CONS) is free to construct but time-consuming, creating a time-vs.-thoroughness tradeoff.

Score: 5/5 — System interactions are well-documented and create meaningful emergent behavior. Collisions feel organic.

4. KEY MAPPING RIGOR — 4/5

Criterion: Is every key accounted for in every cell type? Black Ledger uses PURE NUMERIC numpad (no directional). Are QUOTE+EQ forensic comparison mechanics fully specified? Is CONS (link evidence) defined? Is LAMBDA (audit macro) detailed?

Status: COMPREHENSIVE, with one notable gap.

Strengths:

All 14 function keys are mapped (section 12, KEY MAPPING TABLE):
- CAR: Drill into account (1 CAR move)
- CDR: Navigate/Scroll (free)
- CONS: Link Evidence (free)
- NIL: Clear/Unflag (free)
- ATOM: Test if Leaf (free)
- EQ: Compare Transactions (1 EQ move)
- EVAL: Submit/Confirm (free or submit)
- QUOTE: Flag Suspicious (1 QUOTE move)
- LAMBDA: Record Trace (free, unlock at Logic_Index 40+)
- APPLY: Replay Trace (free)
- BACK: Return/Exit (free)
- INFO: View Cycle (free)
- LINK: Linked Audit (free)
- SYS: System Menu (free)
All 16 numpad keys are mapped to numeric entry, filters, and analysis:
- 0-9: Numeric entry (account IDs, amounts, search)
- ENT: Confirm input
- +: Credit filter (inflows only)
- -: Debit filter (outflows only)
- ×: Ratio analysis
- ÷: Reverse lookup (find transactions by amount)
Pure numeric numpad is respected. No directional overloading (8/2/4/6). This is correct per the UI design system (4.5 Numpad Conventions: “Data-first: Numpad delivers raw digits”).
QUOTE+EQ mechanics are fully specified:
- QUOTE marks transaction as suspicious (1 move, plays bell tone)
- EQ compares two transactions (1 move, plays major third for match / diminished for mismatch)
- Both are documented with visual output and audio feedback
CONS (link evidence) is detailed (section 3, “CONS: Link Evidence Into Chains”):
- Free to construct (unlimited evidence chains)
- Builds narratives like “Bribery Money Laundry”
- Links multiple flagged transactions into a coherent story
- Judge evaluates narrative_match (80%+ = +300 bonus, <50% = -100 penalty)
LAMBDA/APPLY (macros) is defined:
- LAMBDA: Begin recording a trace sequence (up to 20 actions: CAR, CDR, QUOTE)
- APPLY: Replay macro on a different starting account
- Unlock at Logic_Index 40+ (introduced at CASE 3)
- Free to use, but planning-intensive

Weakness:

ATOM (Test if Leaf) is underspecified. The spec says “Determine if account has child accounts” but does not specify the operator feedback, audio cue, or use case. Is this used to verify an account is a shell (shells have no children)? Does it play an audio confirmation? Does it consume a move? The section 11 (Cell Architecture) mentions on_atom(ACCOUNT *this) but the handler is not defined. This is a minor gap but breaks the “every key accounted for in every cell” criterion.

Score: 4/5 — Nearly complete key mapping. ATOM is underspecified. Everything else is rigorous.

5. CELL ARCHITECTURE — 4/5

Criterion: This is CRITICAL for Black Ledger — the entire game IS cell navigation. Are ACCOUNT, TRANSACTION, EVIDENCE_CHAIN, and CASE cell types fully defined with fields and handler signatures?

Status: MOSTLY COMPLETE, with one critical omission.

Strengths:

ACCOUNT cell is fully defined (section 11):

typedef struct {
    uint16_t account_id;
    char name[48];
    uint8_t account_type;  // Holding, Subsidiary, Shell, Offshore, Front
    char jurisdiction[32];
    uint32_t current_balance;
    uint16_t balance_history[5];
    TRANSACTION *transactions[32];
    uint16_t transaction_count;
    uint8_t beneficial_owner_discovered;
    uint32_t flags;
} ACCOUNT;

Handler signatures: on_car(), on_cdr(), on_quote(), on_eval(), on_info()
All handlers are documented with behavior

TRANSACTION cell is fully defined:

typedef struct {
    uint32_t transaction_id;
    uint16_t date;
    uint32_t amount;
    uint16_t source_account_id;
    uint16_t dest_account_id;
    char description[48];
    uint8_t routing_type;
    uint8_t guilty_status;  // Hidden
    uint8_t visible_status;  // VISIBLE or REDACTED
    uint32_t audio_signature;  // Tone index
    uint8_t flags;
} TRANSACTION;

Handler signatures: on_car() (follow transaction to destination), on_cdr(), on_quote(), on_eq(), on_info()
All handlers specified with move costs

EVIDENCE_CHAIN cell is fully defined:

typedef struct {
    uint16_t chain_id;
    char narrative[256];
    uint16_t transaction_ids[20];
    uint16_t link_count;
    uint32_t total_amount;
    uint8_t chain_type;  // SEQUENTIAL_FLOW, LOOP, SPLIT, CONVERGE
    uint8_t narrative_match;  // Hidden
} EVIDENCE_CHAIN;

Handler signatures: on_cons() (add transaction), on_cdr(), on_eval() (submit chain)
Narrative matching is documented (80%+ = +300, <50% = -100)

CASE cell is fully defined:

typedef struct {
    uint16_t case_id;
    char case_name[64];
    uint8_t case_type;  // AUDIT, RECONSTRUCTION, FORENSIC_TRACE, SHELL_MAPPING
    uint8_t threat_level;
    uint16_t duration_seconds;
    uint16_t time_remaining;
    uint16_t car_budget, car_used;
    uint16_t quote_budget, quote_used;
    uint16_t eq_budget, eq_used;
    ACCOUNT *root_account;
    ACCOUNT *all_accounts[32];
    TRANSACTION *all_transactions[128];
    uint16_t guilty_transaction_count;  // Hidden
    EVIDENCE_CHAIN *evidence_chains[8];
    uint32_t final_score;
    int8_t reputation_gain;
} CASE;

Handler signatures: on_car(), on_eval(), on_back()
All handlers documented

Critical Omission:

CASE_BOARD cell is mentioned in section 8 (Onboarding) but NOT defined in section 11 (Cell Architecture). The mission board screen (Screen 1 in section 14) shows the contract/case selection list. This is navigated with CAR/CDR/EVAL, making it a cell type. But there is no typedef for CASE_BOARD, no field definitions, no handler signatures. Section 11 jumps directly from Design Philosophy to ACCOUNT without documenting CASE_BOARD.

This is a significant architectural oversight. The CASE_BOARD is the entry point to all cases. Its cell handlers must be specified:
- What fields does it contain? (Cursor position, case list, currently selected case)
- What does on_car() do? (Enter selected case → advance to CASE cell)
- What does on_cdr() do? (Move cursor to next case in list)
- What does on_info() do? (Show case details / threat level / rewards)
- What does on_eval() do? (Accept case → initialize CASE cell)
Without CASE_BOARD definition, the phase chain flow from boot → case selection → case execution is incomplete.

Minor Issue:

Section 11 is titled “CELL ARCHITECTURE” but contains only the typedef definitions and handler signatures. It does not explain the navigation graph (how cells are linked together) or the phase chain structure. ICE Breaker’s section 11 equivalent is sparse too, so this is acceptable, but a simple diagram of the cell hierarchy (CASE_BOARD → CASE → ACCOUNT → TRANSACTION) would clarify the architecture.

Score: 4/5 — Core cells are well-defined. CASE_BOARD is a critical omission. Cell navigation flow could be clearer.

6. SOUND DESIGN — 4/5

Criterion: Are PSG channels assigned? Does Voice 2 carry transaction audio signatures (suspicious entries sound different)? Can an experienced operator hear fraud?

Status: STRONG, but Voice 1 integration could be deeper.

Strengths:

Voice 1: Investigation Theme — Minor-key chord progression (C minor → G minor → F minor, 60 BPM baseline). Accelerates to 120 BPM in final minutes. Dissonance increases as time pressure rises. Resolves to major key on success, unresolved minor fade on failure. This is well-designed and conveys emotional texture.
Voice 2: Transaction Tone Signatures — Each transaction type has a distinct pitch:
- C4: Legitimate operational (calm, normal)
- D4: Unusual but possibly legitimate (neutral, questioning)
- E4: Suspicious (alert)
- F#4: Highly suspicious (alarm, dissonant)
As operator scrolls through transactions (CDR), each plays a 200ms tone. “An operator who listens learns: C, C, C, D, E, E, F#, C… = there are suspicious transactions clustered in positions 4-6.” This is auditory pattern matching and is a learned skill.

This is brilliant design. It makes sound mechanical, not cosmetic.
Voice 3: Feedback and Verdict Tones — Distinct tones for each action:
- QUOTE: Bell tone (G5, 100ms)
- CONS: Harmonic stack (C4-E4-G4, stacked 50ms, 300ms total)
- EQ match: Major third (C4-E4)
- EQ mismatch: Diminished (C4-Eb4, dissonant)
- Case complete (success): Major arpeggio (1 second, satisfying)
- Case complete (failure): Unresolved minor (300ms, unsatisfying)
- Verdict swell: C minor → G minor → F → C minor (2 seconds, dramatic)
Advanced play: Auditory scanning. Expert operators can work screen-off, relying on Voice 2 to identify suspicious transactions and Voice 1 to gauge time pressure. This is documented as an accessibility feature that becomes an advanced technique (section 5, “Advanced Play: Auditory Scanning”).

Weaknesses:

Voice 1 lacks precision in expressing move budget depletion. ICE Breaker’s Voice 1 has distinct attack signatures for JUNK/BLACK/RED/HUNTER classes. Black Ledger’s Voice 1 is primarily time-pressure responsive. There is no audio signature for “you are running out of CAR moves” or “you have used 80% of your QUOTE budget.” The Cipher voice provides text feedback (“CAR moves exhausted. Switch to pattern recognition.”), but there is no corresponding audio cue. An operator playing by ear would not hear the move budget pressure.

Suggestion: Assign Voice 1 sub-frequencies (e.g., subtle harmonic drone that rises in pitch as CAR moves deplete) to telegraph move budget status in parallel with time pressure.
Voice 3 verdict tones are documented but not integrated into the case resolution narrative. ICE Breaker’s verdict tones are embedded in the debrief screen. Black Ledger’s section 5 documents them but section 14 (Screen Layouts) does not show a “VERDICT SCREEN” where the verdict tones play. Section 7 (Session Shape) describes the verdict calculation but not the audio/visual experience of receiving it. The verdict should be a dramatic moment—music + text + score calculation. This gap is filled by section 16 (Implementation Notes), which shows calculate_verdict(), but the sensory experience is underspecified.

Score: 4/5 — Voice 2 transaction signatures are brilliant. Voice 1 and Voice 3 lack depth compared to ICE Breaker’s threat escalation signatures. Move budget audio is missing.

7. SCREEN LAYOUT PRECISION — 4/5

Criterion: Are ASCII wireframes provided for all 7 screens? Is the dual-pane split layout (account tree left, transaction detail right) fully specified? Do wireframes fit 80×25?

Status: MOSTLY COMPLETE, with minor gaps.

Provided wireframes (section 14):

✓ Screen 1: Mission Board / Case Selection (80x25 compliant, full detail)
✓ Screen 2: Case Briefing (80x25 compliant, full detail)
✓ Screen 3: Account Tree (Hierarchical View) (80x25 compliant, dual-pane implied but not explicit)
✓ Screen 4: Transaction Detail (80x25 compliant, single-pane view)
✓ Screen 5: Comparison View (implied in section 3, “EQ: Compare Two Transactions” with visual example, but NOT in section 14 wireframes)
✓ Screen 6: Money Flow Diagram (mentioned in section 3, “View 3: Money Flow Diagram (Sankey)” and section 14 lists it as available, but wireframe is NOT provided)
✓ Screen 7: Verdict Screen (mentioned in section 7, “Verdict:” example, but wireframe is NOT in section 14)

Dual-pane layout analysis:

Section 2 says: “LEFT PANE (Account Tree): Hierarchical view of accounts… RIGHT PANE (Transaction Detail): List of transactions for the selected account… Pane Switching: CDR at account-level switches focus to transaction pane.”

This is specified conceptually, but Screen 3 shows a single-pane view (Account Tree on top, transactions below). The spec claims split-pane layout but the wireframe shows sequential tab layout.

80×25 compliance:

Screens 1-4 fit within 80 columns × 25 rows.
However, Screen 3 (Account Tree) shows a large tree structure with indentation and accounts listed. On an actual 80×25 screen, only 3-4 account levels would be visible. The wireframe doesn’t show vertical scrolling indicators or row limits.

Wireframe gaps:

Screen 5 (Comparison View): Section 3 shows the comparison output:

TRANSACTION COMPARISON
═════════════════════════════════════════════════════════════
Transaction 1: TXN-01 (Nexus Inflow $1.5M on 02-05)
Transaction 2: TXN-03 (Nexus Outflow $2.0M on 03-10)
MATCH ANALYSIS:
  Amount Match: NO ($1.5M ≠ $2.0M)
  Date Proximity: YES (33 days apart - consistent with holding period)
  Counterparty Link: POSSIBLE (both involve shells)
  Part of Same Scheme: LIKELY (inflow from parent, followed by outflow to offshore)

This should be a formal wireframe in section 14, with header, action bar, and status line.

Screen 6 (Money Flow Diagram): Not wireframed. The spec mentions “directed edges with amounts” and “Sankey diagram” but no ASCII rendering is provided. This is a critical view (mentioned as one of three main views). It should have a wireframe.
Screen 7 (Verdict Screen): Section 7 shows the verdict calculation and example scores, but no actual wireframe. The verdict should be a formal screen with header, score breakdown (section 14 suggests using stdlib_draw_score_breakdown()), and action bar.

Minor issue:

The UI design system document (now archived at _archive/ui-design/KN-86-UI-Design-System-and-SDK-Extensions.md, section 1.3 “CDR for List Scrolling / Pane Toggle”) specifies: “At pane level: CDR toggles between panes (split-pane layouts).” But Black Ledger’s section 2 says pane switching is via “CDR at account-level” without clarifying whether this is true split-pane (two views visible simultaneously) or sequential tab views (one view at a time). The wireframes suggest sequential tabs, not split-pane.

Score: 4/5 — Four complete wireframes provided. Three critical screens are missing wireframes (Comparison, Money Flow, Verdict). Pane layout is conceptually specified but wireframes don’t clearly show split-pane vs. tab layout.

8. CROSS-MODULE INTEGRATION — 5/5

Criterion: Does the spec define how Black Ledger receives data from ICE Breaker in Corporate Espionage campaigns? Phase handlers? Cipher vocabulary? Deck state bits?

Status: EXCELLENT.

Strengths:

Corporate Espionage campaign is fully specified (section 15):
- Phase 1 (ICE BREAKER, 20 minutes): Operator infiltrates network, extracts financial data via MIRROR/GHOST tools
- Transition: Automatic Phase 2 trigger if BLACK LEDGER is in cartridge history and operator extracted financial data
- Phase 2 (BLACK LEDGER, 40 minutes): Extracted data auto-loads as a BLACK LEDGER case. Operator audits the damage trail and covers tracks.
- Scoring: Phase 1 payout (high extraction) increases Phase 2 case difficulty. Phase 2 accuracy bonus applies back to Phase 1 final payout.
- Combined payout: 3000-5000 ¤ (if both succeed)
- Combined reputation: +5
Phase chain state preservation is documented (section 16):
```
typedef struct {
    uint16_t car_budget;
    uint16_t car_used;
    uint16_t quote_budget;
    uint16_t quote_used;
    uint16_t eq_budget;
    uint16_t eq_used;
} MoveBudget;
```
This shows move budget serialization for phase chain continuity. (The Capability Model Spec defines phase_chain as a 256-byte buffer in DeckState for multi-phase state persistence.)
Proficiency cross-transfer is documented:
- NEONGRID Proficiency 60+ → BLACK LEDGER +25% navigation speed (spatial pattern recognition transfers to financial patterns)
- BLACK LEDGER Logic_Index 60+ → ICE BREAKER +15% payout on SABOTAGE contracts (financial deduction transfers to network sabotage planning)
Cipher voice integration:
- Same Cipher persona across all campaigns
- Briefing style evolves: verbose at low rep, terse at high rep
- At Logic_Index 70+, Cipher provides “investigator tips” in case briefings (e.g., “Shell companies have low transaction variance. Listen for that pattern.”)
Deck state integration:
- cartridge_history bitfield: Module 0x03 (BLACK LEDGER) sets bit when loaded
- credit_balance: Universal currency, earned in any module, spent in any module
- reputation: Domain-agnostic, accrues from all modules
- phase_chain: Multi-phase campaign state preserved across swaps

Minor notes:

The spec does not explicitly document which cartridge_history bit is assigned to BLACK LEDGER (0x03 is mentioned in the Design Philosophy but not in the integration section). This is acceptable because the Capability Model Spec likely owns that mapping.
The spec does not document the Cipher vocabulary for BLACK LEDGER (e.g., “Bureau 9” is mentioned in Design Philosophy, but the complete Cipher domain is not listed). However, section 8 (Onboarding) includes example Cipher voice lines (“You are an auditor reviewing an account…”), and section 7 (Session Shape) shows Cipher context (“Bureau 9 summarizes the case”). This is sufficient.

Score: 5/5 — Cross-module integration is thoughtfully designed and leverages the capability model architecture. Phase chain preservation, proficiency transfer, and Cipher voice evolution are all documented. Integration feels organic and rewarding.

9. ONBOARDING CLARITY — 4/5

Criterion: Can a first-time operator learn forensic accounting on the Deckline in 5 minutes? Is the learning sequence explicit?

Status: GOOD, but the learning sequence is implicit rather than explicit.

Strengths:

Section 8 (Onboarding: The First Five Minutes) is concrete and specific:
- Mission board appears with available cases
- Operator selects CASE 2 (Simple Reconstruction)
- Case briefing is shown with objective, threat level, move budget, corporate structure, payout estimate
- Operator presses CAR to begin investigation
- First puzzle: Account balances don’t match transaction history. Infer deleted transactions.
- Cipher voice: “Use CONS to hypothesize a deleted transaction.”
- Walkthrough shows numpad entry (3 0 0 0 0 0, then +, then destination account number)
- Judge evaluates hypothesis
Training cases are available (section 8): “Audit 101”, “Reconstruction 101”, “Money Trail Tracing” — repeatable, no rep gain.
Logic_Index progression is defined:
- Introduced in Onboarding section as a learned proficiency metric
- LAMBDA/APPLY (macros) unlocked at Logic_Index 40+
- Advanced Cipher hints unlocked at Logic_Index 70+
No explicit tutorial text. Black Ledger teaches through play, mirroring ICE Breaker’s philosophy.

Weakness:

The learning sequence is implicit, not explicit. The spec shows the first case (Reconstruction 101) but does not explicitly list the progression. What is CASE 3, 4, 5? What skills are introduced at each stage?

Comparison to ICE Breaker: ICE Breaker section 9 does not explicitly list the learning sequence either. But section 12 (Appendix A: “The Run”) provides a complete walkthrough of a Threat 2 contract, showing the operator’s decision-making and skill development over time.

Black Ledger provides the Threat 3 case walkthrough (section 7), which is good, but the early-game progression (Threat 1 cases → Threat 2 → Threat 3) is not detailed. A first-time operator reads section 8 and learns: “I can flag transactions and see if the judge agrees.” But they don’t immediately understand:
- When do deleted transactions become a mechanic? (Case 2, Reconstruction)
- When do macros unlock? (Logic_Index 40+, Case 3+)
- When does shell detection become important? (Case 3, Shell Detection 101)
- When does voice-based pattern recognition become viable? (After ~20 completed cases, per section 5)
Accessibility for first-time operators is not explicitly addressed. ICE Breaker section 9 explicitly states “There is no tutorial” and then walks through a typical operator’s first minutes, showing how they discover CAR/CDR/CONS organically. Black Ledger could benefit from a similar clarity statement and walkthrough.

Minor note:

Section 8 does not show the Mission Board screen that the operator would see first. It jumps straight to case selection. But section 14 (Screen 1) provides the Mission Board wireframe, so this is acceptable (it’s just organization).

Score: 4/5 — Onboarding is concrete and case-driven. The learning sequence is implicit. A beginner can play through the first case successfully, but the broader skill progression is not explicitly mapped.

10. TARGET AUDIENCE FIT — 5/5

Criterion: Does this feel like a forensic investigation tool, not a spreadsheet game? Is the noir aesthetic present? Would an adult hobbyist find the deduction compelling?

Status: EXCELLENT.

Strengths:

Forensic investigation frame is ironclad. The operator is an auditor working for “Bureau 9 Technical Services” (a mysterious government forensics division). Cases are framed as corporate crimes, embezzlement schemes, money laundering, bribery. The objective is always to uncover hidden money flows and name beneficiaries. This is fundamentally investigative, not accountancy simulation.
Noir aesthetic is present:
- “Bureau 9 Intelligence Brief” framing (section 8, section 14)
- Shell companies, tax havens, offshore accounts, front companies
- Corruption, embezzlement, bribery as narrative themes
- Operator handle as identity (from DeckState)
- “Shadow Holdings Embezzlement” and similar case names
- Cipher voice as a mysterious mentor / narrator
- Amber-on-black display (hardware aesthetic carries noir mood)
The game is genuinely deductive. There are no hints, no hand-holding. Cases are presented as raw corporate data. The operator must extract meaning through investigation. False flags are penalized. Missed guilty transactions are penalized. The operator must learn to recognize financial conspiracy patterns through repeated play.

Example: A $5M transfer from subsidiary A to shell company B looks like money laundering. But when traced further, it’s revealed to be a legitimate subsidiary restructuring (legal, ethically questionable). Operator learns: appearance ≠ reality. This is intellectual work, not button mashing.
Move-limited investigation creates genuine tension. Unlike turn-based puzzles (which can be optimized offline), Black Ledger’s move budgets force in-the-moment decision-making: Do I drill into this account now, or wait? Do I use my EQ comparisons on these two transactions, or save them for later? This pressure mirrors the time pressure of professional forensic work (you have limited time to investigate before statute of limitations, before suspects flee, etc.).
Proficiency metrics (Logic_Index) encourage mastery. Like ICE Breaker’s operator reputation, Black Ledger’s Logic_Index tracks learned expertise. Operators improve by playing, recognizing patterns, understanding shell company structures, trusting audio cues over visual inspection. This appeals to adult hobbyists who enjoy skill-based progression.
Asymmetric linked play (section 10) adds social depth: one operator conducts the audit while another (Analyst) digs into specific accounts or runs macros. This is competitive intelligence work, not a game mechanic novelty.
Session shape creates narrative arc (section 7). A 45-minute case is not grinding; it’s an investigation with buildup (discovery phase), confidence (theory formation), and resolution (verification and verdict). Operators emerge feeling like they solved something.
Comparison to spreadsheet games: The spec explicitly avoids simulation tedium. There is no “optimize your tax structure” or “balance quarterly reports.” There is no currency exchange or portfolio management. The only numbers that matter are transaction amounts and move budgets. Everything else is qualitative: pattern recognition, inference, deduction.

Specific evidence for hobbyist appeal:

The Red Herring Collision (section 6): “Operator spots a $5M transfer from subsidiary A to shell company B. It looks like money laundering. Operator flags it. Later, operator traces the money further: shell company B is a legitimate subsidiary restructuring.” This is a narrative moment, not a mechanical failure. Adult players enjoy this kind of learning.
The Deletion Collision (section 6): “Operator is reconstructing deleted transactions. They infer: there was a $50K transfer on 02-15. But when they trace the ledger: External Vendor Account received $50K on 02-16 (not 02-15). Operator’s reconstruction is wrong.” This is a puzzle, requiring careful reasoning.
The Shell Network Conspiracy Collision (section 6): “Operator has mapped 8 shell companies. They’ve traced money from A → B → C → D → E → F → G → H → Final Account. They believe they understand the conspiracy pattern. But then they notice: Company D has two parent accounts (both B and C send money to it). The graph is not linear; it is branching.” This teaches systems thinking, not just pattern matching.

Score: 5/5 — This is a compelling forensic investigation experience that would appeal to adult hobbyists interested in deduction, financial crime, and skill-based progression. The noir aesthetic is present but not overwrought. The mechanics serve the fiction, not the other way around.

TOP 3 STRENGTHS

Move-Limited Investigation as Core Pressure (Systems: 5/5, OODA: 4/5) — Unlike tempo-driven real-time pressure (ICE Breaker), Black Ledger’s move budgets create decision tension through resource depletion. CAR budget forces prioritization. QUOTE budget rewards precision over recall. EQ budget incentivizes pattern recognition. The three-budget system creates a rich decision space where strategic operators outperform explorers.
Voice 2 Transaction Tone Signatures as Mechanical Sound (Sound Design: 4/5) — Each transaction type has a distinct pitch (C4 = legitimate, D4 = unusual, E4 = suspicious, F#4 = highly suspicious). As the operator scrolls through transactions, each plays a 200ms tone. This makes sound mechanical information, not cosmetic. An expert operator can auditorily scan a 30-transaction list in 90 seconds without reading. This is brilliant design.
Emergent Collisions That Teach Systems Thinking (System Interaction: 5/5) — Four documented collisions (Red Herring, Deletion, Shell Network, Time Pressure) teach the operator to think like an investigator: appearance ≠ reality, precision matters, graphs branch, time is a constraint. These are not hand-crafted narratives; they emerge from the rule set interacting with player behavior.

TOP 5 SPECIFIC IMPROVEMENTS (WITH SECTION REFERENCES)

1. BLOCKING ISSUE: Document CASE_BOARD Cell Architecture (Section 11)

Problem: The mission board screen (Screen 1, section 14) is navigable (CAR to select, CDR to scroll, EVAL to accept). But CASE_BOARD cell is not defined in section 11 (Cell Architecture). Phase chain flow from boot → mission board → case is incomplete.

Solution: Add to section 11:

### CASE_BOARD Cell (Contract Selection Root)

typedef struct {
    uint8_t cursor_index;        // Currently selected case
    uint8_t case_count;
    CASE *available_cases[16];
    uint16_t case_ids[16];       // Case IDs for reference
} CASE_BOARD;

/* Phase handlers */
on_car(CASE_BOARD *this) {
    // Enter selected case: advance phase to selected CASE cell
    drill_into(available_cases[cursor_index]);
}

on_cdr(CASE_BOARD *this, int direction) {
    // Move cursor to next/previous case
    cursor_index = (cursor_index + direction) % case_count;
    stdlib_sfx_navigate();
}

on_info(CASE_BOARD *this) {
    // Show selected case details (threat level, payout, duration)
    display_case_details(available_cases[cursor_index]);
}

on_eval(CASE_BOARD *this) {
    // Accept case and begin investigation
    on_car(this);  // Navigate to selected case
}

Impact: Closes the architectural gap between boot sequence and case execution. Makes phase chain flow explicit.

2. Add Wireframes for Comparison View and Money Flow Diagram (Section 14)

Problem: Sections 3 and 8 mention three investigation views: Transaction List, Account Tree, and Money Flow Diagram. Sections 3 and 14 show an example EQ comparison output, but no formal wireframes are provided for Comparison or Money Flow screens.

Solution: Add two wireframes to section 14:

Screen 5: EQ Comparison View

╔════════════════════════════════════════════════════════════════════════════════╗
║ BLACK LEDGER // COMPARISON ANALYSIS                    TIME: 28:15 / 45:00   ║
╠════════════════════════════════════════════════════════════════════════════════╣
║                                                                                ║
║  TRANSACTION 1                          │  TRANSACTION 2                      ║
║  ─────────────────────────────────────────────────────────────────────────   ║
║  ID: TXN-2088-01-20-001                 │  ID: TXN-2088-03-10-001             ║
║  Date: 2088-01-20                       │  Date: 2088-03-10                   ║
║  Amount: $1,500,000                     │  Amount: $2,000,000                 ║
║  From: Zenith Industries                │  From: Nexus Holdings               ║
║  To: Nexus Holdings                     │  To: Caribbean Trust                ║
║  Description: "Q1 Transfer"             │  Description: "Quarterly Transfer"  ║
║                                                                                ║
║  MATCH ANALYSIS:                                                               ║
║  ─────────────────────────────────────────────────────────────────────────   ║
║  Amount Match ........... NO ($1.5M ≠ $2.0M)                                 ║
║  Date Proximity ......... YES (50 days apart, consistent with holding)        ║
║  Counterparty Link ...... YES (both involve shells)                           ║
║  Direction ............. COMPLEMENTARY (inflow → outflow)                    ║
║  Part of Conspiracy ..... LIKELY (sequential money laundering)                ║
║                                                                                ║
║  VERDICT: These transactions are likely part of the same money laundering     ║
║  scheme. Transaction 1 receives bribes from Zenith Industries into Nexus     ║
║  Holdings. Transaction 2 moves the money onward to Caribbean Trust.          ║
║                                                                                ║
║  [CDR: Cycle next pair] [QUOTE: Flag both] [CONS: Add to evidence chain]   ║
║  [BACK: Return] [SYS: Menu]                                                  ║
║                                                                                ║
╚════════════════════════════════════════════════════════════════════════════════╝

Screen 6: Money Flow Diagram (Sankey)

╔════════════════════════════════════════════════════════════════════════════════╗
║ BLACK LEDGER // MONEY FLOW DIAGRAM                     TIME: 28:15 / 45:00   ║
╠════════════════════════════════════════════════════════════════════════════════╣
║                                                                                ║
║  CASH FLOW TOPOLOGY (Sankey Diagram)                                          ║
║  ─────────────────────────────────────────────────────────────────────────   ║
║                                                                                ║
║  ZENITH INDUSTRIES (Holding)                                                  ║
║       ▐════════════════════════════════════════════════════════════════════▌  ║
║       │  $2.3M (bribes)    │ $500K (normal ops)  │ $1.2M (dividends)  │     ║
║       │                    │                     │                    │     ║
║       ▼                    ▼                     ▼                    ▼     ║
║    NEXUS HOLDINGS      PACIFIC DIV.      VENERUS CONSULTING       [BENIGN]   ║
║    (Shell)             (Legitimate)       (Front Co.)                        ║
║       │ $2.0M           │                    │                              ║
║       ├─→ CARIBBEAN ────┘                    │                              ║
║       │   TRUST (Cayman)                     └─→ [External Accounts]        ║
║       │      │ $1.95M (5% fee)                                              ║
║       │      ▼                                                               ║
║       │   CAYMAN FINANCE (Offshore)                                         ║
║       │      │ $1.85M (5% fee)                                              ║
║       │      ▼                                                               ║
║       │   HANDLER LLC (Front)                                               ║
║       │      │ $1.8M (final)                                                ║
║       │      ▼                                                               ║
║       └─→ PERSONAL ACCOUNT [BENEFICIARY - UNKNOWN]                          ║
║                                                                                ║
║  LEGEND: Thick lines = suspicious. Thin lines = legitimate. Dashed = suspected. ║
║  TOTALS: $2.3M enters system, $1.8M exits to unknown beneficiary (22% loss).    ║
║                                                                                ║
║  [CAR: Drill node] [CDR: View stats] [INFO: Transaction list] [SYS: Menu]   ║
║                                                                                ║
╚════════════════════════════════════════════════════════════════════════════════╝

Impact: Provides complete screen inventory. Validates the three-view system (Transaction List, Account Tree, Money Flow). Clarifies how Money Flow diagram communicates complex money flow patterns at a glance.

3. Specify Voice 1 Harmonic for Move Budget Pressure (Section 5)

Problem: Voice 1 conveys time pressure but not move budget pressure. An expert operator should hear when they are running low on CAR, QUOTE, or EQ moves, not just read Cipher text (“CAR moves exhausted”).

Solution: Expand section 5, add subsection “Voice 1: Multi-Dimensional Pressure Signaling”:

Voice 1 simultaneously encodes two pressures: time and move budget.

BASE LAYER (Time Pressure): Minor-key chord progression (C min → G min → F min)
cycles at BPM = 60 + (10 × threat_level). As time_remaining decreases to <10 min,
BPM accelerates to 120+. Dissonance increases (adding diminished chords).

HARMONIC LAYER (Move Budget Pressure): A subtle drone frequency (sub-bass,
80-120 Hz) rises in pitch as move budgets deplete:

- CAR budget 90-100% available: drone at 80 Hz (imperceptible)
- CAR budget 70-90% available: drone at 100 Hz (barely audible)
- CAR budget 40-70% available: drone at 120 Hz (noticeable)
- CAR budget 0-40% available: drone at 160 Hz (prominent, causes tension)

QUOTE and EQ budget pressure are encoded in Voice 3 envelope (attack + decay
time of feedback tones become sharper as budgets deplete).

Example: Experienced operator at minute 30 of a 45-minute case, with 5 CAR moves
remaining (out of 30 original):
- Voice 1 plays at 60 BPM (time is not yet critical)
- Voice 1 drone is at 140 Hz (CAR budget is tight)
- Voice 3 feedback tones have sharp attacks (QUOTE and EQ budgets are also low)

Operator hears: "I need to work efficiently. I'm running out of investigation tools."

Impact: Makes the move budget system auditorily transparent. Enables expert operators to play by ear with full information. Adds mechanical depth to the audio design.

Problem: Section 2 claims “dual-pane split layout (account tree left, transaction detail right)” but wireframes show sequential screens (Account Tree on Screen 3, Transaction Detail on Screen 4). The pane-switching mechanic is vague: “CDR at account-level switches focus to transaction pane.”

Solution: Clarify in section 2:

BLACK LEDGER uses a SEQUENTIAL TAB VIEW (not true split-pane) to fit the 80×25 display:

- At CASE cell: Operator presses INFO to cycle between three views:
  - View 1: Account Tree (full hierarchy, CAR to select account)
  - View 2: Transaction List (flat list of transactions for selected account, CAR to detail)
  - View 3: Money Flow Diagram (Sankey view of all flows)

- At ACCOUNT cell: Operator presses CDR to scroll siblings, INFO to cycle views
- At TRANSACTION cell: Operator presses CDR to scroll list, CAR to follow to destination

FUTURE ENHANCEMENT (if display is expanded to 80×48 or split-screen device):
True split-pane layout (Account Tree on left, Transaction List on right) with independent
CDR navigation in each pane. For now, sequential views are more readable at 80×25 resolution.

Impact: Removes ambiguity about screen layout. Clarifies that the three-view system is the primary navigation mechanism, not true pane splitting.

5. Specify ATOM Handler Behavior and Move Cost (Section 11 and 12)

Problem: ATOM (Test if Leaf) is mapped in section 12 but not defined in section 11. Its use case is unclear (“Determine if account has child accounts”) and no handler signature is provided.

Solution: Add to section 11 (Cell Architecture), ACCOUNT cell:

on_atom(ACCOUNT *this) {
    // Determine if account is a leaf (no child accounts)
    bool is_leaf = (this->child_count == 0);

    if (is_leaf) {
        // Account has no children (it is an operating account or personal account)
        // This often indicates: beneficial owner, cash endpoint, or front company
        stdlib_sfx_select();  // Bright confirmation tone
        cipher_voice("This account has no outflows to shell companies. Dead end.");
    } else {
        // Account has children (it routes money through the hierarchy)
        // This indicates: shell, holding company, or intermediary
        stdlib_sfx_alert();   // Warning tone
        cipher_voice("This account routes money to subsidiaries. Follow the tree.");
    }
    // No move cost. No action, just information.
}

And clarify in section 12:

| ATOM | Middle Row (1) | **Test if Leaf** - Determine if account has child accounts or is a terminal (beneficial owner). Useful for shell detection: shells always route money onward. Terminal accounts often indicate owners. | Free |

Impact: Clarifies ATOM’s strategic role in shell detection. Makes the handler explicit for implementers. Prevents confusion.

BLOCKING ISSUES

Critical Issue: CASE_BOARD Cell Architecture Missing

This is the only genuine blocking issue. The mission board is the entry point to all cases. Its cell definition is required for phase chain flow clarity.

Resolution: Add CASE_BOARD typedef and handlers to section 11 (see Improvement #1 above).

VERDICT: PASS

Overall Score: 44 / 50

Black Ledger is an exemplary capability module specification that deserves production green-light. It respects the KN-86 platform architecture, delivers a compelling forensic investigation experience, and integrates seamlessly with ICE Breaker via the Corporate Espionage campaign.

The five improvements are refinements, not fundamental flaws. CASE_BOARD is a documentation gap, not a design gap. The missing wireframes (Comparison, Money Flow, Verdict) do not prevent implementation—the mechanics are well-specified elsewhere—but they improve clarity and visual reference for module authors.

Recommended path forward:

Mandatory: Add CASE_BOARD cell definition to section 11.
Highly recommended: Add three missing wireframes (Comparison, Money Flow, Verdict) to section 14.
Recommended: Specify Voice 1 move-budget harmonic in section 5.
Nice to have: Clarify split-pane vs. tab navigation in section 2.
Nice to have: Complete ATOM handler in section 11.

All other aspects of the spec are production-ready.

CLOSING REMARKS

Black Ledger transforms financial crime into a deduction engine. The move-limited investigation loop is a distinct contribution to the KN-86 platform—it is not a copy of ICE Breaker’s OODA loop, but a sibling system with its own learning curve and mastery path. The voice-2 transaction signatures make sound mechanical, not cosmetic. The four emergent collisions teach investigative thinking. The noir aesthetic and Bureau 9 framing create coherence with the platform’s cyberpunk identity.

This is a game for players who enjoy reasoning, pattern recognition, and risk management. It is a worthy launch title alongside ICE Breaker.

BLACK LEDGER GAMEPLAY SPECIFICATION — ROUND 1 DESIGN EVALUATION

OVERALL SCORE: 44 / 50

SCORING BREAKDOWN

1. STRUCTURAL COMPLETENESS — 5/5

2. OODA / CORE LOOP DEPTH — 4/5

3. SYSTEM INTERACTION — 5/5

4. KEY MAPPING RIGOR — 4/5

5. CELL ARCHITECTURE — 4/5

6. SOUND DESIGN — 4/5

7. SCREEN LAYOUT PRECISION — 4/5

8. CROSS-MODULE INTEGRATION — 5/5

9. ONBOARDING CLARITY — 4/5

10. TARGET AUDIENCE FIT — 5/5

TOP 3 STRENGTHS

TOP 5 SPECIFIC IMPROVEMENTS (WITH SECTION REFERENCES)

1. BLOCKING ISSUE: Document CASE_BOARD Cell Architecture (Section 11)

2. Add Wireframes for Comparison View and Money Flow Diagram (Section 14)

3. Specify Voice 1 Harmonic for Move Budget Pressure (Section 5)

4. Clarify Split-Pane vs. Tab Navigation (Section 2 and 14)

5. Specify ATOM Handler Behavior and Move Cost (Section 11 and 12)

BLOCKING ISSUES

Critical Issue: CASE_BOARD Cell Architecture Missing

VERDICT: PASS

CLOSING REMARKS