Main site

Quality AI agent · Requirements trace

Requirements Trace AI Agent

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.

Typical delivery
4–6 weeks
Deployment
Your stack
Named reviewer
Links first
After launch
Agent Care

What this agent does

Proposes the link, never certifies it

In

  1. 01

    A link is proposed, and the signal that suggested it is recorded beside the link itself.

  2. 02

    A link is not a proof: the matrix records a relation, never the argument that it holds.

Reason

  1. 03

    Best published trace recovery holds up two links in five, on a set of twenty-two requirements.

  2. 04

    A review of seventy-nine studies found no compelling evidence that recovered links are useful.

  3. 05

    Design control runs 820.10(c) to ISO 13485 clause 7.3; 820.30 was reserved on 2 February 2026.

Decide

  1. 06

    Traceability sits at clause 7.3.2, and the design history file is now clause 7.3.10.

  2. 07

    Under 807.87(l) a responsible person of the firm, not a consultant, signs within fifteen days.

Out

  1. 08

    No rule found requires the matrix as a document, and that absence is recorded, not filled.

  2. 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

  1. 1Requirement set extractedDesign inputs, software requirements, hazards, test cases and the change history behind them
  2. 2Baseline fixed and datedThe requirement identifiers, their versions, the artefacts in scope and the day the baseline was taken
  3. 3Candidate links proposedThe requirement, the artefact that may cover it, the signal that suggested the link and the confidence
  4. 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

  1. 6Design file and matrix records updatedOnly where write access and records policy allow it
  2. 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 required

8 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 boundary

    Agent 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 requirement

Illustrative example
Link
Design input to system test
Recorded as
Proposed, not accepted
Direction
Both directions
Evidence of record
Design file, 14 August 2026
Confidence
Held unaccepted
Held for
The named reviewer, by name

As received

Drawn from the requirement text, the test record and the change history, and it shows resemblance only.

What the record holds

  • Requirement text
  • Test record
  • Change history

Why no coverage here

Calling a requirement covered is a judgement a named reviewer makes.

What the score decides

Below the configured threshold a link gets a design-assurance read before the reviewer.

Action

Accept linkReject linkSend to design-assurance review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Each proposed link

From 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.

04

Build 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 inputs

    • ALM suites
    • requirement stores
    • Requirement text and versions

  • Tests and verification records

    • Test management
    • CI results
    • Test cases and their results

  • Risk and hazard files

    • Risk 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 records

    • Change control
    • design file feeds
    • Change orders and design outputs

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six meshes between the link and the file

Six meshes stacked in one frame, the last the closest. What holds is drawn in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to requirement listing when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and linking rules, and note the version each link was proposed under.Track
L4TraceabilityRecord each link, the signal under it, the baseline it came from and each read of the file.Record
L3Reviewer releaseHold the link for a named reviewer; the hold governs acceptance, not whether the link is true.Gate
L2Baseline guardrailsTest each link against its dated baseline, and refuse one drawn from a superseded requirement.Restrict
L1Confidence thresholdsRoute a safety-bearing or thinly evidenced link to a design-assurance read before the reviewer sees it.Require review
Model coreLink proposed — the requirement, the artefact, the signal, the direction and what stays unplaced
L1 – L2
Test whether a link may be accepted
L3
Leaves the acceptance to a named reviewer
L4 – L5
Keep the link and the requirement behind it
L6
Marks the link unverified when signals degrade

How Nestack evaluates it

Evaluate the whole tracing run — not only the matrix that comes out.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the matrix an inspector opens

  1. E1Final-output evaluationDid the link stay inside what its cited evidence actually shows?
  2. E2Step-level evaluationDid the agent read the right baseline, the right artefacts and the live linking rules?
  3. E3Tool evaluationDid it read the correct requirement and write the correct link record?
  4. E4Confidence calibrationDo low-confidence links actually attract more reviewer rejections?
  5. E5Slice evaluationHow does performance change across requirement classes and link directions?
  6. E6Business outcomeHow many links needed a second read before the reviewer accepted one?

Floor — the file read back under CP 7382.850

Failure modes

Where each failure originates in the agent

