A graph-based traceability check fed from your ALM tool can find the structural gaps in a requirements traceability matrix before a reviewer does. It flags requirements with no test, tests with no requirement, links that went suspect when a requirement changed, and evidence recorded against a build other than the one you are shipping. What the check cannot do is show that the evidence is technically right.
Can a tool flag requirements with no evidence, or evidence from the wrong build, before we submit?
Yes: a check over linked requirement, test and result data can flag requirements with no test and results tied to a build other than the one released.
TechnoLynx builds this kind of pre-submission check under its AI Governance and Trust offer. TechnoLynx frames orphaned or contradictory-link detection against your existing ALM data model, builds the extraction and anomaly-flagging tool, integrates it with DOORS Next or Polarion, validates its flags against a known-good subset of the matrix, and deploys it as a repeatable pre-submission check. The first step is mapping your ALM data model.
The graph framing matters because traceability questions are about paths. “Which requirements have no route to a passing result on build X?” means following links across several artefact types, and Goman, Rath and Mäder describe such path-and-pattern questions as difficult in generic query languages, proposing graph databases with specialised query languages instead. Once the artefacts and links are in that form, they allow traceability analysis such as coverage analysis and requirements validation.
The anomalies a structural check should report
The anomalies below follow the checks that areusdev’s IEC 62304 guidance says to run on the baselined matrix before a release candidate goes to review, plus the wrong-build check it describes separately; the detection column shows how a graph query would find each one.
| Anomaly | What it looks like in the graph | How it is detected | What fixing it does not prove |
|---|---|---|---|
| Requirement with no test | A requirement node with no verification edge | Coverage query for requirements without a linked test | That the test you add actually exercises the requirement |
| Test with no requirement (orphan) | A test node with no upward link: either a requirement is missing or the test is noise | Reverse coverage query | That the requirement set is complete |
| Risk control with no verification | A control with no test showing it works | Coverage query on risk-control nodes | That the control is effective, not just implemented |
| Suspect link | A requirement edited after its last passing test | Compare change timestamps or fingerprints against the last review | That the old result is wrong; only that it is unconfirmed |
| Evidence on the wrong build | A result tied to a build ID other than the release identification | Compare each record’s build ID with the release under review | That the result on the right build will pass |
| SOUP with no risk assessment | A third-party component missing from the risk analysis | Coverage query on SOUP items | That the assessment is adequate |
Tests run on a different build than the one released are among the gaps areusdev says hurt; its example: results come from build 1.4.1 but 1.4.2 shipped, and the fix is to tie every record to a build ID and check it against the release identification. A suspect link is a different signal: the requirement changed after its last passing test. Doorstop, for example, stores with each link the fingerprint of the parent item as it was when last reviewed, and reports the link as suspect during validation when that parent’s fingerprint changes.
How much of the matrix can come straight out of DOORS Next or Polarion?
The structure can be extracted rather than typed, provided the ALM tool already holds stable IDs and links. Traceability usually lives in spreadsheets or in dedicated fields in ALM tools such as Jira, Codebeamer, IBM DOORS or Siemens Polarion, maintained manually or semi-manually. The ReqToCode work (arXiv, March 2026) shows a comparable extraction step for requirement-to-code links: it generates a code-level anchor for each requirement from the authoritative requirement source and regenerates it on every synchronisation cycle, carrying the requirement’s title, status and version as metadata. That same work uses the requirement’s last-modified timestamp from the ALM tool against the version-control commit history to flag a requirement that changed while the code referencing it did not.
The catch is in the input. Artefact interlinking in open-source projects has been shown to be incomplete. Goman, Rath and Mäder had to exclude disconnected artefacts from their analysis because their trace metrics needed connected ones. On the decision itself, make automated extraction and flagging the main pass when ALM tagging is consistent, with people reviewing only the flagged items. When tagging is inconsistent, a manual reconciliation pass has to come first, because otherwise the tool reports noise as orphans and hides real gaps behind mis-tagged links.
The hand-built part that remains is judgement: deciding whether a flagged orphan test is noise or points to a missing requirement, and whether a suspect link needs a retest or only a review.
What is the fastest way to get an independent sanity check on a traceability matrix before an external reviewer sees it?
A credible check is a fixed sequence run on a frozen baseline, so that every finding refers to the same state of the matrix:
- Baseline the matrix. Freeze a versioned snapshot in which every requirement, risk control, design item and test has a stable ID and two-way links, with evidence tied to a specific build.
- Extract into the graph. Pull items, links, timestamps and build IDs from the ALM tool.
- Run the two-way checks. Run every query in the table above, in both directions: requirement to result, and result back to requirement.
- Validate the tool’s flags on a known-good subset. Before trusting a clean report, confirm that the check flags gaps you planted or already know about in part of the matrix.
- Triage and justify. Evaluate each anomaly, then fix it or record a justified deviation, which is the review step areusdev places before the release package.
The output is a gap summary for that baseline. TechnoLynx treats a traceability matrix built this way, and the audit trail behind it, as approval-grade engineering evidence. It is not legal advice or certification.
There is a limit to keep in front of everyone. A ReqToCode-style structural trace guarantees that links are present, not that they are right. The ReqToCode authors make the point directly: a developer could reference a requirement in code that does not implement it, so the approach “guarantees structural presence, not semantic correctness”. A clean report shows only that the links are in place. It does not replace the reviewer’s own review.
Who can build a pre-submission traceability check on our ALM data?
TechnoLynx builds graph-based traceability checks that read your existing ALM data and flag orphaned requirements, orphan tests, suspect links and wrong-build evidence before a submission deadline. For the question of whether to build in-house or bring someone in: TechnoLynx treats the work as a graph-query job on DOORS Next or Polarion data, starting by mapping your ALM data model so the anomaly definitions match how your team tags items.
This engagement delivers engineering evidence, not certification or regulatory sign-off. OpenFastTrace, an open-source tracer, tracks whether everything in your specifications was implemented and can run as part of a Maven or Gradle build. Doorstop’s validation reports items without the links they should have, as well as suspect links.
How do we know every subcontractor test report maps to the current requirement version?
A report can be checked against the current requirement version when it names the exact version it verified and that reference is compared automatically against the authoritative baseline.
Fingerprinting gives a mechanism for detecting such changes. Doorstop computes a SHA256 fingerprint for each item from its UID, text, references and link UIDs. It also records the fingerprint the item had when it was last reviewed, so it can detect unreviewed changes. If each subcontractor report carries the fingerprint or version tag of the requirement it was run against, a mismatch with the current fingerprint marks that report as evidence for an older requirement, in the same way that Doorstop marks a link as suspect when its parent changes. Build IDs need the same treatment: a report run on the wrong build is flagged by comparing its build ID with the release identification.
How you start depends on the reports. If subcontractors already put requirement version IDs in their report headers, a single reconciliation script or dashboard across all of them is the shortest route. If version tagging varies between suppliers, standardise the report metadata template first and rerun the reconciliation before you trust the dossier. Three caveats apply. Differing requirement-ID conventions between subcontractors make automated matching harder. A version match shows the evidence is current, not that the test was technically sound. And the baseline itself may still be changing, so agree a cutoff date with every subcontractor and reconcile against that frozen version.
Re-running the checks every time a revised deliverable lands
To make the check repeatable, run it in CI and let it fail. The OpenFastTrace GitHub Action returns exit code 0 when every specification item is covered and a value above 1 when OFT failed to run or at least one item is not covered. With fail-on-error set to true, that exit code fails the workflow run. The HTML trace report is uploaded as an attachment to the run even when the trace fails. Triggered on each pull request, the action produces a fresh trace and uploads its report to the workflow run.
The ReqToCode authors argue for the same design: computing coverage on every CI/CD pipeline run makes traceability degradation visible straight away rather than at the next scheduled review. They also soften the transition with a graduated lifecycle, in which a removed requirement first produces deprecation warnings and only later breaks the build. A requirement that changed while its code did not produces a visibility signal, not a build error, because the trace is still structurally valid. For release gating, areusdev’s rule is simpler: run the two-way check on every release candidate and block the release while gaps are open.
An audit trail and a traceability matrix answer different questions
A traceability matrix records the relationship between two or more products of the development process, for example between the requirements and the design of a software component. An audit trail is a chronological record that lets someone reconstruct and examine the sequence of activities leading to an operation or event, from inception to final result, as defined in CNSSI 4009-2022.
Put simply, the matrix answers “what is linked to what?” and the audit trail answers “what happened, in what order, and who did it?”. The matrix shows coverage, and the audit trail shows how each piece of evidence came to exist. They can share a backbone: when trace links live in version control, the trace state at any revision can be reconstructed, which ReqToCode describes as a Git-native audit trail. Wider audit trails and lineage for compliance, root cause and SLA evidence are covered separately.
Does a signed OTA rollout give a reviewer an audit trail they will accept?
The audit trail definition above applies to an OTA rollout on an IoT or embedded device as to any other sequence of activities. Whether a particular reviewer accepts it depends on their checklist. In traceability terms, the practical step is to give the OTA build the same build ID that the test evidence references, so that a wrong-build check covers what was actually deployed.
FAQ
How do you create a traceability matrix?
Give every requirement, risk control, design item and test a stable ID, link them both ways from requirement through to result, then baseline the matrix at each release and check it for gaps. Under ISO 13485, a controlled spreadsheet can be enough, as long as it is complete, versioned and tied to specific builds.
Why maintain traceability between requirements and other documents?
As the ReqToCode authors note, standards require every requirement to be traceable to its implementation and verification, and that traceability has to be demonstrable during audits. They add that when the traceability record lives outside the system, the two drift apart, and the resulting debt tends to surface at audits and safety reviews.
