Requirements Traceability Check¶
Traceability analysis — instantiates Deductive Chain Validation
Links a 'complete', 'safe', or 'compliant' claim down to the specific requirements, assumptions, and tests that ground it, flagging every link that rests on an unverified assumption.
A Requirements Traceability Check treats a high-level claim — "this release is complete," "this system is safe," "this build is compliant" — as the top of an argument, and links each element of that claim downward to the specific requirements, assumptions, and test results meant to ground it. Its defining move is structural rather than evaluative: it maps the claim to its supporting inference chain and flags any link that is missing, broken, or resting on an unverified assumption — without itself ruling on whether any individual premise is true. It answers "is every part of this claim actually connected to something that supports it, and where are the weak connections?" — leaving the verifying of each connected item to whoever owns it. The output is a picture of what the claim depends on and where it is thin, not a verdict on the claim.
Example¶
A medical-device team is about to sign off that "the infusion pump firmware meets its safety requirements." A Requirements Traceability Check builds the map instead of taking the sign-off on faith. Each safety requirement is traced to the design element that implements it, the test that exercises it, and any assumption it leans on. Most links are solid. But requirement SR-14 — "no single fault shall cause over-delivery" — traces to a test recorded as "passed, assuming the occlusion sensor is calibrated within tolerance," and the calibration procedure is not yet closed. Two other requirements trace to design elements with no linked test at all. The check doesn't declare the firmware unsafe; it converts "we think it's safe" into a precise structure: "it is safe if these three open assumptions hold and two untested requirements are covered" — turning a blanket claim into a short, named list of exactly what still has to be true.
How it works¶
The check works top-down from the claim, decomposing it into the requirements it asserts and tracing each to its grounds — design, test, evidence, or a stated assumption. Every requirement must terminate in something concrete; a requirement that traces to nothing is a gap, and a requirement that traces only to an assumption is a conditional link. It records the whole as a traceability structure[1] — historically a matrix, increasingly an explicit assurance case — so coverage is visible at a glance: which claims are fully grounded, which have holes, and which stand only on assumptions someone still has to discharge. Its discipline is to be honest about linkage, not to adjudicate the linked items: a link to a passing test is recorded as present, and whether that test was itself valid is somebody else's check.
Tuning parameters¶
- Trace granularity — claim-to-requirement only, versus full claim-to-requirement-to-design-to-test-to-assumption. Deeper traces expose more hidden dependencies but multiply the links to maintain as the system changes.
- Assumption surfacing — whether every leaned-on assumption must be written as an explicit node or may stay implicit in a test's fine print. Explicit assumptions catch the SR-14-style gap but inflate the structure.
- Coverage bar — how much of the claim must be fully grounded before it may be asserted: no gaps, versus gaps allowed if flagged. A strict bar prevents thin claims but can stall a release on a formality.
- Bidirectionality — forward-only (claim → grounds) versus also backward (each requirement → the claims that depend on it). Backward links reveal orphaned requirements and blast radius but double the bookkeeping.
When it helps, and when it misleads¶
Its strength is exposing the two things a confident sign-off hides: requirements that trace to nothing, and claims that quietly ride on unverified assumptions. By making the whole support structure inspectable, it turns "it's safe" into an auditable dependency graph and gives the residual-risk conversation a concrete target — these specific open links.
Its failure mode is coverage theater: every requirement has a link, the matrix is green, and no one notices that a link points at a stale test, a weak assumption, or a document that doesn't actually establish what it claims to. Traceability certifies that a connection exists, not that the connected evidence is sound — a fully-linked matrix over rotten evidence is a confident path to a wrong sign-off. The guarding discipline is to treat every flagged assumption and every link as a claim still owed a real verification, and to route those to the mechanisms that actually test them, rather than reading a complete map as a complete proof.
How it implements the components¶
premise_list— inventories the requirements, assumptions, and acceptance criteria the top claim depends on, as an explicit, enumerated set of inputs.inference_step— the trace links are the inference chain from grounds to claim, laid out link by link so each supporting step is individually inspectable.residual_uncertainty_label— flags each link that rests on an unverified assumption or a coverage gap, so the claim's confidence is explicitly bounded to its weakest supported link.
It maps a claim to its grounds but does not itself verify those grounds (premise_verification) — running the tests and confirming the facts is done by others, such as Policy Eligibility Review for case facts and Rule-Engine Validation for encoded logic — nor does it rule on the abstract validity of each step (validity_check), which Logic Checklist prompts. Unlike the abstract form laid out by Syllogism Template, this maps a concrete engineering claim to real evidence and marks the gaps.
Related¶
- Instantiates: Deductive Chain Validation — Requirements Traceability Check is the archetype's form for assurance claims, grounding a "safe/complete/compliant" conclusion in an inspectable web of requirements and evidence.
- Sibling mechanisms: Rule-Engine Validation · Policy Eligibility Review · Diagnostic Logic Check · Logic Checklist · Syllogism Template · Legal Syllogism Review · Proof Checking
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Requirements Traceability Check operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it links a 'complete', 'safe', or 'compliant' claim down to the specific requirements, assumptions, and tests that ground it, flagging every link that rests on an unverified assumption.
Independent corroboration: The frozen evidence defines Requirements Traceability Check as 'Links a 'complete', 'safe', or 'compliant' claim down to the specific requirements, assumptions, and tests that ground it, flagging every link that rests on an unverified assumption', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Analysis, Modeling & Optimization — Requirements Traceability Check includes features of an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution, but its defining operation is a bounded evaluation of existing evidence or work that produces a finding or disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Tracing claims through requirements, assumptions, and tests originates in systems and safety engineering.
Related originating lineages:
- Computer Science & Software Engineering — Software verification materially developed automated trace links to code and tests.
- Law & Governance — Compliance practice independently requires evidence chains from rules to controls.
Review resolution: Both blind reviewers agree that engineering_design is the primary historical origin. Explicit reconciliation of alternate origin disagreement adopts reviewer_a's evidence: Tracing claims through requirements, assumptions, and tests originates in systems and safety engineering. The selected record uses alternates=computer_science, law_governance, origin_mode=cross_disciplinary_synthesis, and domain_reach=multi_domain; the other review proposed alternates=computer_science, systems_cybernetics, origin_mode=cross_disciplinary_synthesis, and domain_reach=multi_domain. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Kelly, T. P. Arguing Safety – A Systematic Approach to Managing Safety Cases. PhD thesis, University of York (1998). Presents a graphical assurance structure linking claims to evidence while explicitly showing assumptions and undeveloped goals. registry ↩