When the Requirement Itself Is Wrong, Who Notices?

Someone files a ticket: a field is displaying incorrectly and should be changed. An agent implements it faithfully. Tests pass, review confirms it matches the ticket, it ships.

The field was correct. The behavior was intentional, decided two years ago for a reason documented in a place nobody looked. The ticket was wrong, and every stage of a well-functioning process faithfully executed it.

The check that used to be implicit

Human engineers reject requirements regularly, and usually so informally that it doesn't register as a process step:

• "Wait — isn't that deliberate?"
• "That'll break the export."
• "The reason it works that way is the finance team needs it."
• "This contradicts what we agreed last month."

None of that appears in a workflow diagram. It happens because someone with context reads a request and something doesn't fit. Remove that person from the path and the check disappears with them — silently, because nothing was ever recorded as happening.

Why agents are especially poor at it

Premise acceptance is the default. A model given a framing works within it. Told a behavior is a bug, it treats it as a bug and looks for the cause — and it will find one, because most behavior has a cause that can be described as a defect if you're looking for one.

The contradicting evidence is scattered. The reason the behavior is correct lives in a comment, an old decision doc, a Slack thread, or nobody's notes. It isn't in the diff, which is where attention goes.

Everything downstream reinforces the error. Tests are written to the new requirement. Review checks the change against the ticket. Each verification confirms compliance with the wrong thing, and the volume of passing checks reads as confidence.

⚠️ This is the specification-error problem in its most concrete form, and it's invisible to every automated check by construction — because those checks all measure against the specification.

What restores the check

Attach the original request, not just the ticket, to every stage. A ticket is a lossy encoding; the original words sometimes contain the tell that the reporter had a wrong premise.

Have the agent look for prior intent before implementing. A cheap step with a real hit rate: search for the behavior in comments, decision records, tests that assert it, and recent changes touching it. Assert it explicitly:

Before changing behavior, check whether it is intentional.
Report: any comment, test, or decision record indicating the current
behavior is deliberate. If found, escalate rather than change it.

A test asserting the current behavior is the strongest signal available, and it's mechanically findable. ✅ A change that deletes or inverts an existing assertion should never proceed unexamined — that's a machine-checkable rule catching a large share of these.

Make "the premise looks wrong" an available output. As with any escalation, it has to be a legitimate, rewarded move or it won't happen. dispute_requirement(reason, evidence) costs nothing to add.

Keep decisions where they'll be found. The reason lived somewhere nobody looked. Decision records adjacent to the code — a comment on the behavior itself saying why, not what — are the version that gets found by both humans and agents.

💡 The related failure: the requirement that's right and incomplete

A softer version, and more common. The requirement is correct as far as it goes and omits a case: what happens to existing records, what the API consumers see, what the migration does.

Humans catch this by knowing the system. The mitigation is the same shape — have the agent enumerate affected surfaces before implementing, and report which ones the requirement doesn't address. That list is exactly what a knowledgeable engineer produces in their head, made explicit.

🔍 Measuring it

Sample delivered work and ask the requester: did this do what you wanted? Not "is it correct" — correctness against the spec is what every existing check measures.

The gap between "correct" and "what was wanted" is where these live, and nothing in an automated pipeline can see it. Sampling is the only instrument, which means it has to be scheduled rather than intended.

The takeaway

Engineers reject wrong requirements constantly, informally, and invisibly — and that check leaves the process along with them. Restore it deliberately: search for prior intent before changing behavior, treat a deleted assertion as a stop condition, make disputing the premise a first-class output, and put the why next to the code where it will be found. Then sample against intent rather than against spec, because that's the only place this failure is visible.