Find it in the files, not the field.
Machine-speed analysis of technical specifications. Find contradictions, gaps, and duplicates before sign-off.
Find it in the files, not the field.
Machine-speed analysis of technical specifications. Find contradictions, gaps, and duplicates before sign-off.
Automotive requirements & specification analysis
Specifications for ADAS, powertrain and body-control software now run to tens of thousands of requirements, written by different systems teams on different suppliers' schedules. Wyzer Detective is the automotive requirements checker that reads all of it at once, cross-referencing every requirement against every other. That last part is what a section-by-section review structurally cannot do, however careful its reviewers are.
Every programme below is publicly reported, at costs its owner disclosed. Reporting on them keeps returning to the same root cause.
CARIAD delayed the Porsche Macan Electric and Audi Q6 e-tron launches by roughly a year, then Volkswagen paid Rivian $5.8B for the EV software platform CARIAD couldn't deliver. Reporting on the failure keeps landing on the same root cause: software specifications authored independently across VW, Audi, and Porsche that were never reconciled before integration.5
Ford's FNV4 electrical architecture, meant to unify vehicle software the way Tesla's does, was cancelled after contributing to billions in losses at Ford's EV and software division. Ford's own explanation: every supplier that builds a component also supplies its own software for it, and nobody was checking those supplier-authored specifications against each other before they shipped.6
A software-related defect triggered a 1.46-million-vehicle Ram truck recall, on top of a separate recall of 211,581 trucks and SUVs where a software fault disabled electronic stability control after an ABS defect. Cumulative Stellantis recall costs have run to roughly $951M since 2023, the bill a cross-supplier specification conflict generates once it reaches the field instead of a review.7
Both figures below come from published specifications anyone can go and read: the VIWI infotainment protocol, submitted to the W3C, and Eclipse S-CORE, the Apache-2.0 licensed safety platform. Nothing here is a synthetic example.
Applied to the automotive requirements you already write, in the review step you already run.
The body-control and powertrain sections can each read correctly on their own and still specify incompatible behaviour for the same signal. Wyzer reads the specification as one document rather than one section at a time, and flags where the two disagree.
Coverage analysis against the work products an ASPICE assessment expects, so requirements with no downstream test case or design element surface before an assessor reaches them.
Flags safety requirements that are present but under-specified: no measurable acceptance value, no stated tolerance, no clear safe state. That is the ambiguity a functional safety assessment rejects.
When a Tier 1 baseline is re-issued, Wyzer diffs it against the OEM master specification for new contradictions introduced in that revision, not just what changed.
Wyzer Detective doesn’t replace the process. It checks the requirement set the process depends on.
A 30,000-requirement ADAS specification, split across twelve supplier-facing modules written by different systems teams. No single reviewer reads all twelve end to end before sign-off. Two modules define the same sensor-degradation fallback behaviour, worded differently enough that neither review recognises them as one requirement. Integration testing finds it instead, once both implementations exist and disagree. Wyzer Detective reads the whole baseline in one pass, so that conflict surfaces while it is still a review comment.
The example above illustrates the class of defect Wyzer Detective catches. It is not a specific customer engagement.
Yes. Wyzer checks requirement coverage against the work products an ASPICE assessment expects and flags requirements with no traceable downstream element.
Yes, via ReqIF, the same interchange format both tools already export. No migration off your system of record.
Same day. Export a ReqIF baseline, upload it, and Sherlock returns quality scores, contradictions, and coverage gaps within minutes. No configuration, no training data, no integration project.
No. Customer data is not used to train the system and is not exposed to other customers or external models. Data is encrypted at rest.
In the EU. Wyzer's infrastructure runs in an EU region, isolated to your environment, with standard retention capped at 90 days by default.
No practical one. Sherlock has been tested to tens of thousands of requirements with no degradation in output quality: it processes specifications in parallel batches rather than reading them end to end.
No. Reviewers keep working in the requirements tool they already use. Wyzer Detective runs before or alongside the existing review, and relevant findings get applied back into that review. It's a quality-gate step, not a new system to adopt.
Credit-based pricing that scales with the number of requirements in your specification and how complex they are (plain text vs. requirements with tables or diagrams). There's no fixed per-seat licence. Get in touch for a quote sized to your specification. Searching a finished analysis with a defect or failure description (the Requirement Scan API, in beta) costs one credit per query, whatever the size of the specification.
Yes. Any ReqIF export works as the reference: a published standard, an internal template, last year's baseline, whatever you want the current spec measured against. The comparison runs requirement by requirement, not as a single aggregate score, so you can see exactly which ones fall short.
Export a ReqIF baseline and get a full Wyzer Detective analysis within minutes: quality scores, contradictions, and coverage gaps.
← Back to all industries