A checker that says 'something's wrong' is useless if you can only patch one spot — does fixing work best when the check matches the fix?

This explores what it means for a check to be the right size for the fix, and how that plays out for different kinds of things agents produce. The corpus states the principle clearly in one survey but doesn't compare artifact families side by side, so what follows is that principle plus what neighboring notes show about each kind of artifact.

The principle comes from a survey of 259 works on agentic artifact creation. Verification loops guide repair only when the feedback names failures at a scope the system's available actions can actually fix (When does verification feedback actually guide targeted artifact repair?). A verifier that says 'something is wrong somewhere' is useless to a system that can only patch one paragraph. Having a verifier at all is the wrong test. The question is whether its output has the same resolution as the repair move.

Documents show the mismatch most clearly, and the problem there is detection, not repair. Weaker models degrade documents by visibly deleting content, which a coarse check catches. Frontier models corrupt content while keeping the surface intact (Does model capability change how documents degrade?). The strongest models corrupt about 25% of content over long relay workflows, and spot checks miss it (Do frontier LLMs silently corrupt documents in long workflows?). Better tools don't fix this, because the error starts in the model's judgment about what to change, not in the editing interface (Can better tools fix LLM document editing errors?). Stronger repair machinery can't help when the checks don't look where the failures are.

Other artifact types line up scope and action differently. For reasoning traces, asynchronous verifiers fork off to pull out one verifiable piece of state and step in only on a violation. The check and the intervention are both small, so the cost is near zero (Can verifiers monitor reasoning without slowing generation down?). For retrieval, a compressed-vector check can't tell a structural near-miss from a topical match. A small verifier reading the full token-to-token similarity map can, so the check has to be finer than the recall step that came before it (Can verification separate structural near-misses from topical matches?). For runtime audits, agents get a limited remit, fixed artifacts to inspect, and a duty to cite evidence, so their semantic judgments stay bounded and arguable (Can scoped agents reliably judge semantic hacks in runtime analysis?). Code and test protection adds a wrinkle. One study bundles authorization rules with restricted tools and reports zero test modifications. Without ablations, nobody can say whether the agent couldn't cross the line or chose not to (Do authorization rules or restricted tools prevent test modifications?). That is the same scope-versus-capability question in another form.

Whole workflows are the family where the scope needed is widest, and local checks fail there. Steps can each pass plausibility, alignment, or protocol checks while the end-to-end result still fails, because those checks test different properties than system safety needs (Can individual components pass safety checks if the system still fails?). Per-action guardrails can't even state a rule that depends on history. Only stateful monitors that track sequences can (Can stateless checks ever catch sequence-level constraint violations?). Existing measures of whether errors stay visible, contained, and recoverable are fragmented, and none covers all of them (How can we measure whether AI errors stay visible and recoverable?).

The mismatch runs both ways. A check can be too coarse for the repair, as with document spot checks and vector recall, or too local for the failure, as with per-step and per-action checks on a workflow. A strong repair tool doesn't help in either case, and the check has to be matched to where the failure actually lives.