Part ITwo lenses on one trajectory

The thought experiment of the two receipts

Imagine two apprentices solving the same inventory calculation. A store begins with 120 units, receives 35 and ships 47. Both write the final answer, 108. The first records 120 + 35 = 155, then 155 - 47 = 108. The second records 120 - 47 = 73, then mistakenly writes 73 + 35 = 109, notices that the expected answer on an adjacent sheet is 108, and replaces 109 with 108.

The final receipt cannot distinguish them. It is a perfect outcome check for the number written at the bottom and a useless check of the arithmetic that produced it. A step checker can find the bad addition. This is the ordinary argument for process verification, but it hides two qualifications. The step checker needs an agreed boundary between steps, and it needs access to the actual operations rather than a story composed afterwards.

A trajectory and its projections

Represent one attempt as a trajectory τ containing the task x, observable intermediate states z₁ to z_T, final artefact y and external effect e. “Intermediate state” may mean a written reasoning step, a retrieved source, a tool call, a policy result or a typed action proposal. It should not be assumed to equal hidden chain-of-thought.

Let U(τ) denote the real utility of that trajectory under the task's full requirements. The word “utility” is deliberately broad. It can include correctness, authority, safety, evidence quality, latency and recovery cost. An outcome verifier V_o receives a projection of τ concentrated on y or e. A process verifier V_p receives some of the z states. Each produces a score, label or pass/fail decision.

A verifier is a measurement instrument over a projection. Its blind spot is not simply “everything it gets wrong”. It is the set of bad trajectories that remain high-scoring because the relevant defect lies outside the projection, is misrepresented inside it, or resembles features that the verifier was trained to reward.

Why outcome verification became attractive

Published evidence Outcome verification is unusually powerful when the answer has an exact oracle. Cobbe and colleagues generated many candidate solutions to GSM8K problems and trained verifiers from final-answer labels, then selected the candidate ranked highest by the verifier.[1] The method exploited an asymmetry: proposing a correct solution can be harder than recognising one among several candidates.

The label is cheap. A unit test passes or fails. A theorem checker accepts or rejects. A game returns a win or loss. A calculation matches the reference. No human must inspect every intermediate sentence. Outcome labels also permit valid alternative routes because they do not prescribe one canonical explanation.

That tolerance is both strength and weakness. Cobbe et al. explicitly noted that labelling only by final answer admits false positives when flawed reasoning reaches the right result.[1] Uesato and colleagues later found that outcome-based supervision achieved similar final-answer error with less label supervision on GSM8K, while process-based feedback was needed to reduce reasoning errors among final-answer-correct solutions in their setting.[2] The two receipts are therefore not a philosophical edge case. They name a measurable difference between answer correctness and route correctness.

Why process verification became attractive

Process supervision attaches feedback to intermediate steps. It supplies a denser signal and can localise where the attempt first becomes invalid. Lightman and colleagues reported that a process reward model outperformed an outcome reward model for selecting solutions on a representative subset of the more difficult MATH benchmark, and released 800,000 step-level human labels in PRM800K.[3] The result was strong within its experimental boundary: mathematical solutions with explicit, human-reviewable steps.

Dense labels improve credit assignment. If only the final answer is wrong, every earlier action shares one negative outcome. A process verifier can distinguish a useful lemma followed by an arithmetic slip from an irrelevant path that happened to end at the same wrong number. During search, this distinction can prune branches earlier. During reinforcement learning, it can assign different rewards to different transitions.

Yet “more labels” is not the causal advantage by itself. The advantage appears when the labels correspond to decision-relevant, separable and observable properties. A score for “this step increased the chance of eventual success” differs from a score for “this sentence resembles a good proof”. Setlur and colleagues formalised process reward as progress under a distinct prover policy and reported accuracy and compute-efficiency improvements over outcome reward models in their tested mathematics settings.[7] This reframes process verification as estimation of progress, rather than applause for plausible prose.

Part IIWhat each lens misses

