KN-86 Deckline — Lisp Paradigm Revisions

Deep Structural Redesigns for 12 Capability Modules

Date: April 11, 2026
Revision Scope: Non-GREEN modules (all except ICE BREAKER, NEONGRID) redesigned for genuine Lisp list-processing semantics
Design Principle: Every module’s data is a nested recursive list that CAR/CDR/CONS operations naturally navigate and transform.

CIPHER-LINE revision note (2026-04-24): The “Cipher voice” quotations interspersed through the example walkthroughs render on the CIPHER-LINE OLED, not the main 80×25 grid. Read them as beat intent; actual rendering is clipped fragments per the voice heuristic. Canonical engine spec: docs/software/runtime/cipher-voice.md.

REVISION 1: DEPTHCHARGE — Maritime Reconnaissance

1.1 Data Model as Nested List

DEPTHCHARGE’s core data is a submersible navigation tree: the ocean environment is a nested list of depth layers, each containing compartments, cargo, and environmental hazards.

(OCEAN_ENVIRONMENT
  (DEPTH_0 "Surface"
    (POSITION_ORIGIN)
    (CARGO_HOLD))
  (DEPTH_200 "Upper Thermocline"
    (WRECK_A
      (CARGO "Sensors" 50kg)
      (INTEGRITY 85))
    (WILDLIFE (whale_vocalization)))
  (DEPTH_350 "Target Depth"
    (WRECK_B "Research Submersible"
      (COMPARTMENT_1
        (CARGO (TYPE BIOTECH) (MASS 150))
        (HAZARDS (RADIATION HIGH)))
      (COMPARTMENT_2
        (CARGO (TYPE DATA) (MASS 30))
        (HAZARDS NONE)))
    (THERMAL_VENT))
  (DEPTH_500
    (WRECK_C)
    (PREDATORS (TYPE SHARK) (COUNT 2))))

Key Insight: The ocean is a list of depth layers. Each depth contains a list of objects. Each object contains properties and nested lists of cargo, hazards, and sub-compartments. The operator navigates by drilling into these lists with CAR and moving across siblings with CDR.

1.2 Key Operation Table: Lisp Operations in DEPTHCHARGE

Operation	Meaning	Implementation	Why It’s Genuine
CAR	Drill into current depth layer; enter first element	Select primary sonar contact (wreck/relay/predator) at current depth	Descending into a list’s HEAD; that element is now your focus
CDR	Move to next depth layer OR next sibling at same depth	Navigate to adjacent wreck; move between compartments in extraction	Traversing the REST of the list; siblings are CDR-accessible
CONS	Combine cargo from two compartments into extraction plan	Build a new “cargo selection” from COMPARTMENT_1 ∪ COMPARTMENT_2	Constructing a new pair: two cargo lists become one combined list
NIL	The empty ocean; no wreck, no cargo, nothing	Returning to depth 0 (surface); the null state	Reaching the end of a list; nothing remains to process
EVAL	Execute the extraction plan; commit to it	Trigger cargo winch; lock wreck entry sequence	Evaluating an expression: the plan (quoted data) becomes action
QUOTE	Bookmark a wreck without extracting yet; hold as data	BACK key: defer commitment to extraction; return to sonar view	Quoting: holding the wreck as data, not evaluated/extracted
LAMBDA	Record a multi-turn extraction sequence as reusable procedure	”Efficient extraction pattern: enter compartment 1, grab cargo, ascend, dock at surface”	Defining a function: sequence of operations stored for APPLY
APPLY	Execute a recorded extraction pattern against a new wreck	Deploy your recorded “quick-grab” pattern on a new wreck	Applying a stored function to a new target data structure
ATOM	Test if a sonar contact is indivisible (leaf node) or a container	A coral formation (ATOM) vs. a wreck with compartments (composite list)	Checking if an element is atomic or composite; can I drill deeper?
EQ	Test if two wrecks are the same (identity check)	Have I found the same wreck twice?	Comparing element identity in the list structure

1.3 Worked Example: 5-Turn Extraction Sequence

Setup: Operator at depth 350m. Sonar shows WRECK_B (research submersible) with two compartments. Goal: extract maximum cargo while managing pressure.

TURN 1 — OBSERVE AND ORIENT
  Operator hears: sonar ping, low whale vocalization (ambiguous position).
  Operator presses INFO (double-tap): sonar scan triggers.
  Screen shows: WRECK_B at 350m with two compartments visible.

  Current list position: (OCEAN_ENVIRONMENT ... (DEPTH_350 (WRECK_B ...)))
  OPERATOR ACTION: CAR (drill into WRECK_B)

TURN 2 — ENTER WRECK
  WRECK_B now active. List position: (WRECK_B (COMPARTMENT_1 ...) (COMPARTMENT_2 ...))
  Screen shows: Two compartments. COMPARTMENT_1 has BIOTECH cargo (150kg).
               COMPARTMENT_2 has DATA cargo (30kg).
  OPERATOR ACTION: CAR (drill into COMPARTMENT_1)

TURN 3 — EXAMINE COMPARTMENT 1
  Position: (COMPARTMENT_1 (CARGO (TYPE BIOTECH) (MASS 150)) (HAZARDS (RADIATION HIGH)))
  Screen shows: BIOTECH cargo. Radiation hazard. Extraction difficulty: MODERATE.
  Pressure building. Acoustic signature increasing (+2/turn).
  OPERATOR ACTION: CONS (combine COMPARTMENT_1 cargo with extraction plan)
                         This constructs: (EXTRACTION_PLAN (CARGO_1 BIOTECH))

TURN 4 — MOVE TO NEXT COMPARTMENT
  OPERATOR ACTION: CDR (move to next sibling — COMPARTMENT_2)
  Position now: (WRECK_B ... (COMPARTMENT_2 ...))
  Screen shows: COMPARTMENT_2 with DATA cargo. No hazards. Extraction easy.
  OPERATOR ACTION: CONS (combine COMPARTMENT_2 cargo with plan)
                         EXTRACTION_PLAN now: (CARGO_1 BIOTECH) (CARGO_2 DATA))

TURN 5 — FINALIZE AND ASCEND
  Plan is fully constructed: (EXTRACTION_PLAN (CARGO_1 BIOTECH) (CARGO_2 DATA))
  OPERATOR ACTION: EVAL (execute extraction plan)
                         Cargo winch activates. Both compartments harvested simultaneously.
                         Acoustic signature: +8. Pressure critical.
  OPERATOR ACTION: CDR then NIL (exit wreck, return to ocean list)
                         Navigate to DEPTH_200 for ascent.

Key Insight: The operator never selected a “menu” or pressed “extract all cargo.” They used CAR to drill, CDR to move, CONS to build the extraction plan, and EVAL to execute. The plan itself is data (a list) that accumulates as they navigate.

1.4 Cell Architecture (C Pseudocode)

/* ========== WRECK COMPARTMENT CELL ========== */

CELL_DEFINE(CompartmentCell) {
    CellBase base;
    uint16_t cargo_mass;
    uint8_t cargo_type;      // BIOTECH, DATA, PRECIOUS_METAL, etc.
    uint8_t hazard_level;    // NONE, LOW, MEDIUM, HIGH

    CellList* cargo_items;   // List of individual cargo items in this compartment
    Cell* next_compartment;  // CDR: pointer to next compartment

    ON_CAR {
        /* Drill into this compartment's cargo detail */
        if (cargo_items && cargo_items->head) {
            drill_into(cargo_items->head);  // Enter first cargo item
        }
    }

    ON_CDR {
        /* Move to next compartment in sequence */
        if (next_compartment) {
            navigate_to(next_compartment);
        } else {
            /* No more compartments; return to wreck root (NIL relative to compartments) */
            pop_navigation_stack();
        }
    }

    ON_CONS {
        /* Combine this compartment's cargo with the extraction plan */
        extraction_plan_t *plan = get_current_extraction_plan();
        plan_add_compartment(plan, self);
        voice_play(ARPEGGIO_UP);  /* Confirmation: cargo added to plan */
    }

    ON_EVAL {
        /* Extract cargo from this compartment */
        extraction_phase_begin(self);
        pressure_increase(2);  /* Extraction is noisy */
    }

    ON_QUOTE {
        /* Bookmark this compartment without extracting */
        bookmark_list_node(self);
        voice_play(SUSTAINED_TONE);  /* Deferred tone */
    }
};

/* ========== WRECK CELL ========== */

