Simple, fast UI
Built for review, not data entry. Keyboard-first navigation, bulk actions, queues that surface what needs your attention.
Reads every spec.Surfaces every gap.
Requirements Manager extracts requirements from raw specifications and classifies every one at domain-expert level. The kickstart to the product lifecycle.
Lifecycle start
Spec
Build
Verify
Built for engineers who need decisions, not dashboards.
Explainable classification
Each classification ships with plain-language reasoning, citing the prior requirements behind every decision.
One-click traceability
Jump from any requirement back to its source document, page and section. No hunting through PDFs.
Works out of the box
No setup needed to start extracting. Configure ontology mappings later, only if you need them.
Reads any spec
ReqIF, Word, PDF, Excel. Structured or unstructured, no preprocessing required.
Export to spreadsheet
Move classified requirements into PLM, ALM, or a plain spreadsheet for downstream teams.
Product history
Reuse what your organization already knows.
Compare thousands of incoming requirements against prior programs. SPREAD separates what is covered, what is new, what is only partial and what conflicts with known engineering reality.
Accuracy
Measured against experts, not against an imagined truth.
Classifying a requirement as covered, partial, conflicting or new is subjective work. Senior engineers disagree on borderline cases, especially the line between partial and conflicting. So we measure SPREAD against expert agreement itself, the real human ceiling for this task.
Expert-level parityQuadratic-weighted κ
κ0.72
SPREAD agrees with domain experts as often as experts agree with each other. We measure parity, not absolute accuracy, because subjective boundaries cannot be checked against an imagined single truth.
Expert vs expertInter-rater agreement, 3 senior engineers
κ 0.7195% CI 0.68 to 0.74
SPREAD vs expertModel agreement with adjudicated consensus
κ 0.7295% CI 0.69 to 0.75
Stratified benchmark across automotive safety, performance and interface domains. Expert labels adjudicated to consensus.
Disagreement, mappedConfusion matrix
SPREAD only disagrees where experts also disagree.
The boundary between partial and conflicting is genuinely ambiguous. SPREAD surfaces those cases for review with calibrated confidence instead of pretending the boundary is clean.
Covered
Partial
Conflicting
New
Covered
94%
4%
1%
1%
Partial
5%
78%
13%
4%
Conflicting
2%
14%
75%
9%
New
1%
4%
6%
89%
Ontology connected
Every requirement joins your engineering ontology.
Instead of another isolated spreadsheet row, each requirement is attached to your engineering data: affected systems, implemented functions, variants, standards, tests and previous programs.
Connected contextFunction · Component · Test · Standard · Variant
How it works
From messy spec to connected engineering data.
Reads every source
Ingests PDFs, RfQs, standards and specification documents with no manual cleanup or preprocessing.
Structures the intent
Extracts requirement candidates, classifies engineering meaning and preserves source traceability for review.
Connects the ontology
Attaches every requirement to your engineering ontology: functions, components, tests, variants and prior programs.
Surfaces the comparison
Marks each requirement as covered, partial, conflicting or new, so engineers decide before architecture and delivery work inherit the risk.
Get started
Start with better requirements.Move faster from day one.
Book a 20-minute walkthrough. We will map a real requirements workflow and show where SPREAD connects to your product ontology.