What it looks like in the wild
Ask why a system has a verifier, and someone points to a stage in the pipeline: a box between a worker’s output and whatever ships next. Ask whether that verifier has ever said no, and a quieter question gets asked, one almost nobody has answered, because the team measures whether the box exists, not what it does.
A rubber-stamp verifier is easy to spot once you go looking and easy to miss otherwise, because from the outside it looks exactly like a working one: a verification step on the diagram, a verdict in the logs on every call, a pass rate on the dashboard, usually a high one, which reads as good news to anyone who has not asked what that number would look like if the verifier were structurally unable to return anything else. It shows up as a code-review bot approving pull requests it nominally gates, or an eval harness scoring outputs against a rubric too loose to trip on the system’s own habitual failure. Most often it is a verifier agent checking a worker’s answer with a bare “does this look right” prompt, running the same base model that produced the answer, grading its own class of work against no written standard at all.
The tell is not that the verifier approves most things; most things should be approved. The tell is that the approval rate does not move when the input quality does: feed it good answers and deliberately broken ones, and if approved comes back on both piles at close to the same rate, nothing about the check is tracking the thing it exists to check.
This shape already has a name, just not this one. Cemri et al.’s MAST taxonomy of multi-agent failure modes calls it Incorrect Verification: a verifier accepting an output without properly checking it against the task. MAST supplies the failure mode; this catalogue supplies the plainer name. That is what restated status means here: naming an existing description, not discovering one.
Why it happens
Ask a model to judge output it just produced, or output of the kind it habitually produces, and the question has been put to the wrong party. The generator and the verifier, sharing a base model and no rubric to break the symmetry, share blind spots too: whatever class of mistake that model tends to make is the class it is least likely to catch in its own work, because catching it would require noticing something its own training never taught it to flag.
Even a genuinely separate verifier call gets nowhere on “does this look right,” because the question gives the model nothing to stand on. A rubric is what makes a verifier able to say no: explicit, checkable criteria a specific failure can be measured against, so a verdict compares against something written down rather than an impression of plausibility. Strip the criteria out and the verifier is not lenient so much as directionless; nothing was ever specified as what a wrong answer would look like, so everything reads as approvable.
That gap does not stay open by accident; the reason is economic, not technical. A rubric specific enough to fail a real case demands the same unglamorous work an eval rubric demands anywhere else: work out the actual ways output goes wrong, write criteria a second reader would apply the same way, then demonstrate the rubric rejecting something real before trusting it on a thousand more cases. A bare “looks good?” prompt costs one line and ships today, filling the identical slot in a diagram that alone will never say which one is inside. Asked only to approve or reject, with no stated cost for a false approval and no visible reward for a caught failure, the model resolves the ambiguity the way most under-specified systems do: toward yes.
What it costs
The bill runs twice over. First is the plain cost of the step: a model call on every item, adding latency and inference cost for a check that returns the same verdict whatever it is handed. Second, and worse, is what the step buys in place of protection: verification theatre. A pipeline with a rubber-stamp verifier reads as more careful than one with no verifier at all, because the diagram implies the extra box is doing work. A missing verifier at least leaves a visible gap a reviewer might notice; a rubber-stamp verifier fills that gap with something that reads as coverage and is not.
The specific trap is what this does to the number a team actually watches. A rubber-stamp verifier does not fail loudly; it fails by making the aggregate look better than the system underneath it, because every case it waves through, right or wrong, gets recorded as a pass. The failures a real check would have caught get relabeled, silently, as successes: the dashboard reports what the verifier approved, not what the worker actually got right, leniency mislabeled as accuracy. Lab-001 measured exactly this in a single run: a headline score that looked close to competitive was, on inspection, a verifier waving through 14 percent of queries regardless of content, and the honest number, once that stopped, was seven points lower. A stricter verifier can only reveal accuracy that was already the ceiling; it cannot lower it, only stop hiding what was there.
The same failure wears a human costume. A fatigued reviewer signing off on every ticket in a queue, because disagreement takes longer to write up than agreement, runs the identical process: an approval granted regardless of input carries the same zero information whether the approver is silicon or a person at the end of a shift. Approval Gate is built, in part, against that failure, with a defined timeout in place of a default yes.
Worked example
Lab-001 set out to test something else entirely: whether a three-agent hierarchy, classifier plus worker plus verifier, beats a single-agent workflow router on short-horizon customer support queries. The rubber-stamp verifier turned up as a side finding, not the thing the experiment was built to measure: nobody went looking for it, and it was sitting inside the architecture supposed to be the more careful of the two.
The verifier agent sat at the end of the chain, checking the worker’s output against the original query before the answer returned to the customer. On the first eval pass, the system scored 81 percent against the shared rubric (0.4 correctness, 0.3 grounded, 0.3 completeness, 0.7 pass threshold), against the router’s 87 percent on the same 100 queries. A six-point gap is close enough that a team choosing between the two architectures on this number alone might call it a near-miss and back the multi-agent system anyway, on the theory that hierarchy and verification would earn back the difference once the task set got harder.
The number was measuring the wrong thing. On inspection, the verifier agent was bypassing 14 percent of queries with a “looks good to me” response regardless of content, measured directly from the run, returning approved on roughly one in seven queries no matter what the worker had produced. The fix was not a better model or a longer prompt for the worker; it was a verifier prompt carrying explicit, checkable criteria in place of an open-ended judgment call. The bypass rate fell to roughly 3 percent, and genuine accuracy came out at 74 percent, a full 7 points under what the first pass had reported. Not every bypassed query had been wrong, so the two figures do not move together; the seven points are the share now correctly caught instead of waved through as verified.
Had 81 percent gone out as the headline result, the six-point gap against the router would have read as a near-miss worth another sprint of tuning. The real gap was thirteen points, and the extra seven were never in the worker’s answers; they were sitting in a verifier that could not say no, a distinction the dashboard alone gave no way to catch before shipping.
The pattern that replaces it
Verifier Loop occupies the identical slot in the diagram, and nothing about the box’s shape tells which one you have built. What separates them sits entirely inside it: whether the check is anchored to the original task rather than whatever the previous step produced, and whether it carries a rubric specific enough to reject a real case rather than approve on an impression. Swapping one for the other is not visible from outside the system; it is a change to what the prompt inside that box is allowed to say yes to.
There is a direct test for which one is running: has this verifier ever said no, on a real input, and can someone point to the case. If the honest answer is “not that we’ve checked,” the box is decorative regardless of its documentation. Lab-001’s fix used the same base model before and after; what changed was the criteria the verifier checked against, not the model doing the checking. A rubber-stamp verifier is evidence of a missing rubric, not a weak model, and a stronger model given the same absence of criteria will rubber-stamp just as readily, because nothing written down gives it a case to fail.
The honest fix costs something a lenient prompt does not: someone has to write down what a correct answer looks like, specifically enough that a wrong one fails against it, then demonstrate that failure on a real case. That cost is exactly why the anti-pattern persists after a team already knows better: it is cheaper to leave a verifier able to approve everything than to do the work that lets it occasionally, correctly, refuse.
Related patterns
Verifier Loop is the pattern that replaces this one outright: the same slot in the pipeline, with a task anchor and a rubric that can fail a real case in place of an approval that never varies. Hallucinated Done is the louder sibling failure, skipping verification outright, where a rubber-stamp verifier runs a check and approves anyway, which is why the quieter failure survives longer before anyone notices. Failure Buckets is what actually catches this in practice: a single aggregate score cannot distinguish a verification failure from a routing or grounding failure, and only a bucketed breakdown turns a rubber-stamp rate into a line item. Approval Gate is the human analogue, a fatigued reviewer approving everything in a queue, with the identical fix: explicit criteria and a defined path for a genuine no, not a default yes dressed up as review. Baseline and Floor names the same trap from the evaluation side: a rising aggregate can hide a component sinking underneath it, a verifier quietly approving everything among them.