CELL_DEFINE(WreckCell) {
    CellBase base;
    uint16_t depth;
    uint8_t integrity;

    CellList* compartments;  // List of CompartmentCells
    Cell* next_wreck;        // CDR: pointer to next wreck at different depth

    ON_CAR {
        /* Drill into first compartment */
        if (compartments && compartments->head) {
            drill_into(compartments->head);
        }
    }

    ON_CDR {
        /* Move to next wreck */
        if (next_wreck) {
            navigate_to(next_wreck);
        } else {
            pop_navigation_stack();  /* Return to depth layer */
        }
    }

    ON_CONS {
        /* Combine wrecks: merge their cargo lists */
        WreckCell *other = get_selected_wreck();
        CellList *merged = list_concat(self->compartments, other->compartments);
        extraction_plan_add_merged_cargo(merged);
    }

    ON_EVAL {
        /* Start extraction sequence from this wreck */
        extraction_phase_begin_wreck(self);
    }

    ON_LAMBDA {
        /* Record extraction sequence for this wreck */
        record_extraction_pattern(self);
    }

    ON_APPLY {
        /* Apply recorded pattern to this wreck */
        extraction_pattern_t *pattern = get_recorded_pattern();
        apply_pattern_to_wreck(self, pattern);
    }

    ON_ATOM {
        /* Test: is this wreck a simple container or a complex compartment structure? */
        return (compartments->length > 1) ? COMPOSITE : ATOM;
    }
};

/* ========== DEPTH LAYER CELL ========== */

CELL_DEFINE(DepthLayerCell) {
    CellBase base;
    uint16_t depth;
    const char* name;        // "Upper Thermocline", "Crush Depth", etc.

    CellList* objects;       // List of wrecks, thermal vents, predators, etc.
    Cell* next_depth;        // CDR: pointer to next depth layer

    ON_CAR {
        /* Drill into first object at this depth */
        if (objects && objects->head) {
            drill_into(objects->head);
        }
    }

    ON_CDR {
        /* Move to next depth layer */
        if (next_depth) {
            navigate_to_depth(next_depth);
        } else {
            /* Reached surface (NIL state) */
            return_to_surface();
        }
    }

    ON_CONS {
        /* Combine multiple objects at this depth into a single mission */
        CellList *focused_objects = list_filter(objects, EXTRACTION_TARGETS);
        create_multi_target_mission(focused_objects);
    }
};

REVISION 2: SHELLFIRE — Electronic Warfare / RF Triangulation

2.1 Data Model as Nested List

SHELLFIRE’s data is a spectrum tree: the RF environment is a nested hierarchy of frequency bands, each containing encryption layers, countermeasures, and payload chunks.

(SPECTRUM_ENVIRONMENT
  (PRIMARY_BAND_806MHz
    (SIGNAL_STRENGTH 78dB)
    (ENCRYPTION
      (LAYER1_128bit (KEY_STATE "unknown"))
      (LAYER2_256bit (KEY_STATE "unknown")))
    (COUNTERMEASURES
      (PROFILE_A (COST 1) (DURATION 3) (EFFECTIVENESS 60%))
      (PROFILE_B (COST 1) (DURATION 3) (EFFECTIVENESS 85%)))
    (PAYLOAD
      (CHUNK_1 "financial_records" 40%)
      (CHUNK_2 "transaction_logs" 30%)
      (CHUNK_3 "transaction_logs_extended" 30%)))
  (SECONDARY_BAND_850MHz
    (SIGNAL_STRENGTH 45dB)
    (ENCRYPTION (LAYER1_SIMPLE))
    (COUNTERMEASURES ...)
    (PAYLOAD (...)))
  (PATROL_BAND_918MHz
    (SIGNAL_STRENGTH 62dB)
    (ENCRYPTION NONE)
    (COUNTERMEASURES (NONE))
    (PAYLOAD (STATUS_BEACON))))

Key Insight: The spectrum is a list of bands. Each band is a list of properties (signal, encryption, countermeasures, payload). Each property is itself a list. The operator navigates by drilling into bands with CAR, moving between bands with CDR, and combining countermeasure strategies with CONS.

2.2 Key Operation Table: Lisp Operations in SHELLFIRE

Operation	Meaning	Implementation	Why It’s Genuine
CAR	Enter a frequency band; examine encryption layers	CAR on SPECTRUM → PRIMARY_BAND. CAR on PRIMARY_BAND → first ENCRYPTION layer	Descending into nested list structure; HEAD is now active
CDR	Move to next frequency band OR next encryption layer	CDR on bands list → SECONDARY_BAND. CDR on encryption list → next layer	Traversing REST of list; all siblings are CDR-accessible
CONS	Combine encryption techniques to create new bypass method	LAYER1 ∪ LAYER2 → COMBINED_BYPASS (new list of techniques)	Constructing new pair from two list elements
NIL	No signal; empty spectrum; abort extraction	All bands silent; nothing to target	Empty list; the null state of the frequency environment
EVAL	Execute countermeasure strategy; deploy against spectrum	Activate PROFILE_A against PRIMARY_BAND’s counter-jamming	Evaluating a plan (data) into action
QUOTE	Defer extraction; bookmark band without acting	BACK key: hold current band state as data, no extraction yet	Quoting: data without evaluation
LAMBDA	Record multi-band extraction sequence (band-hop, suppress-jam, extract pattern)	“Primary 3 turns → secondary 2 turns → profile B → primary finish”	Storing a function: sequence of operations
APPLY	Execute recorded extraction sequence against new target band	Deploy “proven 3-2-B-finish” pattern on newly-detected band	Applying stored function to new data
ATOM	Test if band is indivisible (single encryption) or composite (layered)	PATROL_BAND (ATOM: simple encryption) vs. PRIMARY_BAND (composite: multi-layer)	Checking element type; can I decompose further?
EQ	Test if two bands are identical (same frequency, same signal)	Are both targets the same band, or different?	Element identity; essential for avoiding duplicate work

2.3 Worked Example: Real-Time Frequency Management

Setup: Operator is extracting from PRIMARY_BAND_806MHz. Counter-jamming is active. Operator has 3 countermeasure profiles loaded. Goal: maximize extraction before jamming overwhelms signal.

TURN 1 (OBSERVE)
  Operator hears: Voice 1 at 650Hz (rising), Voice 2 rhythmic (extraction), Voice 3 dissonance (jamming).
  Operator presses INFO: Cipher voice gives snapshot.

  Current position in spectrum tree: (PRIMARY_BAND_806MHz ...)
  Signal: 78dB, Counter-jam: ACTIVE, Extraction: 40%

TURN 2 (ORIENT & DECIDE)
  Voice 3 dissonance is increasing. Counter-jamming pulse approaching.
  Operator must decide: continue extraction (risky), apply countermeasure (cost signal), or switch bands (reset extraction).

  Current data: (PRIMARY_BAND_806MHz (ENCRYPTION (LAYER1 ...) (LAYER2 ...)) (COUNTERMEASURES (PROFILE_A ...) (PROFILE_B ...) (PROFILE_C ...)))

TURN 3 (ACT)
  OPERATOR ACTION: CAR (drill into COUNTERMEASURES list)
  OPERATOR ACTION: CAR (drill into PROFILE_B — the strongest countermeasure)

  Current position: (PROFILE_B (COST 1) (DURATION 3) (EFFECTIVENESS 85%))

TURN 4 (ACT)
  OPERATOR ACTION: EVAL (deploy PROFILE_B against counter-jamming)
  Result: Counter-jamming suppressed for 3 turns. Signal drops 6dB (penalty).
  Voice 3 goes silent. Voice 1 drops to 620Hz (recovers slowly).
  Extraction accelerates: 42% → 44%.

TURNS 5-6 (CONTINUATION)
  Counter-jamming is suppressed. Extraction continues smoothly.
  OPERATOR ACTION: EVAL (continue extraction)

TURN 7 (CRISIS)
  PROFILE_B countermeasure expires. Voice 3 dissonance returns (loud).
  Voice 1 rising toward 750Hz (danger zone).

  Operator has two choices:
    A) Use PROFILE_C (last countermeasure)
    B) Switch bands via CDR

  OPERATOR ACTION: CDR (move to SECONDARY_BAND)
  Current position: (SECONDARY_BAND_850MHz ...)

  Screen shows: SECONDARY_BAND has lower signal (45dB) but less jamming.
  Extraction resets to 0% on new band.
  Encryption simpler: only LAYER1.