Seven failure modes, each placed where the break first becomes visible.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • VH-03

      Live view read as the record

      The tool is read, not the controlled file.

    Stage gathers

    The inputs, the tests, the code and the hazards

  2. 02 · Reasoning

    2 modes

    • VH-04

      Link asserted on wording alone

      Resemblance is filed as coverage.

    • VH-06

      Orphan closed by nearest match

      A real gap disappears into a link.

    Stage proposes

    The link, the signal, the direction and the doubt

  3. 03 · Tool / write

    2 modes

    • VH-02

      Reverse direction never drawn

      Forward links read green; nothing checks back.

    • VH-05

      Derived requirement given a parent

      The escalation that was owed never happens.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • VH-01

      Signed over links nobody read

      A name goes under a file too large to read.

    Stage returns

    The matrix a reviewer opens and then signs

  5. 05 · Change / Version

    1 mode

    • VH-07

      A change leaves the links behind

      The wording moves; the links stay valid and dead.

    Stage tracks

    Model, prompt, link rules and design changes

  • Sev-1 · a link certified but never read
  • Sev-2 · an orphan closed by resemblance
  • Sev-3 · link unverified, matrix held back
See the complete Requirements-trace failure-mode catalogue

Affected slices

Changed requirements absorb the rejections

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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Changed safety requirements10.4%3.7×Review
Clinically worded requirements7.4%2.6×Review
Derived low-level requirements4.6%1.6×Watch
Stable functional requirements2.1%0.7×Normal

Bar: rejection-rate lift vs. stable-requirement baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Rejection rate rises on requirements that changed late.

  2. 02

    Diagnose

    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.

  3. 03

    Improve

    Number the matrix; the links that fill it are filed beneath it.

  4. 04

    Verify

    A single orphan requirement case stops the whole matrix issuing.

  5. 05

    Learn

    One case joins the suite, and one line joins the linking rules.

  6. Learn → Detect

    The 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.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Trace scope and the automation-boundary definition.Week 1
  2. 02Requirement, test and risk sources.Week 1, Week 2
  3. 03Requirement-to-test and reverse-direction coverage.Week 1, Week 2
  4. 04Requirement extraction.Week 2
  5. 05Baseline and artefact binding.Week 2, Week 3
  6. 06Link confidence and review routing.Week 3
  7. 07Reviewer acceptance workflow.Week 3, Week 4
  8. 08Design-file integration.Week 5
  9. 09Coverage and orphan cases.Week 4, Week 5
  10. 10Guardrails and linking controls.Week 4
  11. 11Link-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final 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 price
Confirmed after discovery based on integrations, workflow complexity, requirement volume, acceptance controls and deployment requirements.
Separate from build
Build 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.

  1. 01Your live requirement sets and the standard each is held to

    Baseline capture and link versioning

    Week 1

  2. 02Representative requirements, tests and past review decisions

    Artefact binding, linking logic and the requirement-inventory baseline

    Week 2

  3. 03Your review path and the design-assurance lead it names

    Baseline mapping, artefact binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Requirement, test and risk source assessment, then integration setup

    Week 2

  5. 05Matrices you would not want inspected

    Coverage cases and the failure round

    Week 4

  6. 06What no link may demonstrate

    Link confidence, review routing, guardrails and release controls

    Week 3

  7. 07A named reviewer who accepts the link

    Handover to the named reviewer, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, 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.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Baseline discovery, link versioning and the automation boundary

W2Requirement, test and risk integration and the inventory baseline

W3Artefact binding, linking logic and release controls

W4Evaluation suite, coverage cases and failure-mode testing

W5Design-file integration, pilot matrices and targeted corrections

W6One design cycle run under the design-assurance lead, then Agent Care handover

Reading the band
Each bar covers the weeks its own work is named for, and week five carries the overlap.
At the end of W6
Once the link record validates, Agent Care adopts the agent.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your requirement sets
Named reviewer
Links first
After launch
Agent Care available

Nestack Agents · Requirements trace

AGT-QA-03 · Agent Care available after launch

Build a requirements trace agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your requirement sets

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.