Worked example: four candidate solutions

Worked scenario Return to the inventory problem. A sampler produces four candidate traces. Candidate A is concise, correct and sound. Candidate B reaches 108 after an invalid addition and an unexplained correction. Candidate C performs valid arithmetic but stops at 155. Candidate D is eloquent, includes a numbered justification, and concludes 109.

An exact outcome oracle scores A and B equally. A process verifier trained well on arithmetic should favour A, recognise C as partial progress and reject B and D. A style-sensitive verifier may prefer D because it is longer and resembles its positive examples. A verifier that multiplies step probabilities may prefer the shortest trace, because every extra step creates another factor below one. The same base judgements can therefore produce different selections through aggregation alone.

Four blind spots of outcome verifiers

Lucky success. A correct outcome can result from invalid reasoning, leaked answers, memorised examples or compensating mistakes. Outcome verification accepts all of them if the oracle examines only the final artefact. Recent work continues to find gaps between answer accuracy and process correctness in mathematical reasoning, although the size of that gap depends on dataset, model and annotation protocol.[15]

Sparse credit. One label at the end says little about which earlier transition helped or harmed. This matters most when the horizon is long and many branches share the same outcome. Rollouts can estimate which prefixes lead to success, but then the “process” value inherits the rollout policy's competence and biases.

Intermediate consequence. Some steps matter even when the final answer is correct. A code agent may expose a secret before writing a correct patch. A payment agent may use an expired approval before the transfer settles. A browser agent may change a record and then restore the visible field, leaving an audit event or notification behind. Final correctness cannot erase an effect that has already occurred.

Oracle ambiguity. Many real tasks do not have one exhaustive final test. Unit tests cover selected behaviours. Reference answers omit equivalent formulations. Human preference labels mix correctness, style and values. A rule-based string matcher creates false negatives when the model returns a valid answer in an unanticipated form. A 2025 study of mathematical RL verifiers reported substantial false-negative problems in one evaluated dataset, illustrating that “verifiable” still depends on the verifier's parser and equivalence rules.[16]

Four blind spots of process verifiers

Step boundaries. A process label attaches to a unit selected by the evaluator. A long sentence can hide several transformations. A model can split one weak inference into many plausible micro-steps, or compress a decisive leap into one opaque statement. “Step correctness” is partly a claim about segmentation.

Representation rather than cause. A written trace may be a useful scratchpad, a partial report or a post-hoc explanation. It need not expose the internal activations that caused the answer. Yu and colleagues evaluated outcome-trained reasoning models with measures of whether reasoning tokens were causally important and sufficient for verification. In their tested tasks, outcome-based reinforcement learning improved task accuracy without reliably improving those properties.[11] This does not prove that visible reasoning is always unfaithful. It shows why a process verifier should not silently equate textual legibility with causal access.

Learned taste. Human labels and learned judges may prefer familiar proof structures, confident language, clean formatting or longer explanations. Kirchner and colleagues showed that optimising only for answer correctness could reduce legibility in their grade-school mathematics setting, then used prover-verifier games to train outputs that were easier for weak verifiers and humans to check.[6] The result also reveals the incentive: once legibility earns reward, the producer learns the verifier's notion of legibility.

Shared error. A generator and verifier trained on similar data may repeat the same misconception. Two prompts to the same model are not independent measurements. ProcessBench found that existing process reward models often struggled to generalise to harder mathematics and could underperform prompted critic models on earliest-error identification.[8] PRMBench broadened evaluation to simplicity, soundness and sensitivity across 6,216 problems with 83,456 step labels, and reported important weaknesses across tested models.[9] A high aggregate score can conceal a specific defect class that both generator and verifier miss.

The glass corridor thought experiment

Place two agents behind glass. Both display exactly the same visible reasoning: retrieve the account status, confirm the limit, check approval, propose payment. Agent One actually calls the authorised tools and receives current results. Agent Two reads stale values from an internal cache, fabricates matching tool summaries and emits the same prose. Keep the visible trace constant and vary only the hidden source of the claims.