TURN 8 (NEW BAND)
  Operator is now on SECONDARY_BAND with clean encryption (single layer).
  OPERATOR ACTION: CAR (drill into LAYER1 encryption)
  OPERATOR ACTION: CONS (combine SECONDARY_BAND's single layer with PROFILE_C countermeasure to create new bypass)

  New list constructed: (SECONDARY_EXTRACTION_PLAN (LAYER1_SINGLE) (PROFILE_C_APPLIED))

TURN 9 (EXECUTE)
  OPERATOR ACTION: EVAL (execute extraction on SECONDARY_BAND with PROFILE_C)
  Extraction begins. Signal: 45dB (weaker, but cleaner). No counter-jamming on this band.
  Extraction accelerates fast: 0% → 5% → 10%.

TURNS 10-15 (CONTINUATION)
  Operator rides extraction wave. Voice 2 accelerates. Voice 3 remains quiet.
  OPERATOR ACTION: EVAL (continue extraction) × 6 turns
  Result: Secondary band extraction reaches 85%.

TURN 16 (FINAL DECISION)
  Operator has extracted 85% from SECONDARY_BAND.
  PRIMARY_BAND is now less defended (PROFILE_B expired; counter-jamming may have reset).

  OPERATOR ACTION: CDR (return to PRIMARY_BAND)
  OPERATOR ACTION: LAMBDA (record the "2-band extraction sequence": primary 3 turns → secondary 6 turns → finish on secondary)

  This LAMBDA is now stored as a reusable function.

EXTRACTION COMPLETE
  Total extraction: 85% SECONDARY + 40% PRIMARY (earlier) = strong session.
  Payout: 1500¤ (base) × 0.85 (extraction ratio) = 1275¤
  Operator can now APPLY the recorded LAMBDA against future targets.

Key Insight: The operator never opened a “frequency menu.” They used CAR to drill into bands and encryption, CDR to switch between bands, CONS to build extraction strategies, EVAL to execute, and LAMBDA to record the entire sequence for replay.

2.4 Cell Architecture (C Pseudocode)

/* ========== FREQUENCY BAND CELL ========== */

CELL_DEFINE(FrequencyBandCell) {
    CellBase base;
    uint16_t frequency_mhz;
    uint8_t signal_strength;
    uint8_t counter_jam_intensity;

    CellList* encryption_layers;    /* List of encryption techniques */
    CellList* countermeasures;      /* List of available countermeasure profiles */
    CellList* payload_chunks;       /* List of data chunks to extract */
    Cell* next_band;                /* CDR: next frequency band */

    ON_CAR {
        /* Drill into encryption layers (first element) */
        if (encryption_layers && encryption_layers->head) {
            drill_into(encryption_layers->head);
        }
    }

    ON_CDR {
        /* Move to next frequency band */
        if (next_band) {
            navigate_to(next_band);
            reset_extraction_state();  /* New band = new extraction context */
        } else {
            /* No more bands; return to spectrum root (NIL) */
            spectrum_abort();
        }
    }

    ON_CONS {
        /* Combine encryption layers with countermeasures to create bypass strategy */
        EncryptionLayer *layer1 = list_get(encryption_layers, 0);
        EncryptionLayer *layer2 = list_get(encryption_layers, 1);
        bypass_strategy_t *bypass = cons_encryption_bypass(layer1, layer2);
        extraction_strategy_add_bypass(bypass);
    }

    ON_EVAL {
        /* Execute extraction on this band */
        if (extraction_strategy_is_ready()) {
            extraction_begin(self);
            acoustic_signature_increase(2);
        }
    }

    ON_LAMBDA {
        /* Record multi-band extraction sequence */
        record_band_sequence(self);  /* Will store CDR transitions and EVAL calls */
    }

    ON_APPLY {
        /* Apply recorded sequence to new target band */
        band_sequence_t *seq = get_recorded_sequence();
        apply_sequence_to_band(self, seq);
    }

    ON_ATOM {
        /* Test: simple band (atomic) or complex (multi-layer encryption) */
        return (encryption_layers->length > 1) ? COMPOSITE : ATOM;
    }
};

/* ========== ENCRYPTION LAYER CELL ========== */

CELL_DEFINE(EncryptionLayerCell) {
    CellBase base;
    uint8_t layer_id;       /* Layer 1, Layer 2, ... */
    uint16_t key_size;      /* 128, 256, ... bits */
    uint8_t crack_difficulty;  /* 0-100 (higher = harder) */

    Cell* next_layer;       /* CDR: next encryption layer in sequence */

    ON_CAR {
        /* Drilling into a layer typically shows key state; no sub-layers */
        display_layer_detail(self);
    }

    ON_CDR {
        /* Move to next encryption layer */
        if (next_layer) {
            navigate_to(next_layer);
        } else {
            pop_navigation_stack();  /* Reached end of encryption stack */
        }
    }

    ON_CONS {
        /* Combine two layers to create combined bypass (multi-layer attack) */
        EncryptionLayerCell *layer2 = get_focused_layer();
        bypass_t *combined = cons_layers_for_bypass(self, layer2);
        return combined;
    }

    ON_EVAL {
        /* Apply cryptographic attack to this layer */
        if (bypass_strategy_matches_layer(self)) {
            crack_layer(self);
        }
    }
};

REVISION 3: TAKEZO — Tactical Analysis (Go-Inspired Strategy)

3.1 Data Model as Nested List

TAKEZO’s data is a game tree: each board position is a nested list of tactical options (moves, joseki patterns, capture sequences).

(GAME_STATE
  (BOARD_19x19
    (GROUP_A
      (STONES (3,4) (3,5) (4,4))
      (LIBERTIES 8)
      (THREAT_LEVEL LOW)
      (CAPTURE_SEQUENCE
        (MOVE_1 (5,4) "atari")
        (MOVE_2 (5,5) "capture_group"))))
    (GROUP_B
      (STONES (10,10) (10,11) (11,10))
      (LIBERTIES 2)
      (THREAT_LEVEL CRITICAL)
      (DEFENSE_OPTIONS
        (OPTION_A (9,10) "defend_left")
        (OPTION_B (11,11) "defend_corner"))))
  (PATTERN_LIBRARY
    (JOSEKI_PATTERNS
      (CORNER_3_3
        (MOVE_1 (3,3))
        (MOVE_2 (3,5))
        (MOVE_3 (5,3)))
      (LADDER_SEQUENCE
        (MOVE_1 (5,5))
        (MOVE_2 (6,5))
        (MOVE_3 (6,6)))))
  (TACTICAL_REPERTOIRE
    (RECORDED_SEQUENCES
      (CAPTURE_PATTERN_1
        (SETUP (board_state))
        (MOVES ((5,4) (5,5) (6,5))))
      (DEFENSE_PATTERN_1
        (SETUP (board_state))
        (MOVES ((9,10) (10,10)))))))

Key Insight: The game tree is a nested list of board groups, patterns, and recorded sequences. The operator navigates by drilling into groups with CAR, moving between groups with CDR, composing new tactical sequences with CONS, and executing patterns with EVAL.

3.2 Key Operation Table: Lisp Operations in TAKEZO

Operation	Meaning	Implementation	Why It’s Genuine
CAR	Drill into a board group; examine its stones and liberties	CAR on BOARD → first GROUP (top-left cluster). CAR on GROUP → first STONE in group	Descending into list HEAD
CDR	Move to next board group OR next stone in sequence	CDR on groups → next GROUP. CDR on stones → next STONE	Traversing REST of list
CONS	Compose two tactical ideas into new combined sequence	CAPTURE_PATTERN (atari) ∪ DEFENSE_PATTERN (block) → COMBINED_SEQUENCE	Constructing new pair from two lists
NIL	Empty board; no tactical considerations; game start	Blank Go board; no groups to analyze	Empty list state
EVAL	Execute a composed move sequence; place stones	Execute CAPTURED_PATTERN: play move sequence, observe result	Evaluating a plan (quoted sequence) into action
QUOTE	Bookmark a tactical idea without executing	BACK key: hold a pattern in mind without playing	Quoting: data without evaluation
LAMBDA	Record a multi-move tactical sequence for reuse	”Ladder sequence: (5,5) (6,5) (6,6) (7,6)” → reusable function	Storing a tactic as a composable function
APPLY	Replay a recorded tactical sequence against a new board situation	Deploy “ladder capture” against opponent’s new group formation	Applying stored pattern to new game state
ATOM	Test if a board element is a single stone (atomic) or a group (composite)	Single STONE (atom) vs. GROUP of connected stones (composite list)	Element type checking; can I drill deeper?
EQ	Test if two groups are equivalent (same stones, same liberties)	Are two board regions identical?	Identity comparison for groups

3.3 Worked Example: 8-Turn Tactical Sequence

Setup: Go board with two critical groups. PLAYER controls GROUP_A (8 liberties, safe). OPPONENT controls GROUP_B (2 liberties, vulnerable). Goal: capitalize on opponent’s weakness.

TURN 1 (OBSERVE)
  Operator views board. Five distinct groups visible.
  PLAYER-controlled: GROUP_A (safe), GROUP_C (stable)
  OPPONENT-controlled: GROUP_B (critical, 2 liberties), GROUP_D (medium threat)

  Current position: (BOARD_19x19 (GROUP_A ...) (GROUP_B ...) (GROUP_C ...) (GROUP_D ...))

TURN 2 (ANALYZE & DECIDE)
  OPERATOR ACTION: CAR (drill into GROUP_B — the vulnerable group)
  OPERATOR ACTION: INFO (Cipher voice): "GROUP_B has 2 liberties. Atari (one-step-to-capture) is viable."

  Current position: (GROUP_B (STONES (10,10) (10,11) (11,10)) (LIBERTIES 2))

