The Requirement Collision: Why SDV Complexity Demands a New Kind of Detective
Weak foundations create invisible cost that only becomes obvious when it is too late to avoid. Software does not infer intent. It executes instructions exactly as written, even when those instructions are incomplete or contradictory. And despite dramatic advances in validation capability, modern vehicle programmes still discover critical issues late. Deterministic analysis allows ambiguity, duplication, and conflict to be surfaced early, while intent can still be clarified and changes are still cheap.
From Clay to Code (Part 4)
The Requirement Collision: Why SDV Complexity Demands a New Kind of Detective
In From Clay to Code, we explored how weak foundations create invisible cost that only becomes obvious when it is too late to avoid.
In Software Is Obedient, Not Psychic, we showed that software does not infer intent. It implements instructions exactly as written, even when those instructions are incomplete or contradictory.
And in When Simulation Runs Faster Than Understanding, we highlighted a growing paradox in modern vehicle development. Validation capability has accelerated dramatically, yet late discovery of issues remains stubbornly common.
This fourth piece closes the loop.
Because if foundations matter, software is literal, and simulation is obedient, then one question becomes unavoidable:
Where is the failure actually hiding?
The Failure Mode We Keep Missing
Across programmes, architectures, and organisations, the same pattern keeps repeating.
Vehicles pass simulation gates. Software integrates. Test coverage looks strong.
Yet late in the programme, sometimes even after launch, behaviour appears that nobody explicitly intended.
When teams trace these issues back, the root cause is rarely code quality or tooling. More often, it sits much further upstream.
In the requirements themselves.
More specifically, in what we now recognise as requirement collisions.
What Is a Requirement Collision?
A requirement collision occurs when two or more requirements that are individually valid create unintended or conflicting behaviour when combined.
This typically shows up through:
- Duplication that later diverges
- Ambiguity interpreted differently across teams
- Timing mismatches between interacting functions
- Requirement intent drifting as specifications are reused or consolidated
Each requirement looks reasonable in isolation. The failure only emerges once they are brought together inside a shared system.
This is why collisions routinely evade traditional reviews.
A Familiar Pattern
Consider a simplified but common safety-critical scenario.
One team defines a requirement stating that driver assistance features must gracefully degrade under fault conditions, prioritising availability and continuity of control. Another team defines a functional safety requirement stating that, under specific diagnostic faults, certain control functions must immediately transition to a safe state.
Both requirements are correct. Both are compliant with their respective standards. Both pass domain-level reviews.
Individually, there is no issue.
The collision only emerges once these requirements are integrated onto a shared software and hardware platform. Under a narrow set of timing and fault conditions, the system oscillates between degradation and shutdown. Neither behaviour is strictly wrong on its own, but together they create an unstable and unintended outcome.
Simulation passes, because each requirement is validated against its own fault scenarios. The conflicting interaction is never exercised as a combined case. The issue is only discovered late during integration testing, or worse, through intermittent behaviour observed in controlled fleet trials.
At that point, teams are forced to reconstruct intent from behaviour, under time pressure, with safety sign-off already looming.
What makes this particularly dangerous is that, on paper, both requirements remain compliant. The risk only becomes visible when regulators, assessors, or incident investigations ask not whether each requirement was satisfied, but whether the system behaved safely and consistently under real operating conditions.
The problem did not originate in software. It originated where safety intent was never reconciled across requirements.
Software behaved exactly as instructed. The problem was not obedience, it was that the instructions were never reconciled.
Why This Is Not “Just Another Integration Issue”
Integration is where the problem becomes visible. The collision is where the problem originates.
The moment requirements are written and combined, the collision already exists. It simply remains latent until software integration, simulation, or real-world use forces those requirements to interact.
By the time the issue is discovered, the cost curve has already turned sharply upward.
This is not a failure of diligence. It is a failure of scale.
The Scale Problem No One Owns
Modern SDV programmes routinely manage tens of thousands of requirements authored across multiple domains, suppliers, and organisations.
To ensure consistency, each requirement would need to be evaluated not only on its own, but against every other requirement it interacts with. That is not a linear task. It is combinatorial.
At that scale:
- No single engineer holds full system context
- Each team assumes conflicts will be resolved downstream
- Suppliers build to specification, even when intent is unclear
- Test and validation teams are left to infer behaviour after the fact
The result is not negligence.
It is cognitive infeasibility.
Legacy Complexity and the Clean-Sheet Illusion
Established OEMs carry decades of accumulated intent. Requirements are reused because they once worked, not because they have been revalidated in a new architectural context.
Clean-sheet programmes delay this problem, but they do not escape it. Complexity always returns. It simply arrives later.
The real differentiator is not age or architecture. It is whether intent is preserved as systems evolve.
Why Simulation Cannot Catch This
Simulation is essential. It is also obedient.
It validates behaviour against scenarios derived from the same specifications that may already contain contradictions or gaps. Conflicting requirements can both pass simulation if they are never exercised together.
Simulation confirms what was tested. It does not reveal what was never defined.
This is how programmes accumulate quality debt while appearing healthy.
The Missing Phase: Detection Before Validation
What has been missing is a phase between writing requirements and validating behaviour.
A phase focused not on proving correctness, but on exposing inconsistency.
One that asks:
- Where do requirements overlap or contradict?
- Where is intent underspecified or drifting?
- Where will interactions emerge that nobody has explicitly reasoned about?
This is detective work.
Not to replace engineering judgement, but to give it leverage.
Why We Built WYZER Detective
WYZER Detective was not created to generate requirements or automate decisions.
It exists because manual methods cannot scale to detect requirement collisions in modern SDV programmes.
Deterministic analysis allows ambiguity, duplication, and conflict to be surfaced early, while intent can still be clarified and changes are still cheap.
The system does not decide. People do.
But it gives experienced engineers something they rarely have at scale: evidence.
Closing the Loop
Late issues are not surprises. They are signals.
And most of those signals originate far earlier than we are comfortable admitting.
If we want to deliver quality vehicles faster, with less rework and fewer downstream fixes, we need to stop building the wrong things more efficiently.
We need to ensure the foundation is collision-free.
That is the next step in the From Clay to Code journey.
Not more simulation. Not more process.
Better understanding, earlier.
If this pattern feels familiar, and you are seeing late-stage issues that trace back to unclear or conflicting specifications, we built WYZER Detective to help teams surface those collisions early, while intent can still be clarified. You can learn more, or simply explore the thinking behind it, at wyzer.it.
