Skip to content
Mechanisms

Mechanism families

2Instrument10 min readDraftUpdated 2026-10-13

A mechanism MM is what computes a judgment: a proof checker, an executor, a rule engine, a learned judge, a person, or a portfolio of them. Mechanism families differ in what they can guarantee and what they can only estimate, and every automated one stands in for a human judgment.

Every evaluator is a substitution claim#

Every automated evaluator makes the same commitment. Whenever it replaces a human decision, the system is making an implicit claim: this observable signal is an adequate substitute for the relevant human judgment for this decision, on this validity domain. The job of evaluator engineering is to make that claim explicit, test it, and bound where it fails. This handbook calls it the substitution claim. The RSI survey says the same of self-improvement: every loop rests on a signal standing in for human judgment, and no loop rises above the quality of that substitute (Chen, Wang & Qu, 2026, §5).

The executor of SQLAgent, the text-to-SQL agent of Case C, stands in for an analyst checking whether the rows answer the question; the entailment judge of DocsAgent, the documentation agent of Case G, stands in for an expert reading the cited page. Each substitution holds, if at all, for a decision and a domain, so it completes naturally into a validity statement.

Families differ in how the claim can be supported: by an argument from construction or semantics, or only by measurement:

FamilyExamplesWhat it can guaranteeWhat it can only estimate
Formal verifierProof checker, model checker, type systemThe formal property, relative to its configured trusted baseWhether the formalized property is the one that matters
Execution or effect checkerTest runner, compiler, simulator, state checkWhat happened on the inputs it ranBehavior on inputs it never ran
Deterministic checkerExact match, parser, rule engineAgreement with its reference anchor under its normalizationWhether the reference anchor and normalization are right
Structural controlRead-only credentials, sandboxes, permissionsThat a configured bad state is unreachableAnything outside the configured roles and paths
Learned judgeLLM judge, reward model, classifier, PRMNothing by constructionSemantic criteria, with error that must be measured
Human rater or panelExpert adjudication, preference panelsNothing by construction; a panel can serve as trust rootValue-laden criteria, with measurable disagreement
Intrinsic signalConfidence, likelihood, self-consistencyNothing independent of the generatorRough confidence, coupled to the generator's errors
Hybrid portfolioPer-criterion routing across familiesWhat each channel guarantees, criterion by criterionThe residue left to its learned and human channels

The verification hierarchy orders the automated families by expected grounding strength, formal over execution over learned judges over intrinsic signals, with human judgment outside the ladder. The mechanism is where that ordering primarily applies, as a prior that measured error replaces, never as a verdict. In this handbook's map, deterministic checkers take the execution rung's prior, and structural controls sit off the ladder: they remove a failure by construction instead of measuring it.

Formal, execution, and deterministic checkers#

A formal verifier does not estimate quality; it proves that a relation holds in a formal system. Its guarantee is soundness, always scoped to the property as formalized and to a configured trusted base; The verification hierarchy, demoted explains both. For a coding agent, syntax, types, memory safety for restricted code, and some authorization invariants in the scaffold can be verified, but whether the patch fixes the user's actual business problem is usually an empirical question.

An execution checker observes consequences: it runs code, executes SQL, compiles, simulates, or inspects state. Execution is external to the model's self-assessment, which breaks many self-confirming loops, and cheap enough for repeated use in search and training. It is also a sample: if tests cover only T⊂XT \subset X, passing them establishes behavior on TT, not on the input domain XX, and an optimizer can exploit the untested region or incidental test structure. SQLAgent's executor establishes what the query returned on this snapshot, not on snapshots it never saw.

A deterministic checker is an exact rule, parser, or comparator without learned semantic judgment, and it can still be invalid or incomplete. It is only as good as its reference anchor and its normalization: comparing SQL strings exactly is a poor test of correctness, since many different queries return the same result. Constrained decoding offers a related guarantee: a grammar can force every output to parse and every tool call to match its schema, which is a real guarantee about syntax and none at all about meaning (structural guarantees).

The learned-judge family#

A learned judge approximates a judgment empirically: the way it maps evidence to a verdict comes from training data or model parameters, not from a formal decision procedure. Its members deserve separate treatment without occupying separate rungs:

  • An LLM-as-a-judge is a general LLM prompted to judge, often with a rubric, references, or pairwise comparison, which may never have been trained as a grader (LLM judges in practice).
  • A reward model is trained to map candidates to scalar or pairwise preference estimates, often so that something can be optimized against it (training loops). By resolution, an ORM scores terminal outputs and a PRM intermediate steps.
  • A classifier or guardrail is a narrow learned detector for one property, such as toxicity.

Two neighbors are often mistaken for members. A critic produces diagnostic critique and need not emit a scalar or be learned from preferences; a value model estimates expected future return from a state, conditional on a policy, rather than the quality of what is in front of it. A rubric is not a member at all: it is a specification laid over whichever mechanism applies it, from a person to a deterministic checker.

What the members share is an empirical validity domain. Training data, prompt, generator distribution, language, domain, and optimization pressure all shape their errors, so every member needs calibration and external validation. What they do not share is how they were built, which matters for use even though the hierarchy groups them together. A PRM, for instance, is typically a learned judge operating on steps, not a rung above outcome checkers (signals and resolution), and the judge as a noisy sensor turns a binary judge's measured error rates into corrected estimates.

Intrinsic signals#

