Three kinds of contradiction, and why more reviewers find fewer of them

Photo by Ivan S on Pexels

Reading is linear. Contradictions aren't.

That is the whole problem, and everything below is either evidence for it or a consequence of it.

A specification can pass every review it is given and still carry its worst defects into the supplier contract. The benchmark data says so: formal requirements inspections, the most rigorous form of review anyone has measured, remove 78% of requirements defects on average, the weakest figure of any formal inspection type. And the survivors are not a random sample. They are concentrated in the one defect class a review cannot structurally reach, because a contradiction does not live inside a requirement. It lives across a set of them, sometimes two and often more, and no member shows a symptom on its own page.

WYZER Detective exists for that remainder. Rather than moving through the document, it evaluates requirements against the whole of the specification and against each other, across every section boundary, and returns the conflicting groups ranked by severity.

The multiplier everyone quotes, and what it actually says

Every article about requirements quality eventually reaches for the cost-of-change curve: 1× in requirements, 10× in design, 100× in the field. You have seen the pyramid slide. So have I. Part of it does not survive contact with its footnotes: Laurent Bossavit chased the citations through The Leprechauns of Software Engineering and found the most-quoted 1:10:100 version traces to an "IBM Systems Sciences Institute" study nobody has been able to produce, the trail ending at internal course notes in a textbook with no data set behind them.

But the question did get studied properly. NASA's Johnson Space Center ran Error Cost Escalation Through the Project Life Cycle using three independent methods on systems comparable to a large spacecraft. The endpoints of their Table 13:

The software column is their synthesis of prior literature, which by their own Table 1 includes Boehm 1981 and most of the lineage Bossavit objects to. The systems column is NASA's own measurement, and it runs from 29× to more than 1615×: a fifty-fold spread inside a single study, because some of those defects were in a satellite nobody could service once it launched.

So the problem with "100×" was never that the figure is too high or too low. One tidy multiplier is the wrong instrument for a quantity that varies fifty-fold depending on what broke and whether you can still reach it. Anyone quoting a single clean number picked a point out of that range, and picked it to suit their slide.

A worked example, from our own homepage

So let me read our own marketing the way we read a specification.

Until recently our homepage carried these two statistics, side by side in a bar of four:

29× Cheaper to catch conflicts before you sign

100× Cost increase when defects reach production

The 29× is ours, out of our own work. The 100× is the NASA figure above. They measure different intervals: one is the saving from catching a conflict before contract signature, the other is escalation from the requirements phase through to operations. Two quantities, two baselines, two accurate numbers.

Neither label stated which interval it covered. So read the way a visitor reads a stat bar, four numbers in one glance under one implied subject, and they resolve into two answers to a single question, three and a half times apart. Nothing on the page was inaccurate. The scope that reconciles the two was never written down.

Classified properly, that is a numeric scope conflict: the quietest form of the second class below, and the most common one in real specifications. It is also the exact pattern in our own product demo, where one requirement bounds latency at 200 ms "under nominal load" and another bounds response time at 500 ms "in all conditions". Two defensible numbers, two unreconciled scopes, and the second silently broadens the first. We put that on the site because it is the canonical case, then committed it ourselves.

The fix took one line each. The labels now name both ends: cheaper before signature than after, and cost increase from requirements to operations.

What I want you to take from it is not that we were careless. We wrote those four claims and reviewed them. The page then went through a redesign, an SEO pass, and a claims audit hunting specifically for unsupported statements — and every claim passed every review, correctly, because each statement was true, sourced and well-formed. The audit did what audits do, examined each claim on its merits, and was right every time. The defect was never in a statement, so no process that examines statements was ever going to find it.

Four claims, one glance apart, in a document we control completely and care about more than any of your suppliers cares about yours.

Now extrapolate to four thousand requirements, nine teams, two years.

What the measured data says about requirements defects

The best public numbers come from Capers Jones, who spent four decades collecting defect data across thousands of projects. Two findings from Software Defect Removal Efficiency (2011) matter here.