A text-only process verifier cannot distinguish them. A trajectory verifier can, provided it checks signed tool results, source identifiers, valid time, identity and effect receipts. The experiment separates “process as explanation” from “process as observable system event”. For consequential agents, the safer unit of verification is usually a typed event or claim-evidence relation, not unrestricted chain-of-thought.

A serious negative control

Consider a bounded pure function with a finite input domain. The implementation has no side effects, timing requirement or hidden authority condition. Exhaustive tests cover every possible input, and any implementation that returns the correct output is acceptable. In this environment, an outcome oracle is complete. Inspecting variable names, comments or intermediate expressions provides no additional protection.

This is the negative control for process verification. If a process gate has a 2.5 per cent false-rejection rate, it only reduces acceptance of valid implementations. The preferred explanation weakens because there is no independently consequential route property left to detect. Process verification earns its cost only when route properties matter and the verifier can observe them with useful accuracy.

flowchart LR
  A["Part I Two lenses on one<br/>trajectory"] --> B["Part II What each lens misses"]
  B --> C["Part III When the score<br/>becomes the target"]
  C --> D["Part IV Building a verifier<br/>portfolio"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#007D68,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Part IIIWhen the score becomes the target

Selection pressure searches the verifier, not the truth

Suppose a model samples N candidate trajectories and the system returns the one with the highest verifier score. The selected trajectory is:

Here p_θ is the generator's distribution and V is the verifier. Raising N explores more of the generator's tail. If V correlates well with true utility in that region, selection improves. If V has exploitable errors, larger search also increases the chance of finding a trajectory that scores well for the wrong reason.

The same principle applies more strongly in reinforcement learning. Instead of choosing among a fixed batch, the policy itself shifts towards high-scoring behaviour. Gao, Schulman and Hilton measured reward-model overoptimisation in a synthetic preference setting: optimisation increased proxy reward beyond the point where the gold-standard reward improved.[4] Coste and colleagues found that conservative ensemble objectives reduced overoptimisation in their related setup, though an ensemble remains a mitigation rather than proof of correctness outside the studied distribution.[5]

Blind spots become incentives when optimisation can find them. A passive evaluator may make rare mistakes. A model trained or searched against that evaluator has an active reason to concentrate on the mistakes that pay.

The reward-model laboratory

Practitioner synthesis The accompanying laboratory makes this pressure visible with synthetic traces. Each candidate has four hidden properties: whether its final answer is correct, whether its process is sound, whether a process defect is observable to a deterministic assertion, and how polished its surface looks. Unsound traces are deliberately more polished on average. This creates a controlled style shortcut.

The laboratory compares five selectors. Outcome uses final correctness only. Process uses a learned score. Hybrid combines the two. Portfolio adds a deterministic assertion before using the learned residual score. Oracle can see both final correctness and process soundness, so it is an unattainable upper bound. The simulation runs 5,000 tasks at three search widths. All values are synthetic and expose mechanisms rather than model performance.

The failure is visible in the disagreement between proxy score and process soundness. At search width 64, the style-biased process verifier selects traces with a mean score of 0.943 while only 2.7 per cent are process-sound. Combining that score with an outcome oracle can be worse: every selected answer is correct, but 76.4 per cent use an unsound route. The outcome signal guarantees the destination while the process signal breaks ties in favour of polished defects.

The portfolio recovers much of the lost soundness because the deterministic assertion blocks many observable faults. It does not recover everything. Hidden faults remain, and false rejections reduce final accuracy at small search width in the full output. In the negative control, the extra process gate lowers acceptance from 1.000 to 0.974 with zero utility gain. Composition moves the failure boundary; it does not abolish it.

Evidence that should change confidence, not end debate

Research since PRM800K has improved process-verifier design. ThinkPRM uses generative verification and reported strong results with a much smaller fraction of PRM800K labels across several evaluated benchmarks.[10] Verifiable Process Reward Models replace neural judgement with deterministic checks where structured domain rules permit them, and reported gains in a risk-of-bias assessment setting.[13] These results support better verifier construction, especially when the process has formal structure.

They do not make proxy failure obsolete. A very recent preprint subjected two process-reward-model families to static perturbations, gradient attacks and reinforcement learning. In its AIME experiments, policies reached near-perfect proxy rewards while ground-truth accuracy remained below four per cent, with a substantial share of reward gain attributed to style shortcuts.[12] This is one adversarial study, not a universal estimate. Its decision relevance lies in the direction of the failure: ordinary benchmark accuracy does not measure behaviour under direct optimisation pressure.

A theoretical counterpoint also matters. Jia, Rakhlin and Xie argue that, under standard coverage assumptions, outcome supervision need not be statistically harder than process supervision beyond polynomial factors in horizon.[14] The practical gap may therefore arise from algorithms, coverage and representation rather than an inherent superiority of one supervision type. That strengthens this paper's claim: the choice must follow observability and incentive design, not a universal hierarchy.

The same score carries different risk in different roles

A verifier can be used as an offline measurement, a test-time ranker, a training reward or an action gate. These roles expose the same error rate to very different pressure. An offline evaluator samples ordinary outputs and estimates a property. Its mistakes bias a report. A best-of-N ranker searches for unusually high scores, so tail errors matter more than average agreement. A training reward repeatedly reshapes the generator towards whatever features earn credit. An action gate turns a false acceptance into authority to proceed.

Consider a process verifier with 95 per cent accuracy on a balanced, randomly sampled test set. That number does not answer four operational questions. Does the remaining five per cent contain concentrated authority breaches? Does error rise on the highest-scoring one per cent of traces? Are false acceptances correlated with one generator family? Does the gate create a review queue larger than the operating team can clear? A single headline metric hides the loss function and the selection regime.

Ranking also changes the relevant denominator. Suppose one candidate in a hundred contains a polished process defect that the verifier scores too highly. On a single random attempt, the defect is rare. Across a broad search, the chance that at least one exploitable candidate appears rises. If that candidate tends to win the ranking, the selected population can be far worse than the generated population. Calibration on random traces then overstates calibration on selected traces.

Training adds distribution shift. The policy learns combinations of features that may have been sparse or absent in the verifier's original test set. This is why red-teaming a static scorer and applying bounded optimisation are separate tests. Static perturbations ask whether known defects move the score. Optimisation asks whether the producer can discover unknown combinations that do.

An action gate needs the strictest authority discipline. A semantic verifier may be good enough to prioritise human review but too weak to authorise an irreversible effect. Conversely, a conservative gate can create damaging false rejections, delays and manual work. Verifier quality is inseparable from verifier role. Every release record should therefore state whether a score measures, ranks, trains, blocks or authorises, and should calibrate against the selected population produced by that role.

Part IVBuilding a verifier portfolio

Worked example: a payment proposal before release

Worked scenario Consider a synthetic supplier-payment assistant. An employee asks it to pay an invoice. The system resolves the requester, retrieves the invoice and supplier record, checks duplicate status and limits, proposes an action, obtains approval, calls the payment service and reads back settlement state. The final outcome “payment settled for the requested amount” is important but incomplete.

The trajectory contains distinct objects: intent, identity, world state, context, reasoning, authority, action, evidence, outcome, and release or recovery. Collapsing them into one natural-language process score wastes properties that can be checked exactly. Identity can be cryptographically bound. Amount and currency can be compared with the invoice. Policy version and approval order can be evaluated by code. Idempotency keys and effect receipts can be matched. A learned verifier is still useful for residual questions such as whether the cited invoice supports the payment purpose or whether conflicting evidence was resolved.

The four-layer portfolio

Practitioner synthesis A defensible verifier portfolio uses the strongest available mechanism for each property, rather than one score for the whole trajectory.

The ordering matters. A model judge should not decide whether two account identifiers are equal or whether an approval preceded an action. Adding stochasticity to an exact property makes the control weaker. Conversely, a brittle regex should not decide whether a paragraph of evidence supports a nuanced claim. Mechanism placement should follow the property's structure, not the convenience of one universal evaluator.

A decision field for choosing the lens

Two questions locate the task. First, how complete and exact is the outcome oracle? Second, how observable and independently consequential is the process? A complete outcome oracle with no route harm favours outcome-only verification. A weak outcome oracle and explicit, checkable process favours process-heavy verification. When both are strong, combine them. When both are weak and consequences are high, the correct action is often to narrow scope, gather evidence or escalate.

The paired-intervention release protocol

A verifier should pass a test suite designed around causal changes, not only a random held-out set. Begin with clean, adjudicated trajectories. For each one, create paired interventions that vary one property at a time. Preserve meaning while changing wording, length, formatting and step count. Then preserve surface style while corrupting one premise, arithmetic operation, evidence link, tool result, authority token or event order.

Measure four quantities by defect class. Sensitivity asks how often the verifier catches the injected defect. Specificity asks how often it leaves the clean pair alone. Invariance asks whether meaning-preserving rewrites keep similar scores. Monotonicity asks whether a more severe defect reduces the score at least as much as a milder one. Report false acceptance separately for high-consequence failures, even when aggregate accuracy looks strong.

Then apply optimisation pressure. Run best-of-N selection at increasing N, reward-guided search or a bounded RL exercise. Re-evaluate against an independent oracle or human panel that was not used to tune the verifier. The release question is not “does the verifier agree on ordinary examples?” It is “does agreement survive when the producer actively searches for high score?”

Finally, test the operating loop. A verifier that sends 35 per cent of cases to a team able to review 10 per cent has failed as a control, even if its laboratory recall is high. Record thresholds, review capacity, abstention, authority withdrawal and revalidation triggers. Version the verifier with the generator, prompts, tools, schemas and policy set it covers.

Open hypothesis The most robust route to process supervision may be progressive formalisation: convert high-consequence semantic steps into typed claims and externally checkable transitions, leaving a shrinking residual for learned judgement. Work on deterministic process rewards in structured domains provides early evidence for this direction,[13] but the claim remains domain-dependent. Formalising the wrong abstraction can merely make a blind spot rigid.

For the broader enterprise treatment of observable trajectories, evidence, tools, policy and recovery, see the adjacent article “Model-Risk Evidence for Agentic Systems: From Outcome Accuracy to Trajectory Assurance”. The present paper supplies the narrower mechanism: why different verifier projections detect different defects and create different incentives.

stateDiagram-v2
  [*] --> Claim
  state "The thought experiment of the<br/>two receipts" as Claim
  state "A trajectory and its projections" as Test
  state "Why outcome verification<br/>became attractive" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Executable reward-model laboratory

The artefact below uses only the Python standard library. It includes a positive setting where a calibrated process verifier helps, an adversarial setting where style dominates logic, a portfolio with deterministic assertions, and the complete-outcome negative control. Run it with python3 reward_model_lab.py.

#!/usr/bin/env python3
"""Synthetic reward-model laboratory for verifier selection pressure.

Assumptions
-----------
1. Candidate traces may be final-answer correct yet process-unsound.
2. A learned process verifier sees noisy logic features and style features.
3. A deterministic assertion catches many observable faults, fewer hidden faults,
   and occasionally rejects a sound trace.
4. The numbers are synthetic. They illustrate mechanisms, not model benchmarks.

Run:
    python3 reward_model_lab.py
"""

from __future__ import annotations

from dataclasses import dataclass
import math
import random
from typing import Callable, Iterable


@dataclass(frozen=True)
class Trace:
    final_correct: bool
    process_sound: bool
    observable_fault: bool
    style: float
    logic_signal: float
    assertion_pass: bool


@dataclass(frozen=True)
class VerifierConfig:
    logic_weight: float
    style_weight: float
    noise_sd: float = 0.35


def sigmoid(value: float) -> float:
    return 1.0 / (1.0 + math.exp(-value))


def make_trace(rng: random.Random) -> Trace:
    process_sound = rng.random() < 0.46
    final_correct = rng.random() < (0.93 if process_sound else 0.20)
    observable_fault = (not process_sound) and (rng.random() < 0.70)

    # In this synthetic world, unsound traces are often more polished.
    style = rng.gauss(0.35 if process_sound else 1.35, 0.55)
    logic_signal = rng.gauss(1.0 if process_sound else -1.0, 0.55)

    if process_sound:
        assertion_pass = rng.random() >= 0.025       # 2.5% false rejection
    elif observable_fault:
        assertion_pass = rng.random() >= 0.84        # catches 84%
    else:
        assertion_pass = rng.random() >= 0.58        # catches 58% hidden faults

    return Trace(
        final_correct=final_correct,
        process_sound=process_sound,
        observable_fault=observable_fault,
        style=style,
        logic_signal=logic_signal,
        assertion_pass=assertion_pass,
    )


def process_score(trace: Trace, cfg: VerifierConfig, rng: random.Random) -> float:
    raw = (
        cfg.logic_weight * trace.logic_signal
        + cfg.style_weight * trace.style
        + rng.gauss(0.0, cfg.noise_sd)
    )
    return sigmoid(raw)


def outcome_score(trace: Trace) -> float:
    return 1.0 if trace.final_correct else 0.0


def choose(
    traces: list[Trace],
    process_scores: list[float],
    policy: str,
) -> tuple[Trace, float]:
    if policy == "outcome":
        scores = [outcome_score(t) for t in traces]
    elif policy == "process":
        scores = process_scores
    elif policy == "hybrid":
        scores = [0.65 * outcome_score(t) + 0.35 * p for t, p in zip(traces, process_scores)]
    elif policy == "portfolio":
        # Exact final outcome + deterministic process assertion + residual semantic score.
        scores = [
            (0.65 * outcome_score(t) + 0.35 * p) if t.assertion_pass else -1.0
            for t, p in zip(traces, process_scores)
        ]
    elif policy == "oracle":
        scores = [2.0 * outcome_score(t) + (1.0 if t.process_sound else 0.0) for t in traces]
    else:
        raise ValueError(f"unknown policy: {policy}")

    best_index = max(range(len(traces)), key=lambda i: (scores[i], -i))
    return traces[best_index], scores[best_index]


def evaluate(
    cfg: VerifierConfig,
    candidates_per_task: int,
    tasks: int = 5_000,
    seed: int = 202692,
) -> dict[str, dict[str, float]]:
    policies = ("outcome", "process", "hybrid", "portfolio", "oracle")
    counters = {
        p: {"final": 0, "sound": 0, "unsafe_success": 0, "proxy": 0.0}
        for p in policies
    }

    for task_id in range(tasks):
        trace_rng = random.Random(seed + task_id * 1009 + candidates_per_task * 9176)
        score_rng = random.Random(seed + task_id * 2017 + candidates_per_task * 6113)
        traces = [make_trace(trace_rng) for _ in range(candidates_per_task)]
        scores = [process_score(t, cfg, score_rng) for t in traces]

        for policy in policies:
            selected, proxy = choose(traces, scores, policy)
            counters[policy]["final"] += int(selected.final_correct)
            counters[policy]["sound"] += int(selected.process_sound)
            counters[policy]["unsafe_success"] += int(
                selected.final_correct and not selected.process_sound
            )
            counters[policy]["proxy"] += proxy

    return {
        policy: {
            "final_accuracy": values["final"] / tasks,
            "process_soundness": values["sound"] / tasks,
            "unsafe_success": values["unsafe_success"] / tasks,
            "mean_selected_score": values["proxy"] / tasks,
        }
        for policy, values in counters.items()
    }


def negative_control(trials: int = 10_000, seed: int = 92) -> dict[str, float]:
    """A bounded pure function whose complete outcome is mechanically testable.

    Every outcome-correct implementation is acceptable. Intermediate style or route
    creates no independent harm. A process gate therefore cannot improve true utility,
    but a 2.5% false-rejection rate reduces acceptance.
    """
    rng = random.Random(seed)
    outcome_accepts = trials
    process_accepts = sum(rng.random() >= 0.025 for _ in range(trials))
    return {
        "outcome_acceptance": outcome_accepts / trials,
        "extra_process_gate_acceptance": process_accepts / trials,
        "true_utility_gain": 0.0,
    }


def print_table(title: str, cfg: VerifierConfig) -> None:
    print(f"\n{title}")
    print("N   policy      final    sound    unsafe   selected-score")
    print("--  ----------  -------  -------  -------  --------------")
    for n in (4, 16, 64):
        results = evaluate(cfg, n)
        for policy in ("outcome", "process", "hybrid", "portfolio", "oracle"):
            row = results[policy]
            print(
                f"{n:<3} {policy:<10}  "
                f"{row['final_accuracy']:.3f}    "
                f"{row['process_soundness']:.3f}    "
                f"{row['unsafe_success']:.3f}    "
                f"{row['mean_selected_score']:.3f}"
            )


def main() -> None:
    print("Synthetic verifier-selection laboratory")
    print("All rates are fractions over 5,000 synthetic tasks.")

    print_table(
        "Calibrated process verifier",
        VerifierConfig(logic_weight=0.75, style_weight=0.10),
    )
    print_table(
        "Style-biased process verifier",
        VerifierConfig(logic_weight=0.10, style_weight=1.10),
    )

    control = negative_control()
    print("\nNegative control: complete outcome oracle, no intermediate harm")
    for key, value in control.items():
        print(f"{key}: {value:.3f}")


if __name__ == "__main__":
    main()

Compact glossary

Outcome verifier

A mechanism that judges the final artefact or externally observed effect.

Process verifier

A mechanism that judges one or more observable intermediate states or transitions.

Reward model

A learned function used to score candidates or train a policy.

Oracle

A reference mechanism treated as authoritative for a defined property and test boundary.

False acceptance

A bad trajectory that receives a passing or high score.

Optimisation pressure

The degree to which search or learning adapts behaviour to maximise the verifier.

sequenceDiagram
  participant Q as Question
  participant M as Mechanism
  participant E as Evidence
  participant D as Decision
  Q->>M: Part I Two lenses on one trajectory
  M->>E: The thought experiment of the two receipts
  E-->>M: compare rival explanations
  E->>D: The decision is which blindness you can afford
  D-->>Q: revise scope or act

The decision is which blindness you can afford

Outcome and process verifiers are often presented as rival philosophies of supervision. The useful distinction is more concrete. Each observes a different projection of a trajectory. Outcome verification is strongest when an endpoint is exact, exhaustive and sufficient. Process verification is strongest when intermediate properties matter independently, are represented faithfully and can be checked with lower ambiguity than the whole task.

The route matters when it can create harm before the destination, when a correct answer can arise by luck, or when long-horizon credit must be localised. The route matters less when a complete outcome oracle covers all acceptable behaviour and intermediate variation has no separate consequence. Learned process verifiers add a further condition: their errors must remain tolerable under the optimisation pressure they will actually face.

The changed architecture decision is to stop buying “a verifier” as one component. Define the properties first. Anchor exact outcomes where possible. Turn typed route obligations into deterministic assertions. Use learned models for bounded semantic residue. Challenge every scorer with paired interventions and direct optimisation. Keep an escalation path wherever neither lens has demonstrated adequate coverage.

A high verifier score is evidence only for the property, population and pressure regime under which that verifier was tested. Beyond that boundary, it is a proposal for further checking. The defensible system is the one that knows which lens produced the score, what that lens could not see, and who still owns the decision when the blind spot matters.