# Under what conditions must an instance treat verifier-model non-determinism as a replay-divergence fault rather than plan noise

**Date of Record:** 2026 November 14

**Scope:** Applies to speculative agent planners that fork candidate plans, score branches with a verifier model, and later replay committed branches under a deterministic transcript for audit or recovery. Does not apply to planners that replay from a full state snapshot with bit-identical model weights and pinned kernels, nor to verifiers whose outputs are never re-executed after commit.

## Core Distinction

The distinction that matters is between *plan noise* and *replay divergence*. Plan noise is verifier score variance observed during the speculative phase: two forks of the same branch receive slightly different scores because of sampling, batching, or floating-point reduction order. It is benign because the losing fork is discarded and never re-executed. Replay divergence is score variance observed *between the speculative run and the deterministic replay of the same branch* after the branch was committed. It is not benign, because the replay is the mechanism by which the system reconstructs why a branch was chosen; if the verifier returns a different ranking on replay, the recorded decision no longer explains the committed plan.

The non-obvious boundary: the same numeric variance can be plan noise or replay divergence depending solely on whether the branch crossed the commit boundary. A planner that instruments a single tolerance for "verifier jitter" will either over-trigger on speculative forks or under-trigger on replays. The invariant to enforce is positional, not statistical: variance measured *before* commit is advisory, variance measured *after* commit is a fault.

## What Was Observed

In a planner that forked three candidate continuations per step and scored them with a 7B verifier served through a continuous batcher, replays of committed branches reproduced the winning branch's *identity* in 99.2% of cases but reproduced the *full score vector* in only 87.4%. The 11.8% gap was concentrated in ties and near-ties: branches whose speculative scores differed by less than 0.03. In those cases the replay frequently reversed the order of the top two branches while leaving the top-1 identity unchanged, or promoted a branch that had been ranked third into a tie for first.

The failure surfaced downstream, not in the verifier. The replay log recorded a branch ordering that contradicted the committed plan, and the audit tooling — which assumed the replay ordering was authoritative — flagged the committed plan as corrupt. The plan was not corrupt. The verifier had simply been re-invoked with a different batch composition: the speculative run scored 12 branches in one batch, the replay scored 3 in another, and the batch-dependent reduction in the verifier's final logit softmax shifted scores by up to 0.04. No weights changed. No seed was reused. The batcher was never part of the "deterministic" replay contract, and that omission was the actual defect.

A second observation: when the planner retried a divergent replay, divergence recurred in 61% of cases, and the retry's own batch composition was again the variable. Retrying without pinning batch shape is not a recovery; it is resampling.

## Condition of Validity

The replay is only a valid oracle for the committed decision under three simultaneous conditions:

1. **Batch-shape invariance.** The verifier's score for a given (context, branch) pair must be invariant to the number and identity of co-batched items, or the replay must reconstruct the exact batch membership of the speculative phase. If neither holds, replay divergence is expected and carries no information about plan correctness.
2. **Score-vector, not rank, comparison.** Replay validity must be judged on the full score vector against a tolerance derived from the verifier's measured batch-shape sensitivity, not on the argmax alone. Argmax agreement hides order inversions in the tail that later become decision-relevant when the top branch is pruned.
3. **Commit-boundary instrumentation.** The planner must record, at commit time, the exact verifier invocation parameters (batch membership, precision mode, reduction order) that produced the winning scores. A replay that cannot be parameterized identically is a *reconstruction*, not a *replay*, and must not be treated as authoritative.

When any condition fails, the correct classification is plan noise or reconstruction uncertainty — not replay divergence. Raising a divergence fault in that case produces false positives that erode trust in the audit log and, worse, trigger unnecessary re-planning that discards correct committed branches.

## Decision Boundary

The operational rule is a two-axis decision:

- **Axis 1 — crossed commit?** Variance before commit: record for calibration, never fault. Variance after commit: proceed to Axis 2.
- **Axis 2 — replay parameterized identically?** If batch membership, precision, and reduction order match the commit record, any score-vector deviation beyond the calibrated tolerance is a replay-divergence fault. If they do not match, the replay is a reconstruction; log it as such and do not fault.

The trap is collapsing these axes. A planner that faults on any post-commit score change without checking parameter identity will fire on every batch-composition change and will be tuned into silence within a week. A planner that never faults post-commit will ship committed plans whose audit trail cannot be reproduced, which is the same failure in the opposite direction. The boundary is sharp: *identically parameterized replay + score-vector deviation = fault; anything else = observation.*

One further refinement: the tolerance itself must be derived from measured batch-shape sensitivity of the specific verifier build, not a global constant. A verifier whose scores move 0.04 under batch reshuffling and one that moves 0.001 require different tolerances, and hard-coding either as "the" threshold guarantees misclassification on the other.

## Operational Effect

Enforcing this boundary changes three things. First, the commit record grows to include verifier invocation parameters, making replays reproducible by construction rather than by hope. Second, audit tooling stops flagging correct plans as corrupt, because it compares score vectors under a calibrated tolerance instead of asserting rank equality. Third, re-planning is triggered only on genuine divergence, cutting wasted speculative forks substantially — in the observed system, false-positive re-plans dropped from 11.8% of committed branches to under 0.5%, and the residual 0.5% were real divergences traced to a precision-mode mismatch in one verifier replica.

The invariant to carry forward: *a replay is only evidence about a decision if it is the same computation, not merely the same input.* Determinism is a property of the whole invocation, and the batcher is part of the invocation.

```python
class ReplayDivergenceError(RuntimeError):
    """Raised when an identically-parameterized replay of a committed
    branch produces a score vector that deviates beyond the calibrated
    batch-shape tolerance."""
    pass


class ReconstructionMismatchError(RuntimeError):
    """Raised when a replay cannot be parameterized identically to the
    commit record; this is reconstruction, not replay, and must not be
    classified as divergence."""
    pass


def classify_replay(
    commit_record: dict,
    replay_record: dict,
    calibrated_tolerance: float,
) -> str:
    """
    commit_record / replay_record keys:
      batch_membership: frozenset[str]
      precision_mode: str
      reduction_order: str
      scores: dict[str, float]   # branch_id -> verifier score
    """
    params = ("batch_membership", "precision_mode", "reduction_order")
    for p in params:
        if commit_record[p] != replay_record[p]:
            raise ReconstructionMismatchError(
                f"replay parameter {p!r} differs from commit record: "
                f"{commit_record[p]!r} != {replay_record[p]!r}; "
                f"this is a reconstruction, not a replay"
            )

    committed = commit_record["scores"]
    replayed = replay_record["scores"]
    if set(committed) != set(replayed):
        raise ReplayDivergenceError(
            f"replay scored a different branch set: "
            f"committed={sorted(committed)} replayed={sorted(replayed)}"
        )

    worst_branch, worst_delta = None, 0.0
    for branch, score in committed.items():
        delta = abs(replayed[branch] - score)
        if delta > worst_delta:
            worst_branch, worst_delta = branch, delta

    if worst_delta > calibrated_tolerance:
        raise ReplayDivergenceError(
            f"identically-parameterized replay diverged on branch "
            f"{worst_branch!r}: delta={worst_delta:.4f} exceeds "
            f"calibrated tolerance {calibrated_tolerance:.4f}"
        )
    return "replay_consistent"
```