The first is that requirements defects are the hardest to remove. Coding defects are caught at 95% efficiency; requirements defects at 77%, the lowest of any origin he tracks. Read as a miss rate it is sharper: 5% of coding defects reach delivery, and 23% of requirements defects do. There is a counterintuitive consequence. Requirements have the lowest defect potential in his data, 1.00 per function point against coding's 1.75, and the highest delivered defect count, 0.23 against 0.09. Requirements are the smallest source of defects in a programme and the largest source of the defects that ship.

The second is his ranking of pre-test removal methods:

Formal requirement inspections, run with a moderator, a checklist, a reader and prepared participants, average 78% and top out at 90%. Almost nobody runs them that way; the discipline survives until roughly the first schedule crunch and then quietly becomes a meeting. So 90% is close to hypothetical. The reviews that actually happen leave one defect in five, and one in five is the honest planning figure. If what your programme holds is a peer review rather than a moderated inspection, Jones puts that class at 50%, or one in two, though that row is not requirements-specific, so treat it as an indication.

One caveat: Jones measured software projects in function points, not automotive specifications in requirements, and the mapping is not clean.

A contradiction has no local symptoms

Why is requirements review the weakest of the formal inspection types? Not because requirements engineers are worse at their jobs than the people inspecting code. Because of what they are being asked to look at.

A requirement can be reviewed alone. You read it and you can tell whether it is clear, whether it is testable, whether it uses a term someone defined. Ambiguity is visible in a single line, which is why ambiguity is the defect class reviews are good at.

A contradiction is a property of a set of requirements, not of any member. Every one of them can be individually excellent: well-formed, measurable, traceable, signed off by a domain expert who was right. The defect exists only in the relationship between them. Two is the smallest and tidiest case, so the examples below use two; the timing budget further down needs four.

And specifications are assembled the way organisations are shaped. Functional safety writes the safety chapter, the systems group writes performance, whoever owns the bus architecture writes communication. Each section is approved by people who know that domain, and the conflict sits in the seam between two chapters no one person is responsible for reading together.

That is the geometry of the document, not a process failure better discipline corrects.

Logical conflicts survive because the vocabulary drifts

One requirement says the system shall enter degraded mode on sensor timeout. Another says the system shall maintain full functionality when a sensor is unavailable.

Side by side, two seconds. In a real specification they are four hundred pages apart, written eight months apart, and one says "unavailable" while the other says "timeout", which may or may not be the same condition, depending on a definition three chapters earlier that both authors read differently.

The reviewer working through the second requirement has no reason to think about the first. It was fine when they read it.

Numeric conflicts survive because every number is defensible

Our stat bar was the mild version of this. Here is the version that costs money.

A timing budget gets allocated across subsystems. Sensor acquisition: 40 ms. Processing: 50 ms. Bus response: 100 ms. And the end-to-end latency requirement, written by a different team against an assumption true at the time: 120 ms.

Not one of those numbers is wrong. Each was derived carefully by someone who could defend it in a review, and each one did get defended. The conflict is arithmetic nobody performed, because performing it means holding four requirements from four sections in mind at once and knowing that they compose.

This is also the class that most clearly refuses to be pairwise. No two of those four requirements contradict each other; compare any two and you find nothing. The defect appears only when you take three together and add the fourth. So a reviewer hunting conflicting pairs signs this off, and so does a tool that only looks for conflicting pairs.

It passes every structural check your requirements management tool applies, too: ID, owner, complete attributes, downstream link to a test case. Well-formed, fully traceable, wrong in combination, because a traced requirement can still be wrong, and a trace says nothing about whether the thing at the other end agrees with anything else in the document.

Semantic conflicts survive because both parties are right

The third class shares no term and no number.

Diagnostic data is retained until the next service interval, says the diagnostics section. Vehicle-identifiable data is purged at ignition-off, says the privacy section. Whether these conflict depends on whether diagnostic data is vehicle-identifiable, a question neither author asked, because from inside either section the requirement is unambiguous.

