Prescriptive failure

When the system rejects, it names what to do next.

"Call assert_node_order" is something an agent can act on immediately. "Unsatisfied requirement" requires interpretation. The difference is the number of reasoning steps between error and fix.

The test: When this layer fails, does the error name the next action, or describe the problem and leave interpretation to the agent?

Evidence

• Adnan & Kuhn (Nature Scientific Reports, 2025): debugging effectiveness decays exponentially; longer error messages correlate with faster decay. Prescriptive messages are brief and actionable.
• Dai et al. (FeedbackEval, 2025): structured test feedback (61%) outperforms human explanations (50.5%). The value is in actionability, not richness.
• Our canary pilot: precision (naming what failed and what was expected) matters more than brevity for accuracy; both matter for token cost.

In practice

• sqlc: refuses to generate and shows the expected function signature.
• A file-size check that says "split handlers.go into user_handlers.go and admin_handlers.go", not "file too large".
• golangci-lint: specific remediation, not just the violation.
• This reference: a contract check.sh line names the missing file; the pipeline standard's failure names the floating ref to pin.