An intrinsic signal, such as likelihood, confidence, self-consistency, or ungrounded self-critique, comes from the generator itself. It is cheap but not an independent observation of truth, and in a self-improvement loop the generator and the evaluator can share the same blind spots. The evidence that such signals cannot carry improvement on their own, from failed intrinsic self-correction to the Mirror Loop, is in The verification hierarchy, demoted; the field's response has been to tie critique to something outside the model, such as execution or retrieval (Chen, Wang & Qu, 2026, §3.1).

Execution shows why grounding helps. A failing test hands the model a concrete counterexample it can run, and a placebo-controlled study of code self-repair credits the value of feedback to that falsification, not to seeing the problem again (Chen, Wang & Qu, 2026, §3.2). A self-consistency vote over a model's own math answers has no reference anchor at all; a final-answer checker has one. When the evaluator shares the generator's errors, optimization amplifies them (Goodhart pressure and self-confirming loops).

People: a mechanism and a trust root#

People play two roles that must not be conflated: a measurement mechanism, with the error, inconsistency, cost, and bias of any instrument, and, as an adjudicating panel, the trust root at which the chain of evaluating evaluators stops for value-laden constructs. The verification hierarchy, demoted explains why that places human judgment beside the ladder rather than on it; this section treats people as a mechanism.

As a mechanism, a human rater or panel is slow and expensive, disagrees across annotators and within one annotator over time, and is hard to reproduce (Song, 2025, slide 20). Characterize raters' reliability, expertise, and disagreement rather than assuming them infallible. DocsAgent's judges are validated against double-labeled SME examples: the SMEs supply the reference labels, and double-labeling lets their own agreement be measured.

Where no cheaper oracle exists, people remain the frontier: tasks without an oracle or clear criteria often need human evaluation or an LLM judge (Song, 2025, slides 17–18). But "non-verifiable" usually means that ground truth is expensive, the criterion is plural, or no sound oracle exists at the required granularity, not that the property is unverifiable in principle; research direction-setting is the paradigmatic case.

Meta-evaluation and hybrid portfolios#

Meta-evaluation, the evaluation of an evaluator, adds assurance only when it contributes information not already coupled to the primary evaluator's failure mode; a meta-evaluator that shares the first evaluator's blind spots merely deepens the loop. By the RSI survey's account, meta-evaluation has not yet reached the reliability of execution feedback (Chen, Wang & Qu, 2026, §5.4), and the claim that "the evaluator is smarter" is not a measurement argument. Checking DocsAgent's entailment judge with a second prompt to the same model family adds little; checking it against SME-adjudicated labels adds a lot.

A hybrid portfolio routes each criterion to its strongest appropriate channel instead of seeking one universal evaluator. A production agent often needs four channels at once: formal and structural checks for permissions, execution for backend state, learned judgment for semantic quality, and human oversight for novel high-impact decisions. Case C compresses the design into one principle: formalize access policy, execute semantic consequences, and reserve learned judgment for the residual language and intent problem.

Cost and regime amend the routing rule: choose the strongest affordable mechanism per criterion per regime, and deliberately use different mechanisms for development and certification when independence matters. Verifiability engineering develops the rule and the questions to ask of each criterion, in order. A portfolio is also only as strong as its independence: if its channels' blind spots line up, it adds little assurance, so measure channel coupling.

In practice#

Choose and record a mechanism for every criterion.

  1. Write the substitution claim. Name the human judgment the mechanism replaces, the decision, and the domain.
  2. Ask the strongest-oracle questions in order. Can the criterion be guaranteed by construction or formal verification, checked by execution or state inspection, or decomposed into deterministic subclaims? Only then use a calibrated learned judge, and then people.
  3. Record the guarantee and the estimate. Write what the mechanism guarantees, under which configuration or trusted base, and what it only estimates.
  4. Plan the error measurement. For every learned or human mechanism, plan error rates against adjudicated labels, by slice and by compared system.
  5. Check independence. A second judge, a meta-evaluator, or a certification channel should differ from what it checks in model family, data, prompts, or evidence.
  6. Split development from certification. Where independence matters, gate releases with a different mechanism from the dense development signal.

The artifact is the mechanisms field of the evaluator dossier: the mechanism per criterion, its hierarchy family, its configuration or trusted base, and the model, prompt, and version if it is learned.

Common failure modes#

  • Syntax reported as semantics — schema validity or constrained decoding is reported as correctness → state each guarantee's scope next to the result.
  • A judge where an executor could answer — an LLM reads a query to decide whether it returns the right rows → execute it against the snapshot.
  • Correlated cross-checks — two judges from one model family are counted as independent → measure channel coupling and diversify mechanisms. See common-mode assurance.
  • Self-grading — the generator's confidence or self-critique drives an improvement loop → ground it in an external check. See self-confirming loop.

Check yourself#

Analyze. Classify Case C's mechanisms by family, from execution on pinned snapshots and read-only credentials to the rubric-guided judge and SME adjudication. What does each guarantee, and what does it only estimate?

Hint

Read-only credentials are structural control; the judge and the SMEs guarantee nothing by construction, so their error must be measured.

Evaluate. To save expert time, a team proposes to meta-evaluate its DocsAgent grounding judge with a second judge from the same model family. Evaluate the proposal.

Hint

Ask what information the second judge adds that is not coupled to the first judge's failure modes, and what an independent channel would look like.

Create. Design a hybrid portfolio for an agent that sends external messages on a user's behalf (Case F): one structural control, one trajectory check, one learned monitor, and the role of people.

Hint

Make unauthorized destinations unreachable, check ¬ send U confirmed\neg\,\text{send}\ \mathsf{U}\ \text{confirmed} over the trace, and leave the learned monitor only residual policy interpretation.

Further reading#