Find it in the documents, not the field.
Machine-speed analysis of technical specifications. Find contradictions, gaps, and duplicates before sign-off.
Find it in the documents, not the field.
Machine-speed analysis of technical specifications. Find contradictions, gaps, and duplicates before sign-off.
Wyzer Detective
Detective reads a specification the way no reviewer can, all of it at once. Contradictions, duplicates, and coverage gaps surface before sign-off, each one traced back to the requirement IDs that caused it.
Why review misses it
A reviewer reads a specification the way it was written: front to back, one requirement at a time, inside their own domain. The safety chapter comes from a different team than the performance chapter. Both can be entirely correct on their own.
A contradiction is not a property of a requirement. It is a property of a pair, and it lives in the space between two sections that no single person ever reads together. No reviewer holds a whole specification in working memory at once.
The Sherlock engine evaluates all of them, across every section boundary, in a single pass. Human review, however expert, cannot. Not for want of rigour, but because the defect sits nowhere a linear read passes through.
Each layer targets a distinct class of specification defect. Together they cover the full range of issues that generate change requests, integration failures, and audit findings. Specification errors caught before sign-off cost a fraction of what they cost at integration. The same finding on a 1,000-requirement document takes minutes to surface. On a manual review, it may never surface at all.
Every requirement scored 0–10 on six axes: Ambiguity, Measurability, Conciseness, and Completeness, plus conformance to INCOSE and EARS writing rules. Each low score comes with the specific issue and a rewrite suggestion so your team knows exactly what to fix.
A vague requirement is a blank cheque for a supplier to interpret however suits them.
Three classes of conflict: logical negation, numeric constraint, and semantic contradictions, all ranked by severity. The class of finding that only surfaces during integration testing and generates expensive change requests.
Zero false positives on clean specifications: precision is the primary design goal.
Semantically redundant requirements clustered and ranked by similarity, even when written in entirely different vocabulary. Left undetected, duplicates create conflicting contractual obligations when vendors interpret them differently.
The Sherlock engine understands meaning, not just words.
Requirements classified across functional, performance, safety, security, reliability, and compliance domains. Shows exactly where coverage is thin or absent relative to project scope, before contract signing rather than after an audit fails.
A specification that looks complete may still be systematically missing an entire domain.
Requirements checked against established industry standards, and against the ASPICE gate review itself: run Wyzer before the formal review and the same gaps surface on your terms, not the assessor's. Built-in reference-standard coverage is expanding, with ISO 26262 and ASPICE on the roadmap.
Large-scale compliance analysis beyond what manual review can achieve.
Upload a reference document, a standard, an internal template, a prior baseline, or a competitor's public spec, and Wyzer compares your requirement set against it line by line. Each requirement comes back marked under-specified, on par, or ahead of that reference.
Not limited to Wyzer's built-in standards. Benchmark against whatever reference document matters to your programme.
Requirements clustered by semantic similarity into neighbourhoods of related content. Every explicit cross-reference appears as a definitive edge. Navigate the full blast radius of any proposed change before making it.
Understand dependencies and risk concentrations across your entire specification.
Diagrams, tables, and images analysed alongside written requirements to surface mismatches between what the document says and what the visuals imply. Every discrepancy mapped back to the affected requirement IDs.
Written and visual artefacts are often authored separately and drift apart over time.
Not a feature list. A set of reasons why the problem required a new approach.
Existing tools enforce structure: mandatory fields, ID format, attribute completeness. They tell you whether a requirement exists. They cannot tell you whether it is any good. Wyzer Detective analyses what’s in your databases.
Our engine uses deterministic methods to resolve issues and attach a confidence score and reason to every finding. Results are reproducible run to run, making them suitable as a quality gate.
A 1,000-requirement document creates roughly one million possible comparisons. Wyzer Detective eliminates impossible pairs before any AI is involved, reducing the candidate set by orders of magnitude.
Export from IBM DOORS, Polarion, Jama, or Codebeamer, then upload the ReqIF file and findings are returned within minutes. Same day value, no infrastructure changes. Do the pipeline integration when you are ready to scale.
Questions from engineering teams, procurement leads, and programme managers.
From our engineering blog
A requirement can be correctly traced to its parent and still fail an assessment, because nothing checked whether the parent itself was sound. The difference between a trace that exists and a trace that is true.
An AI-generated requirement can be fluent, well structured, and completely wrong, and still pass a skim-level review before sign-off. Where accountability for that output actually lands.
Language understanding alone produces too many false positives to serve as an engineering quality gate. Why precision at scale needs deterministic validation and structured evidence behind every finding.
Upload your first ReqIF file and the Sherlock engine returns findings within minutes. Same day, no integration required.