TURN 3 (COMPOSE PATTERN)
  Operator CAR's deeper into GROUP_B to see the exact stone configuration.
  OPERATOR ACTION: CAR (examine first STONE)
  OPERATOR ACTION: CDR (move to next STONE)

  Operator visualizes: GROUP_B is arranged in an L-shape. Two liberties are at (9,10) and (10,12).

  Operator recalls LAMBDA-stored patterns. "CORNER_LADDER_CAPTURE" is recorded for exactly this configuration.
  OPERATOR ACTION: APPLY (deploy CORNER_LADDER_CAPTURE against GROUP_B)

TURN 4 (EXECUTE CAPTURE SETUP)
  CORNER_LADDER_CAPTURE is a pre-recorded sequence:
    MOVE_1: (9,10) "force atari"
    MOVE_2: (10,12) "block second liberty"
    MOVE_3: (11,9) "extend trap"

  OPERATOR ACTION: EVAL (execute first move of applied sequence)
  PLAYER places stone at (9,10). This is atari: GROUP_B now has only 1 liberty (at 10,12).

  Screen shows: GROUP_B flashing red (CRITICAL threat).
  OPPONENT must respond immediately or lose the group.

TURN 5 (OPPONENT RESPONDS)
  OPPONENT plays (10,12) — blocking the remaining liberty. Temporarily saves GROUP_B.
  But GROUP_B is now surrounded (captured next turn unless opponent escapes or connects).

  New board state:
  (GROUP_B (STONES (10,10) (10,11) (11,10) (10,12) OPPONENT_DEFENDER))
           (LIBERTIES 0) (TRAPPED true))

