Every requirement traced to the clause it came from. Bidirectional. Versioned. Intact.
A governing document states what a system must do in prose. Building that system means turning the prose into specification lines a team can implement and test cases that prove each one, then keeping the link between them intact every time the document is revised.
- Traceability
- Both directions
- Clause to specification line to test case
- Change control
- Versioned
- A revision reopens what it reaches
- Outputs
- Requirements, spec, tests
- And a traceability matrix linking all three
- Scope
- Fixed
- Acceptance criteria written before build
Today
Five places the work is currently manual
Scroll the diagram sideways
- Obligation extraction
- Reading a governing document and deciding which sentences carry an obligation, which restate one already made, and which are context. Everything downstream traces back to that list, so an omission here is invisible later.
- Specification drafting
- Turning each obligation into a statement a team can build against: one requirement, one testable assertion, and no compound sentence hiding a second requirement inside the first.
- Test case derivation
- Deciding what would demonstrate that a requirement is met, including the case that should fail, and writing it before the thing exists rather than after it passes.
- Traceability maintenance
- Keeping the link from clause to specification line to test case current. A matrix is usually correct on the day it is written and drifts from then on.
- Change impact
- When a clause is revised, finding every specification line and every test case it reaches. Doing this by reading is how a requirement quietly loses its test.
Coverage
What stays with the people who own the document
A governing document is written by people with authority over its subject, and it stays theirs. Quantscope covers the segment between that document and a specification a team can build and test against, together with the traceability that holds the two together.
What a clause requires is decided by the people who own the document. The modules hold the structure around that decision: what was extracted, what it became, what proves it, and what a revision changed. Interpretation and approval are made by the people who own the document, under your procedures, and no module makes a judgement offered as one.
What stays with you
- Authority over the document
- What a clause requires, and whether a specification line expresses it correctly, is settled by the people who own the document. The modules record that decision rather than making it.
- Approval and release
- Specification approval, test case approval and release stay inside your quality system, under your signatures.
- The systems of record
- Your requirements management and test management tools stay the system of record. The modules run against them and hand structured outputs back, carrying the identifiers you already use.
- Subject matter judgement
- Where a clause needs a specialist to read it, the configuration names who that is and what stops until they have. Nothing proceeds on a default in their absence.
Configuration
What the configuration encodes
The modules carry no knowledge of any particular governing document. What makes them useful is the configuration: what counts as an obligation in your documents, how a specification line is shaped, what a test case has to contain, and which disagreements stop a specification from progressing. That configuration belongs to you and is versioned like code.
Every item below is written as an acceptance test before it is built, which is also what makes the list finite: a rule nobody can state as a test is a rule nobody can prove was applied.
- Obligation rules
- What makes a sentence an obligation rather than context, per document class. Modal verbs, defined terms and cross-references each carry different weight, and each is written separately.
- Specification shape
- What a well-formed specification line contains: a single assertion, an identifier, the clause it derives from, and the condition that would demonstrate it.
- Test case completeness
- What a test case has to state before it counts as written: preconditions, steps, the expected result, and the case that should fail where one applies.
- Traceability rules
- What must trace to what, and which gaps are a finding. An untested requirement and an untraced test case are different findings and route differently.
- Change impact
- Which downstream outputs a clause revision reopens, and whether reopening one stops a release or raises a query.
- Query routing
- Which findings an author can resolve, which go to the document owner, and which stop a specification from progressing at all. Routing is configuration, so that changing it does not require a release.
Context
What a reviewer can ask for
Specification and validation outputs are the evidence a reviewer actually reads. They run under your quality system rather than beside it, with your team holding release.
A reviewer should be able to ask which clause a requirement came from, which test proves it, and what the last revision changed, and receive a document rather than a reconstruction.
| Output | What it establishes |
|---|---|
| Obligation register | Every clause carrying an obligation, with its source location |
| Requirements document | What the system must do, traced to its clause |
| Functional specification | How the system does it |
| Test cases | What demonstrates each requirement, including the cases that should fail |
| Traceability matrix | Every requirement traced to a clause and to a test |
| Change impact record | What a revision reopened, and what was re-executed |
| Release notes and version history | What changed, when, and why |
A revision is the test of whether the traceability was ever real. The change impact record is produced by the configuration that produced the matrix, so the two cannot quietly drift apart between reviews.
Questions
Questions a first review asks
Does the software decide what a clause means?
No. It proposes an extraction together with the evidence for it: the location in the source, the text it relied on, and the rule that fired. A person with authority accepts, edits or rejects that proposal.
Where the rules cannot settle an item it halts rather than defaults to an answer. Nothing progresses on the strength of a model being confident.
What happens when the source document is revised?
The change impact record names every specification line and every test case tracing to a changed clause, and those outputs reopen.
Whether reopening one stops a release or raises a query is configuration, agreed upfront rather than decided during the revision.
Do you replace our requirements management tool?
No. Your tool stays the system of record and your approval workflow stays where it is. The modules run against it, take documents as they arrive, and hand back structured outputs with the evidence for every extraction.
The connection is a named, versioned output, scoped like any other part of the build.
Is this the same platform as the data quality offering?
Yes. The same four modules against a different problem: Conduit resolves the source into typed outputs, Signal checks them, Trace finds what relates to what, and Gauge establishes whether the same input still produces the same result. What differs between the two is the configuration, not the modules.
Reaching a new input type is scoped and built like any other part of the engagement.
Have you done this in a regulated environment before?
No. The company page describes what does exist and where it runs.
The commercial structure is built around that answer: fixed scope, acceptance criteria agreed before build, and a first milestone deliberately small enough that you find out whether it works early rather than at the end. If it does not meet the criteria it is not accepted and not billed.
Contact
Start with the data
Send the document class, the volume, and what currently has to be traced by hand. If a module cannot be scoped against acceptance criteria, you will be told so.
Request a technical sessiongoes to info@quantscope.ai · response within two business days