Draw the candidate links, keep the evidence and the doubt beside each one, and hand the matrix — not a coverage claim — to the reviewer whose name goes on the submission.
A link is proposed, and the signal that suggested it is recorded beside the link itself.
02
A link is not a proof: the matrix records a relation, never the argument that it holds.
Reason
03
Best published trace recovery holds up two links in five, on a set of twenty-two requirements.
04
A review of seventy-nine studies found no compelling evidence that recovered links are useful.
05
Design control runs 820.10(c) to ISO 13485 clause 7.3; 820.30 was reserved on 2 February 2026.
Decide
06
Traceability sits at clause 7.3.2, and the design history file is now clause 7.3.10.
07
Under 807.87(l) a responsible person of the firm, not a consultant, signs within fifteen days.
Out
08
No rule found requires the matrix as a document, and that absence is recorded, not filled.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Drafting, linking and holding belong to the agent. Coverage belongs to a named reviewer, who accepts the link and answers for the file at inspection.
Example workflow
One link, proposal to acceptance
AgentHuman
1Requirement set extractedDesign inputs, software requirements, hazards, test cases and the change history behind them
2Baseline fixed and datedThe requirement identifiers, their versions, the artefacts in scope and the day the baseline was taken
3Candidate links proposedThe requirement, the artefact that may cover it, the signal that suggested the link and the confidence
4Controls appliedBaseline checks, direction checks, orphan checks and link confidence
No human action required
Stages 1 to 4 run unaided, and no requirement is called covered at any of them — the agent is proposing, and the reviewer lane opens at the acceptance gate.
5DecisionSplits at the acceptance gate
A link with cited evidence
Goes to the named reviewer to accept.
Anything safety-bearing
Adds a design-assurance read first.
Design-assurance review
The link is held with its evidence, its direction and the requirement the agent could not place.
Accept · Reject link · Send to design-assurance review
Accepted — by the named reviewer▼
6Design file and matrix records updatedOnly where write access and records policy allow it
7Outcome evaluatedAcceptance outcomes, orphan age, reviewer rejections and what a CP 7382.850 sample asked to see
Corrections
Each link the reviewer rejects counts in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Concluding that a requirement is covered.
Signing the truthful and accurate statement.
Closing an orphan requirement.
Accepting a link into the design file.
Automation boundaryAgent acts unaided
✓Propose a candidate link and cite its evidence.
✓Record each candidate link with the traceability signal under it.
✓Hold each unplaced requirement for a named reviewer.
✓Flag each requirement the latest change left without verification.
No requirement is called covered except by a named reviewer, inside the agreed boundaries.
Judging whether a test verifies a requirement.
Telling a notified body the file is complete.
Choosing which artefacts a baseline covers.
Changes to the linking rules or the review gate.
Example output
One proposed link, annotated
This serves the design-assurance lead who must show an unbroken chain years after transfer, and Koven Technologies drew one of the first warning letters written in the post-QMSR style; below is one proposed link exactly as the agent leaves it.
Proposed link · single requirementIllustrative example
Link
Recorded as
Direction
Evidence of record
Confidence
Held for
Design input to system test
Proposed, not accepted
Both directions
Design file, 14 August 2026
Held unaccepted
The named reviewer, by name
As receivedDrawn from the requirement text, the test record and the change history, and it shows resemblance only.
What the record holdsRequirement textTest recordChange history
Why no coverage hereCalling a requirement covered is a judgement a named reviewer makes.
ActionAccept linkReject linkSend to design-assurance review
What the score decidesBelow the configured threshold a link gets a design-assurance read before the reviewer.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Each proposed linkFrom the requirement it claims to cover
03Link signal
Where the link is read
MDR Article 15(3)(b) makes the technical documentation a named person's continuing duty, and FAA Order 8110.49A walks an inspector from system requirement to test result.
01Approved path
A link is not a proof
An agent can assert that a test covers a requirement; it cannot know whether the test exercises the conditions that requirement sets, and NPR 7150.2D asks for the chain in both directions.
02Human review
What was checked, and not found
No rule located requires a traceability matrix as a document; FDA asks for the property, not the spreadsheet. Its design-control guidance of March 1997 is still listed Final while construing a section reserved on 2 February 2026, the same day QSIT was withdrawn.
04Build an evidence trail
The requirement, the test that claims it and the reviewer who accepted the link stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Requirements and design inputsALM suites · requirement stores Requirement text and versions
Tests and verification recordsTest management · CI results Test cases and their results
Risk and hazard filesRisk register · hazard assessments Hazards and risk control measures
Agent
Requirements tracing and review
Reads the requirements Proposes the links Holds the matrix
Design and change recordsChange control · design file feeds Change orders and design outputs
A programme coverage figure can read clean while requirements that changed late carry most of the reviewer rejections. Nestack reports the rejection rate by requirement class, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Changed safety requirements
10.4%
3.7×
Review
Clinically worded requirements
7.4%
2.6×
Review
Derived low-level requirements
4.6%
1.6×
Watch
Stable functional requirements
2.1%
0.7×
Normal
Bar: rejection-rate lift vs. stable-requirement baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a broken link costs
A loop closes when the requirement covered on paper alone is a standing case. That suite is what the next matrix drawn is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Rejection rate rises on requirements that changed late.
02Diagnose
The indications quietly widened to take in a fetal application, cited at Koven Technologies in warning letter 734643 under clause 7.3.9, are worked backwards until one cause is left standing.
03Improve
Number the matrix; the links that fill it are filed beneath it.
04Verify
A single orphan requirement case stops the whole matrix issuing.
05Learn
One case joins the suite, and one line joins the linking rules.
Learn → DetectThe return edge. The next matrix is drawn against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, linking logic, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Trace scope and the automation-boundary definition.
02Requirement, test and risk sources.
03Requirement-to-test and reverse-direction coverage.
04Requirement extraction.
05Baseline and artefact binding.
06Link confidence and review routing.
07Reviewer acceptance workflow.
08Design-file integration.
09Coverage and orphan cases.
10Guardrails and linking controls.
11Link-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne requirement set, one cycleProductionProduction review workflowAdvancedMultiple programmes / standards
Introduced at Pilot
Linking to your requirement classes✓✓✓
Named reviewer acceptance✓✓✓
Requirement-inventory baseline✓✓✓
Introduced at Production
Reporting by requirement class—✓✓
Reviewer review workflow in your systems—✓✓
Approved design-file write-back—✓✓
Toolchain-and-repository integration—✓✓
Introduced at Advanced
Multi-standard linking rules——✓
Cross-programme trace packs——✓
Large requirement sets——✓
Multi-standard coverage controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, requirement volume, acceptance controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live requirement sets and the standard each is held to→Baseline capture and link versioningWeek 1
02Representative requirements, tests and past review decisions→Artefact binding, linking logic and the requirement-inventory baselineWeek 2
03Your review path and the design-assurance lead it names→Baseline mapping, artefact binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Requirement, test and risk source assessment, then integration setupWeek 2
05Matrices you would not want inspected→Coverage cases and the failure roundWeek 4
06What no link may demonstrate→Link confidence, review routing, guardrails and release controlsWeek 3
07A named reviewer who accepts the link→Handover to the named reviewer, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
These bands are counted and not evened out; the fifth week holds two because the two genuinely overlap.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Baseline discovery, link versioning and the automation boundaryW2Requirement, test and risk integration and the inventory baselineW3Artefact binding, linking logic and release controlsW4Evaluation suite, coverage cases and failure-mode testingW5Design-file integration, pilot matrices and targeted correctionsW6One design cycle run under the design-assurance lead, then Agent Care handover
Reading the bandEach bar covers the weeks its own work is named for, and week five carries the overlap.
At the end of W6Once the link record validates, Agent Care adopts the agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Quality AI agent
Build a requirements trace agent around the link your last submission never proved.
Show us one requirement and the test your matrix says covers it. Not how fast the links were drawn. Which baseline they were drawn against, what the link establishes and what it does not, and whose name goes under the submission. A link nobody proved comes back as a finding.