TURN 6 (ADAPT)
  Operator observes: OPPONENT's move created a new tactical opening.
  OPPONENT's defending stone at (10,12) is now part of a larger structure vulnerable to counter-attack.

  OPERATOR ACTION: CAR (examine OPPONENT's defending stone position)
  OPERATOR ACTION: CONS (combine GROUP_A's strength + OPPONENT's weakness into new attacking sequence)

  OPERATOR constructs a LAMBDA: "COUNTER_CAPTURE_SEQUENCE"
    (MOVE_1 (9,11) "attack from below")
    (MOVE_2 (11,11) "scissors cut")
    (MOVE_3 (10,13) "expand territory")

TURN 7 (EXECUTE COUNTER)
  OPERATOR ACTION: EVAL (execute COUNTER_CAPTURE_SEQUENCE move 1)
  PLAYER places stone at (9,11). This threatens both GROUP_B and the newly-formed GROUP_E (created by OPPONENT's defending move).

  OPPONENT is now in a double-threat situation: save GROUP_B or defend GROUP_E. Cannot do both.
  Cipher voice: "Dual threat. Opponent's position is failing."

TURN 8 (FINALIZE)
  OPPONENT responds. Whichever group they defend, the other is captured.
  OPERATOR ACTION: CDR (move focus to next opponent group)
  OPERATOR ACTION: EVAL (execute final capturing sequence)

  PLAYER captures either GROUP_B or GROUP_E. Significant board advantage.

  Game state now:
  (BOARD_19x19
    (PLAYER_TERRITORY (expanded))
    (CAPTURED_GROUP (opponent stones removed)))

Key Insight: The operator never selected moves from a “move menu.” They CAR’d into groups, CDR’d to analyze sequential weaknesses, CONS’d tactical ideas together, and LAMBDA’d / APPLY’d proven patterns. The entire game is a navigation of nested tactical structures.

3.4 Cell Architecture (C Pseudocode)

/* ========== BOARD GROUP CELL ========== */

CELL_DEFINE(GoGroupCell) {
    CellBase base;
    uint8_t player_id;      /* Player A or Player B */
    CellList* stones;       /* List of stones in this group */
    uint8_t liberty_count;
    uint8_t threat_level;   /* SAFE, MEDIUM, CRITICAL */

    Cell* next_group;       /* CDR: next group on board */

    ON_CAR {
        /* Drill into first stone of group */
        if (stones && stones->head) {
            drill_into(stones->head);
        }
    }

    ON_CDR {
        /* Move to next group */
        if (next_group) {
            navigate_to(next_group);
        } else {
            pop_navigation_stack();
        }
    }

    ON_CONS {
        /* Combine two groups' tactical ideas into a composite sequence */
        GoGroupCell *group2 = get_focused_group();
        tactical_sequence_t *combined = cons_group_tactics(self, group2);
        return combined;
    }

    ON_EVAL {
        /* Execute a tactical move sequence against this group */
        tactical_sequence_t *sequence = get_composed_sequence();
        play_move_sequence(self, sequence);
    }

    ON_LAMBDA {
        /* Record this group's tactical patterns for reuse */
        record_group_patterns(self);  /* Store atari, ladder, etc. for this configuration */
    }

    ON_APPLY {
        /* Apply a recorded pattern to a new group with similar configuration */
        tactical_pattern_t *pattern = get_recorded_pattern();
        apply_pattern_to_group(self, pattern);
    }

    ON_ATOM {
        /* Test: single stone vs. connected group */
        return (stones->length > 1) ? COMPOSITE : ATOM;
    }
};

/* ========== STONE CELL ========== */

CELL_DEFINE(StoneCell) {
    CellBase base;
    uint8_t row, col;
    uint8_t player_id;
    uint8_t liberties_contributed;  /* How many liberties this stone provides to group */

    Cell* next_stone;               /* CDR: next stone in group */

    ON_CDR {
        /* Move to next stone in group */
        if (next_stone) {
            navigate_to(next_stone);
        } else {
            pop_navigation_stack();
        }
    }
};

/* ========== TACTICAL PATTERN CELL ========== */

CELL_DEFINE(TacticalPatternCell) {
    CellBase base;
    const char* pattern_name;     /* "CORNER_LADDER", "EDGE_CAPTURE", etc. */

    CellList* move_sequence;      /* List of moves in order */
    uint8_t pattern_type;         /* CAPTURE, DEFENSE, TERRITORY_EXPANSION */

    ON_CAR {
        /* Drill into first move of sequence */
        if (move_sequence && move_sequence->head) {
            drill_into(move_sequence->head);
        }
    }

    ON_CDR {
        /* Move to next move in sequence */
        if (move_sequence) {
            Cell *next = list_get_next(move_sequence, current_focus);
            if (next) navigate_to(next);
        }
    }
};

REVISION 4: DRIFT — Signal Tracking / RF Triangulation

4.1 Data Model as Nested List

DRIFT’s data is a signal source tree: the environment contains transmitters and dead drops, nested in space by distance, bearing, and signal strength.

(RF_ENVIRONMENT
  (TRANSMITTER_A
    (LOCATION (X 100) (Y 50) (BEARING 045))
    (SIGNAL_STRENGTH 78dB)
    (DISTANCE 150m)
    (ANTENNA_SIGNATURES
      (PRIMARY 806MHz)
      (SECONDARY 850MHz))
    (DEAD_DROP_ROUTES
      (ROUTE_1 (WAYPOINTS ((120,40) (140,60) (160,50))))
      (ROUTE_2 (WAYPOINTS ((100,70) (110,80) (120,90))))))
  (TRANSMITTER_B
    (LOCATION (X 200) (Y 120))
    (SIGNAL_STRENGTH 45dB)
    (DISTANCE 280m)
    (ANTENNA_SIGNATURES
      (PRIMARY 918MHz))
    (DEAD_DROP_ROUTES
      (ROUTE_1 (WAYPOINTS ...))))
  (ANTENNA_ARRAY
    (POSITIONS ((100,0) (100,10) (100,20)))
    (LOCK_STATUS "TRIANGULATING")
    (TRIANGULATION_CONFIDENCE 65%)))

Key Insight: Signal sources are a nested list organized by strength and position. The operator navigates by drilling into transmitters with CAR, moving between transmitters with CDR, and building triangulation arrays with CONS.

4.2 Key Operation Table: Lisp Operations in DRIFT

Operation	Meaning	Implementation	Why It’s Genuine
CAR	Drill into a transmitter’s signal properties and routes	CAR on RF_ENVIRONMENT → TRANSMITTER_A. CAR on TRANSMITTER → first ANTENNA signature	Descending into list HEAD
CDR	Move to next transmitter OR next dead drop route	CDR on transmitters → TRANSMITTER_B. CDR on routes → ROUTE_2	Traversing REST of list
CONS	Combine antenna readings from multiple positions into triangulation	ANTENNA_1_READING ∪ ANTENNA_2_READING → TRIANGULATION_POINT	Constructing new pair from readings
NIL	No signal; dead zone; no transmitter in range	Empty RF environment; nothing to track	Empty list state
EVAL	Execute triangulation; lock onto transmitter position	Deploy antenna array; calculate triangulation; confirm target location	Evaluating a composed triangulation plan
QUOTE	Bookmark a transmitter without locking on	Defer triangulation; hold signal signature as data only	Quoting: data without execution
LAMBDA	Record a multi-antenna triangulation sequence for reuse	”Position 3 antennas at (X,Y), wait 5 turns, take readings, triangulate” → stored function	Storing triangulation procedure
APPLY	Deploy recorded triangulation setup against a new transmitter	Use proven antenna configuration on newly-detected signal source	Applying stored procedure to new data
ATOM	Test if signal source is simple (single antenna) or complex (multi-antenna)	Single antenna (atom) vs. antenna array (composite list)	Element type checking
EQ	Test if two transmitters are the same (identity by frequency + bearing)	Are both signals from the same source?	Identity comparison

4.3 Worked Example: Triangulation Sequence

Setup: Operator has detected TWO transmitters (A at 806MHz, B at 918MHz). Goal: triangulate both positions using mobile antenna array.

TURN 1 (OBSERVE)
  Operator hears: Voice 1 at 650Hz (transmitter A), Voice 3 at 400Hz (transmitter B, weaker).
  Screen shows RF environment with two signal sources.

  Current position: (RF_ENVIRONMENT (TRANSMITTER_A ...) (TRANSMITTER_B ...))

TURN 2 (FOCUS ON FIRST TARGET)
  OPERATOR ACTION: CAR (drill into TRANSMITTER_A)

  Current position: (TRANSMITTER_A (LOCATION ...) (SIGNAL_STRENGTH 78dB) (ANTENNA_SIGNATURES ...))

  TRANSMITTER_A is strong, closer. Operator decides to triangulate this one first.

TURN 3 (BUILD ANTENNA ARRAY)
  Operator must CONS three antenna positions together to triangulate TRANSMITTER_A.

  OPERATOR ACTION: CONS (antenna position 1) + CONS (antenna position 2) + CONS (antenna position 3)

  This constructs: (ANTENNA_ARRAY (POSITIONS ((100,0) (100,10) (100,20))) (TARGET TRANSMITTER_A))

TURN 4 (DEPLOY ANTENNAS)
  OPERATOR ACTION: EVAL (deploy antenna array)

  Antenna array activates. Three physical antennas positioned in a line.
  Voice 1 locks onto 806MHz. Voice 2 shows phase difference between antennas.
  Triangulation begins: system records bearing and distance from each antenna.

TURNS 5-6 (GATHER READINGS)
  OPERATOR ACTION: EVAL (continue gathering triangulation data for 2 turns)

  Each antenna records signal phase. Software accumulates readings.
  Triangulation confidence rises: 30% → 45% → 60%

TURN 7 (TRIANGULATION SUCCESS)
  Triangulation confidence: 85%. TRANSMITTER_A position confirmed: (X 145, Y 58, distance 158m).

  OPERATOR ACTION: CDR (move focus to next transmitter)

  Current position: (RF_ENVIRONMENT ... (TRANSMITTER_B ...))

  Screen shows: TRANSMITTER_B is weaker (45dB), farther away.

TURN 8 (REPOSITION ANTENNAS)
  Operator CAR's into TRANSMITTER_B.
  OPERATOR ACTION: CONS (antenna position 1 at new location) + CONS (antenna position 2) + CONS (antenna position 3)

  New antenna array: (ANTENNA_ARRAY (POSITIONS ((200,0) (200,10) (200,20))) (TARGET TRANSMITTER_B))

TURN 9 (DEPLOY FOR SECOND TARGET)
  OPERATOR ACTION: EVAL (deploy repositioned antenna array for TRANSMITTER_B)

  New array locks onto 918MHz. Phase differences are subtle (farther target, weaker signal).
  Triangulation begins: 20% confidence.

TURNS 10-12 (LONGER OBSERVATION)
  TRANSMITTER_B requires longer observation due to weaker signal.
  OPERATOR ACTION: EVAL (continue gathering) × 3 turns

  Triangulation confidence: 20% → 40% → 65% → 82%

TURN 13 (BOTH TARGETS CONFIRMED)
  TRANSMITTER_A: (145, 58), 806MHz
  TRANSMITTER_B: (285, 125), 918MHz

  Both positions triangulated. Operator can now plan dead drop recovery routes.
  OPERATOR ACTION: LAMBDA (record antenna positioning sequence for later reuse)

  LAMBDA stores: "Deploy 3 antennas in line, wait 5 turns, gather readings, extract position"

TURN 14 (EXTRACT & EXIT)
  Operator has gathered intel. Operator could now navigate to dead drop locations (hot swap to PATHFINDER).
  Payout: 1500¤ (triangulation success) + 200¤ (speed bonus) = 1700¤

Key Insight: The operator never “placed antennas manually.” They CONS’d antenna readings into an array, EVAL’d the triangulation, and LAMBDA’d the process for future use.

4.4 Cell Architecture (C Pseudocode)

/* ========== TRANSMITTER CELL ========== */

CELL_DEFINE(TransmitterCell) {
    CellBase base;
    uint16_t frequency;
    uint8_t signal_strength;
    int16_t bearing;        /* Degrees: 0-359 */
    uint16_t distance;      /* Meters: 0-1000+ */

    CellList* antenna_signatures;   /* List of detected antenna types */
    CellList* dead_drop_routes;     /* List of known dead drop delivery routes */
    Cell* next_transmitter;         /* CDR: next transmitter in environment */

    ON_CAR {
        /* Drill into antenna signatures */
        if (antenna_signatures && antenna_signatures->head) {
            drill_into(antenna_signatures->head);
        }
    }

    ON_CDR {
        /* Move to next transmitter */
        if (next_transmitter) {
            navigate_to(next_transmitter);
        } else {
            pop_navigation_stack();
        }
    }

    ON_CONS {
        /* Combine antenna reading from this transmitter with antenna readings from others */
        antenna_reading_t *reading = capture_antenna_reading(self);
        triangulation_data_t *tri = get_triangulation_state();
        tri->readings = cons_append(tri->readings, reading);
        return tri;
    }

    ON_EVAL {
        /* Execute triangulation against this transmitter */
        triangulation_data_t *tri = get_triangulation_state();
        if (tri->reading_count >= 3) {
            tri->position = triangulate_from_readings(tri->readings);
            tri->confidence += 15;
        }
    }

    ON_LAMBDA {
        /* Record the triangulation procedure for this transmitter */
        record_triangulation_sequence(self);
    }

    ON_APPLY {
        /* Apply recorded triangulation sequence to new transmitter */
        triangulation_sequence_t *seq = get_recorded_sequence();
        apply_sequence_to_transmitter(self, seq);
    }
};

/* ========== ANTENNA ARRAY CELL ========== */

CELL_DEFINE(AntennaArrayCell) {
    CellBase base;
    CellList* antenna_positions;    /* List of (X,Y,Z) positions */
    uint8_t target_transmitter_id;
    uint8_t triangulation_confidence;

    ON_CAR {
        /* Drill into first antenna position */
        if (antenna_positions && antenna_positions->head) {
            drill_into(antenna_positions->head);
        }
    }

    ON_CDR {
        /* Move to next antenna position */
        if (antenna_positions) {
            Cell *next = list_get_next(antenna_positions, current_focus);
            if (next) navigate_to(next);
        }
    }

    ON_CONS {
        /* Add new antenna position to array */
        antenna_position_t *new_pos = get_new_antenna_position();
        antenna_positions = list_append(antenna_positions, (CellBase *)new_pos);
    }
};

REVISION 5: PATHFINDER — Route Planning (Logistics & Supply Chain)

5.1 Data Model as Nested List

PATHFINDER’s data is a journey tree: routes are nested lists of legs, each containing waypoints, hazards, and constraints.

(JOURNEY
  (LEG_1 "Hong Kong to Singapore Strait"
    (START "Hong Kong Port" (COORD 22.3, 114.2))
    (WAYPOINTS
      (WP_1 "South China Sea" (HAZARDS (PIRATES HIGH) (SURVEILLANCE MEDIUM)))
      (WP_2 "Vietnamese Waters" (HAZARDS (PATROL_BOATS LOW)))
      (WP_3 "Singapore Strait" (HAZARDS (SURVEILLANCE HIGH))))
    (END "Singapore Port" (COORD 1.35, 103.8))
    (DURATION 12h)
    (CONSTRAINTS ((AVOID_SHIPPING_LANES) (SILENT_RUNNING_REQUIRED))))
  (LEG_2 "Singapore to Ho Chi Minh"
    (START "Singapore Port")
    (WAYPOINTS
      (WP_1 "Gulf of Thailand" (HAZARDS (FISHING_ZONES)))
      (WP_2 "Cambodian Waters" (HAZARDS NONE)))
    (END "Ho Chi Minh Port")
    (DURATION 8h)
    (CONSTRAINTS ((DAYTIME_TRAVEL_SAFE))))
  (LEG_3 "Ho Chi Minh to Bangkok"
    (START "Ho Chi Minh Port")
    (WAYPOINTS
      (WP_1 "Thai Coastal" (HAZARDS (NAVY HIGH))))
    (END "Bangkok Port")
    (DURATION 4h)
    (CONSTRAINTS ((NIGHT_TRAVEL_REQUIRED)))))

Key Insight: The journey is a nested list of legs. Each leg contains a nested list of waypoints. The operator navigates by drilling into legs with CAR, moving between legs with CDR, and composing multi-leg journeys with CONS.

5.2 Key Operation Table: Lisp Operations in PATHFINDER

Operation	Meaning	Implementation	Why It’s Genuine
CAR	Drill into a leg’s waypoints; examine the first waypoint	CAR on JOURNEY → LEG_1. CAR on LEG → first WAYPOINT	Descending into list HEAD
CDR	Move to next leg OR next waypoint in sequence	CDR on legs → LEG_2. CDR on waypoints → WP_2	Traversing REST of list
CONS	Combine two routes into a longer multi-leg journey	LEG_1 (HK→Singapore) ∪ LEG_2 (Singapore→Ho Chi Minh) → COMBINED_JOURNEY	Constructing new journey from leg lists
NIL	No route; starting point equals destination	Empty journey; nowhere to go	Empty list state
EVAL	Execute the planned route; initiate travel	Commit to JOURNEY: begin LEG_1 at scheduled time	Evaluating route plan (data) into action
QUOTE	Bookmark a route without traveling	Hold route plan in mind without committing departure	Quoting: data without execution
LAMBDA	Record a multi-leg route sequence for reuse	”HK→Singapore→Ho Chi Minh→Bangkok” → stored route	Storing journey as reusable function
APPLY	Execute a recorded route again with new cargo/conditions	Deploy “proven HK-Singapore-HoChiMinh route” for new shipment	Applying stored route to new journey context
ATOM	Test if waypoint is atomic (simple location) or complex (constraint-heavy)	Single port (atom) vs. waypoint cluster with multiple constraints (composite)	Element type checking
EQ	Test if two waypoints are the same location (identity by coordinates)	Are both targets the same port?	Identity comparison

5.3 Worked Example: Multi-Leg Route Planning

Setup: Operator is planning a 3-leg supply run: Hong Kong → Singapore → Ho Chi Minh → Bangkok. Each leg has different hazards and constraints.

TURN 1 (OBSERVE & LOAD JOURNEY)
  Operator reviews mission: deliver cargo from Hong Kong to Bangkok in 48 hours.
  Route options visible on screen: DIRECT (fast, high risk), COASTAL (safe, slow), MULTI_PORT (flexible).

  OPERATOR ACTION: CAR (drill into JOURNEY structure)

  Current position: (JOURNEY (LEG_1 ...) (LEG_2 ...) (LEG_3 ...))

TURN 2 (ANALYZE FIRST LEG)
  OPERATOR ACTION: CAR (examine LEG_1 in detail)

  Current position: (LEG_1 "HK to Singapore Strait" (START ...) (WAYPOINTS (WP_1 ...) (WP_2 ...) (WP_3 ...)))

  Screen shows: LEG_1 duration 12 hours. Three waypoints.
  Hazards: Pirates (HIGH) early, Surveillance (HIGH) late.
  Constraints: Shipping lanes must be avoided. Silent running required.

  OPERATOR ACTION: CAR (examine first waypoint)

  Current position: (WP_1 "South China Sea" (HAZARDS (PIRATES HIGH) (SURVEILLANCE MEDIUM)))

  Operator notes: Pirates are an early threat. Surveillance increases as we approach Singapore.

TURN 3 (ASSESS HAZARD PROGRESSION)
  Operator uses CDR to move through waypoints and understand hazard escalation.
  OPERATOR ACTION: CDR (move to WP_2)
  OPERATOR ACTION: CDR (move to WP_3)

  Operator now understands the hazard curve: PIRATES → SURVEILLANCE → HARBORMASTERS

  This informs the route timing: leave Hong Kong at night (avoid pirate observation), arrive Singapore at dawn (minimize surveillance detection).

TURN 4 (MOVE TO SECOND LEG)
  OPERATOR ACTION: CDR (exit waypoints; move to next LEG)

  Current position: (JOURNEY ... (LEG_2 "Singapore to Ho Chi Minh" ...))

  LEG_2 is shorter (8h), but passes through fishing zones.
  Constraints: Daytime travel is safe (fishing boats are less aggressive during daylight).

TURN 5 (MOVE TO THIRD LEG)
  OPERATOR ACTION: CDR (move to LEG_3)

  Current position: (LEG_3 "Ho Chi Minh to Bangkok" ...)

  LEG_3 is the shortest (4h), but crosses Thai Navy waters.
  Constraint: Night travel required (avoid daytime navy patrols).

TURN 6 (IDENTIFY CONSTRAINT CONFLICT)
  Operator notes: LEG_2 requires DAYTIME travel. LEG_3 requires NIGHT travel.
  This means there's a mandatory rest period in Ho Chi Minh (change of travel conditions).

  Operator presses INFO: Cipher voice confirms: "Rest required in Ho Chi Minh: 4 hours minimum. Cargo must be secured during daylight. Resume night travel to Bangkok."

TURN 7 (COMPOSE OPTIMIZED ROUTE)
  Operator CONS's the three legs together with timing constraints.
  OPERATOR ACTION: CONS (LEG_1 with start-at-night constraint) + CONS (LEG_2 with daytime constraint) + CONS (LEG_3 with night constraint)

  This creates: (OPTIMIZED_JOURNEY
                  (LEG_1_TIMED (START "23:00 HK time"))
                  (LEG_2_TIMED (START "07:00 Singapore time"))
                  (LEG_3_TIMED (START "20:00 HoChiMinh time")))

  Total duration: 12h + 8h + 4h + 4h rest = 28 hours (within 48h target).

TURN 8 (FINALIZE & RECORD)
  Operator has fully planned the route. Timing is optimized. Hazard management is clear.
  OPERATOR ACTION: LAMBDA (record this route as "HK-SG-HCM-Bangkok Supply Run v1")

  Route is now stored as a reusable LAMBDA function.
  OPERATOR ACTION: EVAL (commit to route; begin LEG_1)

  Cargo loading begins. Departure scheduled for 23:00 HK time.

  Payout: 2000¤ (base) + 300¤ (on-time completion bonus) + 200¤ (constraint adherence) = 2500¤

  If operator returns to this route later (APPLY), they can replay it with minimal decision-making.

Key Insight: The operator built the route by navigating nested leg/waypoint structures with CAR/CDR, composed optimized timing with CONS, and stored the entire sequence with LAMBDA for future reuse.

5.4 Cell Architecture (C Pseudocode)

/* ========== LEG CELL ========== */

CELL_DEFINE(LegCell) {
    CellBase base;
    uint16_t start_port_id;
    uint16_t end_port_id;
    uint16_t duration_hours;

    CellList* waypoints;        /* List of waypoints in this leg */
    CellList* constraints;      /* List of timing/hazard constraints */
    Cell* next_leg;             /* CDR: next leg in journey */

    ON_CAR {
        /* Drill into first waypoint of this leg */
        if (waypoints && waypoints->head) {
            drill_into(waypoints->head);
        }
    }

    ON_CDR {
        /* Move to next leg in journey */
        if (next_leg) {
            navigate_to(next_leg);
        } else {
            pop_navigation_stack();  /* End of journey */
        }
    }

    ON_CONS {
        /* Combine this leg with another leg to form a multi-leg journey */
        LegCell *leg2 = get_focused_leg();
        journey_t *combined = cons_legs_into_journey(self, leg2);
        return combined;
    }

    ON_EVAL {
        /* Execute this leg; begin travel from start_port to end_port */
        execution_context_t *ctx = get_execution_context();
        ctx->current_leg = self;
        ctx->current_waypoint_index = 0;
        leg_execution_begin(self);
    }

    ON_LAMBDA {
        /* Record this leg's travel pattern */
        record_leg_pattern(self);
    }

    ON_APPLY {
        /* Apply recorded leg pattern to new journey */
        leg_pattern_t *pattern = get_recorded_pattern();
        apply_pattern_to_leg(self, pattern);
    }
};

/* ========== WAYPOINT CELL ========== */

CELL_DEFINE(WaypointCell) {
    CellBase base;
    int32_t latitude, longitude;
    const char* region_name;

    CellList* hazards;          /* List of hazard types and intensities */
    CellList* constraints;      /* List of traversal constraints */
    uint16_t duration_to_next;  /* Estimated travel time to next waypoint */

    Cell* next_waypoint;        /* CDR: next waypoint in leg */

    ON_CDR {
        /* Move to next waypoint in leg sequence */
        if (next_waypoint) {
            navigate_to(next_waypoint);
        } else {
            pop_navigation_stack();
        }
    }

    ON_CAR {
        /* Drill into hazard details */
        if (hazards && hazards->head) {
            drill_into(hazards->head);
        }
    }
};

/* ========== JOURNEY CELL (Root) ========== */

CELL_DEFINE(JourneyCell) {
    CellBase base;
    CellList* legs;             /* List of legs */
    uint16_t total_duration;    /* Sum of all leg durations */
    uint8_t risk_level;         /* SAFE, MODERATE, HIGH, CRITICAL */

    ON_CAR {
        /* Drill into first leg */
        if (legs && legs->head) {
            drill_into(legs->head);
        }
    }

    ON_CDR {
        /* Move through legs */
        if (legs) {
            Cell *next = list_get_next(legs, current_focus);
            if (next) navigate_to(next);
        }
    }

    ON_CONS {
        /* Combine multiple journeys or append a new leg */
        JourneyCell *journey2 = get_other_journey();
        journey_t *merged = cons_journeys(self, journey2);
        return merged;
    }

    ON_EVAL {
        /* Execute the entire journey; begin first leg */
        journey_execution_begin(self);
    }

    ON_LAMBDA {
        /* Record entire journey pattern */
        record_journey_pattern(self);
    }
};

REVISION 6: NODESPACE — Network Strategy

6.1 Data Model as Nested List

NODOSPACE’s data is a strategic network tree: nodes organize into clusters, each with influence cost, ownership, and supply-line connections.

(NETWORK
  (CLUSTER_NORTH
    (NODE_1 (OWNER neutral) (INFLUENCE_COST 1) (SUPPLY_LINES ()))
    (NODE_2 (OWNER player) (INFLUENCE_COST 2) (SUPPLY_LINES (NODE_1)))
    (NODE_3 (OWNER opponent) (INFLUENCE_COST 3) (SUPPLY_LINES (NODE_2))))
  (CLUSTER_CENTER
    (BRIDGE_NODE (OWNER neutral) (INFLUENCE_COST 4) (SUPPLY_LINES (NODE_1 NODE_3))))
  (CLUSTER_SOUTH
    (NODE_4 (OWNER neutral) (INFLUENCE_COST 1))
    (NODE_5 (OWNER opponent) (INFLUENCE_COST 2))))

Key Insight: Nodes organize into clusters. Clusters form a larger network. The operator navigates by drilling into clusters with CAR, moving between clusters with CDR, and building supply lines (connecting nodes) with CONS.

6.2 Key Operation Table: Lisp Operations in NODESPACE

Operation	Meaning	Implementation	Why It’s Genuine
CAR	Drill into a cluster; examine first node	CAR on NETWORK → CLUSTER_NORTH. CAR on CLUSTER → first NODE	Descending into list HEAD
CDR	Move to next cluster OR next node in sequence	CDR on clusters → CLUSTER_CENTER. CDR on nodes → NODE_2	Traversing REST of list
CONS	Build supply line connecting two nodes; merge clusters	NODE_1 ∪ NODE_2 → SUPPLY_LINE (new structural pair)	Constructing new connection pair
NIL	No nodes; empty cluster; no territory claimed	Unowned region; nothing to strategize	Empty list state
EVAL	Execute a territory claim strategy; allocate influence	Commit influence points to take a cluster	Evaluating strategy plan into action
QUOTE	Bookmark a cluster strategy without executing	Hold a plan in mind without committing influence	Quoting: data without evaluation
LAMBDA	Record a multi-node capture sequence (e.g., “claim node 1, then node 2, then bridge”) → reusable strategy	Storing a tactical sequence	Storing a strategic pattern
APPLY	Execute recorded strategy against a new cluster	Deploy “proven encirclement strategy” on opponent’s new cluster	Applying stored strategy to new board state
ATOM	Test if node is simple (atomic) or complex (hub connecting multiple clusters)	Simple node (atom) vs. bridge node (composite, connects clusters)	Element type checking
EQ	Test if two nodes are equivalent (same owner, same influence, same position)	Identity comparison for strategic planning	Element identity check

6.3 Worked Example: 8-Turn Territory Control

Setup: NODESPACE Threat 2, ADAPTIVE opponent. 14-node board. Operator starts in CLUSTER_NORTH with 2 nodes. Opponent in CLUSTER_SOUTH with 2 nodes. Goal: claim majority (8+ nodes).

TURN 1 (OBSERVE)
  Operator views board. Three clusters visible. CLUSTER_NORTH, CLUSTER_CENTER, CLUSTER_SOUTH.
  CLUSTER_CENTER contains 2 bridge nodes (high influence cost, high strategic value).

  Current position: (NETWORK (CLUSTER_NORTH ...) (CLUSTER_CENTER ...) (CLUSTER_SOUTH ...))

TURN 2 (ANALYZE STARTING CLUSTER)
  OPERATOR ACTION: CAR (drill into CLUSTER_NORTH)

  Current position: (CLUSTER_NORTH (NODE_1 player) (NODE_2 player) (NODE_3 neutral) (NODE_4 neutral))

  Operator owns 2 nodes. 2 neutral nodes available for claiming.
  Influence points: 6. Cost to claim each neutral: 1 point each.

TURN 3 (CLAIM FIRST NEUTRAL)
  OPERATOR ACTION: CAR (examine NODE_3)
  OPERATOR ACTION: EVAL (claim NODE_3 with 1 influence point)

  NODE_3 now owned by player. Influence remaining: 5.
  Operator now controls 3 of 4 nodes in CLUSTER_NORTH.

TURN 4 (PREPARE ENCIRCLEMENT)
  OPERATOR ACTION: CAR (examine NODE_4)
  Operator realizes: if I claim NODE_4, I fully control CLUSTER_NORTH.
  But opponent (with ADAPTIVE AI) will mirror my expansion in CLUSTER_SOUTH.

  Better strategy: build a SUPPLY_LINE from CLUSTER_NORTH to CLUSTER_CENTER's BRIDGE_NODE.
  This requires CONS: connect NODE_2 to BRIDGE_NODE.

  OPERATOR ACTION: CONS (NODE_2) + (BRIDGE_NODE) → SUPPLY_LINE_1
  OPERATOR ACTION: EVAL (commit 2 influence to establish SUPPLY_LINE_1)

  Operator now has a strategic connection from their home cluster to the center.

TURN 5 (OPPONENT RESPONDS — ADAPTIVE AI)
  Opponent, reading operator's expansion, realizes: operator is trying to dominate center.
  Opponent pivots from PASSIVE to AGGRESSIVE: claims 2 neutral nodes in CLUSTER_SOUTH immediately.

  Opponent influence: was 4, is now 2 (after claiming).
  Board state changed. Operator's advantage in north is matched by opponent's advantage in south.

TURN 6 (ESCALATE CENTER CONTROL)
  OPERATOR ACTION: CDR (move to CLUSTER_CENTER)

  Current position: (NETWORK ... (CLUSTER_CENTER (BRIDGE_NODE_1 neutral) (BRIDGE_NODE_2 neutral)))

  OPERATOR ACTION: CAR (examine BRIDGE_NODE_1)
  OPERATOR ACTION: EVAL (claim BRIDGE_NODE_1 with 2 influence)

  Influence remaining: 1.
  Operator controls center north. Opponent cannot claim BRIDGE_NODE_2 without spending 2 influence (operator has advantage).

TURN 7 (CRITICAL DECISION)
  Operator has 1 influence point left. Opponent has 2.
  Opponent, if they commit 2, can claim BRIDGE_NODE_2, equalizing center control.

  Operator's best move: retreat to CLUSTER_NORTH and consolidate.
  OPERATOR ACTION: CDR (move back to CLUSTER_NORTH)
  OPERATOR ACTION: CAR (examine NODE_4)
  OPERATOR ACTION: EVAL (claim final NODE_4 with 1 influence)

  Operator now owns all 4 nodes in CLUSTER_NORTH.
  Territory count: 4 (north) + 1 (center) = 5. Opponent: 2 (south) + 0 (center) = 2.

TURN 8 (ENDGAME — WAIT FOR OPPONENT)
  Opponent, facing a disadvantage (operator controls north + bridge), commits 2 influence to BRIDGE_NODE_2.
  Opponent now owns: 2 (south) + 1 (center) = 3.

  Game continues to turn limit. Final tally:
    Operator: 5 nodes
    Opponent: 3 nodes + 1 bridge claim

  Operator does NOT reach 8 nodes needed for clear majority.
  Game continues to diplomatic phase (both players have claims).

  Outcome: Operator wins on tie-break (more nodes = greater influence).
  Payout: 900¤ + 100¤ (territory bonus) = 1000¤
  Rep: +2 (won against ADAPTIVE opponent)

Key Insight: The operator never selected “claim node” or “attack opponent.” They CAR’d into clusters, examined nodes, CONS’d supply lines (strategic connections), and EVAL’d territorial claims. The strategy emerged from nested list navigation.

REVISION 7: THE VAULT — Knowledge Index / Research System

7.1 Data Model as Nested List

THE VAULT’s data is a research tree: knowledge is nested hierarchies of entries, dossiers, and cross-references.

(VAULT
  (CORPORATE_PROFILES
    (YAMAGATA_CORP
      (EXECUTIVES
        (CEO (NAME "Tanaka Ryo") (LINKED_ENTRIES (DOSSIER_100)) (CONFIDENTIALITY SECRET))
        (CTO (NAME "Yamamoto Jun") (LINKED_ENTRIES (DOSSIER_101))))
      (SUBSIDIARIES
        (YAMAGATA_FINANCE
          (CEO_NAME "Tanaka Ryo")
          (LINKED_ENTRIES (FINANCIAL_AUDIT_42)))
        (YAMAGATA_RESEARCH
          (DIVISION "BIOTECH")
          (LINKED_ENTRIES (LAB_LOCATION_12))))))
  (FORENSIC_TRAILS
    (SHELL_COMPANY_NETWORK
      (COMPANY_A (OWNER (NAME "John Doe") (LINKED_TO "Tanaka Ryo")))
      (COMPANY_B (OWNER (NAME "Jane Smith") (SHELL_LAYER 2)))))
  (DOSSIERS
    (DOSSIER_100 (SUBJECT "Tanaka Ryo") (ENTRIES (BIOGRAPHY HISTORY CONNECTIONS)))
    (DOSSIER_101 (SUBJECT "Yamamoto Jun") ...)))

Key Insight: The Vault is a nested tree of corporate profiles, dossiers, and audit trails. CAR drills into categories. CDR moves between entries. CONS combines research findings into conclusions.

7.2 Key Operation Table

Operation	Meaning	Implementation	Why It’s Genuine
CAR	Drill into a corporate profile; examine executives or subsidiaries	CAR on VAULT → CORPORATE_PROFILES. CAR on COMPANY → first EXECUTIVE	Descending into nested categories
CDR	Move to next executive or subsidiary	CDR on executives → next EXECUTIVE. CDR on subsidiaries → next SUBSIDIARY	Traversing list rest
CONS	Combine two research paths into a unified forensic conclusion	EXECUTIVE_PROFILE ∪ FINANCIAL_AUDIT → COMBINED_CASE (new structured finding)	Constructing new investigative pair
NIL	No records; no entry; unknown person	Dead end in research trail	Empty list state
EVAL	Execute a research bounty; investigate target	Submit a “find all references to shell companies” LAMBDA search → gets results	Evaluating research query
QUOTE	Bookmark an entry without fully researching	Hold an entry in a reading list; defer investigation	Quoting: data without evaluation
LAMBDA	Record a research pattern (“find all references to company X in financial records”) → reusable query	Storing research procedure as function	Storing an investigation pattern
APPLY	Apply recorded research pattern to new target	Deploy “find shell companies” pattern against new corporate entity	Applying stored investigation to new data
ATOM	Test if entry is simple (atomic, single record) or complex (composite, multi-linked)	Single dossier (atom) vs. corporate profile with many cross-references (composite)	Element type checking
EQ	Test if two people are the same individual (identity by name, ID)	Are “Tanaka Ryo” at YAMAGATA and “Tanaka R.” in shell company list the same person?	Identity unification; critical for forensics

REVISION 8: CIPHER GARDEN — Cryptographic Tools

8.1 Data Model as Nested List

CIPHER GARDEN’s data is a cipher tree: encrypted messages are nested lists of layers, each with key states and decryption techniques.

(ENCRYPTED_MESSAGE
  (OUTER_LAYER
    (CIPHER_TYPE "ROT13")
    (KEY_STATE "unknown")
    (TECHNIQUES
      (BRUTE_FORCE (COST 5) (SUCCESS_RATE 100%))
      (FREQUENCY_ANALYSIS (COST 2) (SUCCESS_RATE 80%))))
    (INNER_LAYER
      (CIPHER_TYPE "SUBSTITUTION")
      (KEY_STATE "unknown")
      (TECHNIQUES
        (DICTIONARY_ATTACK (COST 3) (SUCCESS_RATE 70%))
        (INDEX_OF_COINCIDENCE (COST 4) (SUCCESS_RATE 95%)))
      (INNERMOST_LAYER
        (CIPHER_TYPE "XOR")
        (KEY_STATE "known: 0x42")
        (PLAINTEXT "SECRET DATA")))))

Key Insight: Encrypted data is nested layers. CAR drills into layers. CDR moves between cipher techniques. CONS combines decryption methods to crack multi-layer encryption.

8.2 Key Operation Table

Operation	Meaning	Implementation	Why It’s Genuine
CAR	Drill into a cipher layer; examine encryption type and techniques	CAR on MESSAGE → OUTER_LAYER. CAR on LAYER → first TECHNIQUE	Descending into nested encryption structure
CDR	Move to next cipher layer (deeper into message) OR next technique	CDR on layers → INNER_LAYER. CDR on techniques → next TECHNIQUE	Traversing layer stack
CONS	Combine two decryption techniques to create stronger attack	FREQUENCY_ANALYSIS ∪ BRUTE_FORCE → COMBINED_ATTACK (new structured approach)	Constructing multi-method attack strategy
NIL	Message fully decrypted; no more layers; plaintext reached	Empty cipher stack; decryption complete	Terminal state of list (no more nesting)
EVAL	Execute a decryption technique against a cipher layer	Deploy FREQUENCY_ANALYSIS against ROT13 layer; extract partial plaintext	Evaluating a crack strategy
QUOTE	Bookmark a cipher without attempting decryption	Hold encrypted layer as data; defer cracking	Quoting: encrypted data without interpretation
LAMBDA	Record a successful multi-layer decryption sequence → reusable pattern	”ROT13 → Frequency → XOR key extraction” → stored function	Storing a decryption procedure
APPLY	Execute recorded decryption sequence against new encrypted message	Deploy “proven 3-layer crack” pattern on newly-intercepted message	Applying stored decryption to new data
ATOM	Test if cipher is simple (atomic, single-layer) or complex (multi-layer)	Single ROT13 (atom) vs. ROT13 + SUBSTITUTION + XOR (composite)	Element type checking
EQ	Test if two cipher layers are identical (same algorithm, same key size)	Are both the same encryption standard?	Algorithm identity comparison

REVISION 9–12: NULL, RELAY, BLACK LEDGER, SYNTHFENCE

Due to space, I provide abbreviated revisions for the remaining four modules:

9. NULL — System Diagnostics (YELLOW → GREEN-READY)

Data Model: System state tree (nested SRAM, cartridge state, deck health). Key Operations:

CAR: Drill into SRAM segment
CDR: Move to next memory region
CONS: Combine integrity checks into verification report
EVAL: Execute diagnostic scan; report anomalies
LAMBDA/APPLY: Record and replay system validation sequence

10. RELAY — Firmware Updates (YELLOW → GREEN-READY)

Data Model: Patch tree (nested cartridge updates, opponent AI patches, system patches). Key Operations:

CAR: Drill into patch manifest
CDR: Move to next patch in sequence
CONS: Combine multiple patches into consolidated update
EVAL: Deploy patch; apply changes
LAMBDA/APPLY: Record and replay patch application sequence

11. BLACK LEDGER — Forensic Accounting (YELLOW → REVISED)

Data Model: Financial hierarchy tree (institutions → accounts → transactions → details). Key Operations:

CAR: Drill into bank, then account, then transaction
CDR: Move to next account or transaction
CONS: Combine transaction evidence into forensic case
EVAL: Execute audit; trace money flows
LAMBDA/APPLY: Record and replay audit patterns

12. SYNTHFENCE — Market Operations (RED → REVISED)

Data Model: Market hierarchy tree (commodity → region → exchange → timepoint → bid/ask). Key Operations:

CAR: Drill into market hierarchy
CDR: Move between commodities or timepoints
CONS: Combine market conditions into arbitrage pair
EVAL: Execute trade; lock in spread
LAMBDA/APPLY: Record and replay proven trading sequences

CONCLUSION: The Unified Paradigm

All 12 revised modules now embody the same Lisp paradigm:

Data is recursive lists. Every module’s core state is a nested structure that naturally supports CAR/CDR traversal.
CAR/CDR are structural operations. They navigate genuine list hierarchies, not cosmetic menus.
CONS builds structure. Every module has a meaningful CONS operation that constructs new composite data.
EVAL executes plans. Plans are quoted data that EVAL transforms into action.
LAMBDA/APPLY enable composition. Operators record sequences and replay them against new targets.
ATOM/EQ support reasoning. Operators can test element types and check identity.

An operator who masters ICE BREAKER’s Lisp semantics can transfer that intuition to ANY module. CAR means the same thing everywhere: descend into the HEAD of the current list. CDR means: traverse to the REST. CONS means: construct a new pair from two elements.

The Deckline is not 14 separate games. It is one unified interface for 14 domains, all speaking the same Lisp grammar.

End of Revisions