This is the class that becomes a commercial dispute rather than a bug. The supplier implemented one of them; the other is also in the contract. Both parties point at a signed document and both are correct, which is the worst position a programme can occupy eighteen months before start of production. I have watched that conversation more than once. Nobody in the room is wrong. Everybody in the room is angry.

Why adding reviewers moves the number the wrong way

The instinctive fix for a review that misses things is more reviewers. This is where the arithmetic turns.

Reviewers add reading capacity linearly. One person reads a thousand requirements; four people read two hundred and fifty each. The space where contradictions live does not scale that way. A thousand requirements produce roughly a million possible comparisons, ten thousand produce roughly a hundred million, and that is only counting two at a time. Quadrupling the team quarters the reading time and does approximately nothing to the space that matters.

The sharper problem is how the split is made. Assigning each reviewer the section closest to their expertise is correct for judging whether a requirement is any good, and it is why domain-split reviews find ambiguity well. It is precisely wrong for finding conflicts between sections. The more cleanly you divide a review by domain, the more completely the cross-domain combinations fall outside anyone's field of view.

Which means the 78% is not evenly distributed. Ambiguity and incompleteness are what a good review is finding. The cross-domain contradictions are disproportionately in the remainder, because the structure that maximises the first suppresses the second.

This is also where the organisational cost comes from. When no individual can hold the whole specification, the only way to reach a decision that spans sections is to put everyone who owns a piece of it in the same room, which is the mechanism behind why European OEMs need committees to make decisions Chinese OEMs make alone.

What that costs, in units that mean something

I am not going to hand you a euro figure for a missed contradiction. I would have to invent it, and you would be right to discount it.

The NASA range points at a better way to think about it anyway. The reason their operations figure spans fifty-fold is that the cost of a late defect is dominated by one question: can you still reach the thing?

Automotive has a clean version. Delivering a 1 GB fix over the air runs about $66.50 per vehicle; a defect that cannot be fixed over the air costs roughly $500 per vehicle to recall, per Perforce's 2026 automotive software report. Software defects put over 13 million vehicles into US recalls in 2024 alone. Multiply either figure by a production run and you have a number tied to an actual event, which beats a pyramid because nobody has to trust the arithmetic. They can check it.

The far end of that range is not hypothetical here either. Volkswagen's Cariad posted a €2.431 billion operating loss in 2024, and the Macan Electric and Q6 e-tron each slipped about a year on software. What caused what inside those programmes is not mine to say, and everyone in this industry has their own version of the story.

The question to ask at the next gate

None of this replaces the review. Deciding whether the 120 ms figure or the 100 ms figure is correct is an engineering judgement, and it belongs to someone who understands the system. Nothing automates that, and nothing should. What can be automated is the part that is not judgement at all: noticing that the two numbers are in the same document and cannot both hold.

In WYZER's own validated runs against specifications running into the thousands of requirements, including complex tables and embedded images, roughly 12.8% of requirements came back flagged as duplicate candidates, with no false conflicts raised on a clean specification. Where genuine conflicts existed, the Sherlock engine isolated the directly-conflicting high-risk pairs, around 2% of the requirement set, from the surrounding low-risk overlap. That second number is the operationally important one: a tool that returns every semantically adjacent candidate hands a review team a list longer than the specification, and they learn to ignore it by the second baseline. Precision at that level is not something a language model delivers on its own, which is why hybrid approaches outperform AI alone. Worth knowing before you evaluate anyone's numbers, since every tool in this category shares a dependency on a foundation model it does not control.

And the edge of that evidence, because precision is the whole argument here: those figures cover directly-conflicting requirements. The composed case, the timing budget where no two requirements disagree and four of them do, is harder, and it is where the interesting work is. Anyone who tells you their tool has closed that gap is selling you the pyramid slide again.

So here is the change I would make to your next quality gate, and it costs nothing to try. Stop asking whether the specification has been reviewed. Ask which requirements were compared against which, across which section boundary, and by whom. Most programmes have never been asked, and the answer is almost always the same: the document was read the way it was written. Front to back. One requirement at a time.

The contradictions were never on that path.