Find it in the documents, not the field.
Machine-speed analysis of technical specifications. Find contradictions, gaps, and duplicates before sign-off.
The Analysis Engine
Not a wrapper on a generic LLM. Paste a 2,000-requirement spec into a chat window and a general-purpose model loses track of what's buried in the middle, returning a different answer twice in a row. Sherlock is a purpose-built analysis engine, trained specifically to interpret engineering requirements and designed from the ground up for accuracy, consistency, and trust. The hybrid AI and rule-based architecture means every finding is traceable, reproducible, and explainable.

From upload to findings in minutes. No integration, no training data, no configuration.
A 1,000-requirement document creates roughly one million possible pairwise comparisons. A generic LLM cannot process all of them: it loses context, skips pairs, and produces inconsistent results run to run.
Sherlock uses semantic similarity to eliminate pairs that cannot conflict before any AI is involved, reducing the candidate set by orders of magnitude and making the analysis tractable at any scale, consistently.
Sherlock's integration interface is ReqIF, the OMG-standard Requirements Interchange Format, parsed directly into a structured requirement graph with no manual tagging required.
Each requirement is scored across six quality axes: Ambiguity, Measurability, Conciseness, and Completeness, plus conformance to INCOSE and EARS writing rules. The requirement graph is then interrogated for logical, numeric, and semantic contradictions between requirements.
Sherlock maps your requirement set against domain models for functional, safety, compliance, and security coverage. Gaps are identified, ranked by severity, and linked to the specific area of the specification they affect.
Findings are returned as a structured, navigable report: each issue with a severity rating, a plain-language description, and a suggested rewrite. The same run on the same input always produces the same output.
On a validated 288-requirement specification, Sherlock returned zero false conflicts on a clean document and isolated every genuinely conflicting pair when real contradictions were present. The engine has been run on specifications from a few hundred requirements to over 10,000, with no change in output quality at scale. Findings are auditable: every contradiction maps to the specific requirement IDs involved, the type of conflict (logical negation, numeric constraint, semantic), and the severity rank.
Sherlock also analyses diagrams and tables alongside written requirements. If a diagram shows one interface and a requirement specifies a different one, the mismatch is surfaced with the requirement ID and the visual artefact reference. Text-only review cannot catch this class of defect.
Full support for the ReqIF standard ↗ means no format guesswork on either side of the exchange. If your specifications live in Markdown, Excel, Word, or PDF instead, Wyzer partners with specification-standardization providers who convert them into clean ReqIF input first.
Sherlock runs on the requirement set you already maintain in your requirements management system, not instead of it. See how it fits alongside DOORS Next, Jama Connect, Codebeamer, or Polarion.
Every requirement is scored 0–10 across six axes: four judged by the model, two computed deterministically against public writing standards. Each score comes with the specific issues found and a rewrite suggestion.
Identifies vague qualifiers, undefined terms, and language that allows multiple valid interpretations.
Flags requirements that cannot be verified because they lack quantifiable acceptance criteria.
Detects compound requirements, redundant phrasing, and over-specified constraints that reduce clarity.
Checks that each requirement is self-contained: no dangling references, undefined inputs, or missing context.
A deterministic, rule-based check, distinct from the four LLM-judged axes above, checking each requirement against well-known ambiguity and weak-language patterns from the INCOSE Guide for Writing Requirements.
Also computed deterministically: checks whether the requirement matches one of the canonical EARS templates. A statement that doesn't follow EARS at all is excluded from this axis rather than penalised for it.
Designed from the ground up for engineering rigour, not a general-purpose AI wrapper.
Sherlock combines large language model analysis with a deterministic rule layer. The LLM handles semantic understanding; the rule layer validates logical and numeric consistency. Every finding is traceable to a specific check, an ambiguous term, a missing threshold, a conflicting requirement ID.
A quality gate that produces different results run to run is not a quality gate. Sherlock's deterministic layer is what keeps the same input producing the same findings, which is what makes it usable for audits, supplier reviews, and gate reviews.
Every issue comes with a plain-language description of what was found, why it matters, and a specific rewrite suggestion. Sherlock does not produce unexplained scores. Every number has a reason behind it.
Sherlock only reports on what is present in your specification. It does not generate new requirements or infer missing content beyond what the coverage model can confirm, which keeps noise down and engineering trust intact.
From our engineering blog
Why Sherlock pairs language understanding with a deterministic layer instead of relying on a model alone, and what that costs in false positives when a tool skips the second half.
The architectural case for a hybrid approach rather than a single model. What that means for reproducibility when the same specification is analysed six months apart.
An AI-generated requirement can be fluent, well structured, and completely wrong, and still pass a skim-level review. Why a finding needs a reason attached before anyone can sign off on it.
Upload a ReqIF file and receive a full Sherlock analysis within minutes: quality scores, contradictions, and coverage gaps.
← Back to product overview