# WI-001 — Deterministic Paused/Replay/Live harness and evaluator (Gate 1)

Status: Built → Contract-verified → Measured → (Project-learning, Reader-ready recorded in LEDGER.md)

```text
work_item_id:        WI-001
question_id:         Q2 (prerequisite for Q3–Q6 harness use)
hypothesis_id:       H2
study_id:            S2 (harness prerequisite); S5.2 label definitions
current_project_belief:
    A matched Paused–Replay–Live comparison in which Replay and Live differ ONLY in
    task-clock treatment is realizable for a one-response episode. The old pilot never
    constructed one, so this belief is untested. We also believe a scorer built only
    from E, O, B, D, A can assign the failure labels of S5.2 without ambiguity.
exact_uncertainty_to_reduce:
    U1. What is the executable definition of "Replay", and what is the minimal set of
        identities the Replay–Live pair validator must compare?
    U2. Does an evaluator built from E, O, B, D, A reproduce KNOWN outcomes when the
        controller is a scripted oracle with declared compute and delivery delays
        (Paused = Replay = 1; Live = step in total delay vs. window), and do the S5.2
        labels partition every oracle Live failure?
    U3. Does the harness reject each §16 defect that applies before any GPU exists?
claim_or_decision_enabled_by_this_work:
    Admit or refuse Gate 2 (a real controller) on this harness. Decide whether Replay
    needs a re-run or is a re-scoring for deterministic memoryless controllers.
intended intervention or measurement:
    Oracle controller; sweep compute_ns and delivery_delay_ns against response_window_ns.
matched conditions:          Paused, Replay(Live), Live on one manifest/seed/controller spec.
variables held fixed:        scenario manifest, seed, controller spec, action-space v1,
                             scorer v1, observation-boundary v1, delivery route, timestamp source.
primary outcome:             validity at A (application-time value); per-trial labels;
                             pair-validator verdicts; negative-test rejections.
required trace fields:       experiments.md §13 (all), realized as trace.py record types.
competing explanation ruled out:
    "A Replay–Live gap is an artifact of the harness or scorer." Ruled out iff the
    oracle sweep matches the closed-form prediction exactly.
possible result patterns and their interpretations:
    (a) all predictions hold, all negative tests reject  → harness is contract-verified.
    (b) a prediction fails                               → clock policy or scorer is wrong; fix before any model.
    (c) a defect is not rejected                         → contract gap; fix before any model.
project_delta_expected_from_each_result:
    (a) Replay semantics pinned; validator comparison set known; label set shown exhaustive
        for the oracle. (b)/(c) one specific defect located.
project_decision_unlocked:   Gate 2 admission; whether a concurrent observation publisher
                             is needed for wall-clock controllers (it is — see LEDGER).
generalist_reader_starting_point:
    "Benchmarks pause the screen while the agent thinks; we want to see what happens
    when the screen does not wait."
one_sentence_reader_takeaway:
    With a perfect but slow clicker, the only thing that differs between Replay and
    Live is whether the target is still there when the click lands — and the trace
    says whether the controller could have known.
reader_confusion_or_misconception_prevented:
    A Replay–Live gap is NOT "the agent saw more frames": for a memoryless
    deterministic controller Replay's committed action is identical to Live's by
    construction; only the receipt-time validity differs.
positive acceptance test:    tests/test_oracle_predictions.py; CLI triplet runs; pair valid.
negative contract test:      tests/test_contracts.py — §16 items 1,2,3,4,5,6,7,10,11,12,13,14,15,16,17,18.
                             Items 8, 9 (GPU residency) are not applicable before Gate 3.
stop condition:              any prediction mismatch or undetected defect → stop, fix,
                             do not start a model.
what this work does not establish:
    anything about any model's competence; anything about physical D→A; whether the
    Paused–Replay contrast is informative (it is vacuous for memoryless controllers).
what remains unknown afterward:
    wall-clock controllers need a concurrent publisher (not built); physical A; whether
    a VLM can do even the Paused task.
```