Requirements Traceability Exclusion¶
An audit — instantiates Contrapositive Elimination Reasoning
Rules out the claim that a requirement is satisfied when its mandatory downstream trace — the test or evidence it must link to — is missing, scoped to a specific build or baseline.
Requirements Traceability Exclusion runs the contrapositive over a traceability web. Every requirement carries a forward obligation: if it is genuinely satisfied, it must trace to a design element, a passing verification, and its evidence. A missing mandatory link therefore rules out the claim "this requirement is verified." Its distinctive character is that it treats the forward trace link itself as the necessary consequence and drives the elimination from the link's absence — and that every finding is bound to a configuration baseline, so "unverified" is a precise, versioned claim rather than a vague unease.
Example¶
A medical-device software team is assembling a submission. Its traceability matrix links each requirement forward to design, code, and a verifying test with a recorded result. The audit walks the web. Requirement SR-142 — "the pump shall halt on occlusion within X milliseconds" — must trace to a passing verification. The matrix shows a linked test case, but there is no passing result recorded against it in this build: the mandatory downstream consequence is absent. So the claim "SR-142 is verified" is ruled out — for build 4.2, specifically.
The scoping is the point. The finding is pinned to that baseline; a later build that records the passing result clears it, and no other requirement is implicated. Run across the whole matrix, the audit converts the fuzzy question "are we done?" into a versioned list of exactly which satisfied-claims are ruled out and where. The discipline mirrors avionics and medical-software assurance standards, where a requirement without a passing forward trace cannot be called verified.[n1]
How it works¶
- Treat the forward trace as the required consequence — a satisfied requirement must link forward to a design element, an executed test, and a passing result; those links are the mandatory footprint.
- Cut on a missing link — where a mandatory downstream artifact is absent, the "verified" claim for that requirement is ruled out.
- Bind each finding to a baseline — every exclusion is stamped with the exact build, release, or branch it applies to, so "unverified" is versioned, not permanent.
- Sweep bidirectionally — flag orphan requirements (no downstream trace) and, optionally, orphan tests or code with no upstream requirement.
Tuning parameters¶
- Trace-completeness bar — which downstream artifacts are mandatory (design and code and test and evidence, or a subset). A stricter bar produces more "unverified" findings.
- Baseline granularity — whether findings are scoped per build, per release, or per branch.
- Bidirectionality — whether the audit also flags orphan tests and code with no upstream requirement, not just orphan requirements.
- Evidence strictness — whether a linked-but-unexecuted test counts as a valid trace or as a gap.
When it helps, and when it misleads¶
Its strength is converting an open-ended "are we finished?" into a mechanical, versioned exclusion of every unverified claim — objective, auditable, and reproducible across builds.
Its failure mode is the hollow link: a trace can exist while being empty — a linked test that does not actually exercise the requirement, or a result recorded without a real run. The presence of a link then falsely clears a requirement the audit should have excluded, the mirror image of a false elimination. The classic misuse is back-filling trace links after the fact to make a baseline look verified without re-running verification. The discipline is to require every link to point at an executed, passing artifact, and to re-scope each finding to the exact baseline rather than carrying it forward blindly.
How it implements the components¶
Requirements Traceability Exclusion realizes the trace-and-scope side of the archetype — recording the forward obligation and bounding the exclusion:
forward_implication_record— the trace link itself: the recorded obligation "requirement ⟹ must have this verifying artifact," which the audit checks for presence.elimination_scope_boundary— every "unverified" finding is bound to a specific build or baseline, never to the requirement in perpetuity.
It does not judge whether an absent artifact was truly detectable versus merely un-searched (detectability_and_scope_check — that's Negative-Evidence Reliability Review); it does not run the verifying tests or encode their oracles (necessary_consequence_signature, exception_and_defeater_list — that's Falsification Test Harness); and it does not perform the bare deduction (contrapositive_inference_step — that's Modus Tollens Checklist).
Related¶
- Instantiates: Contrapositive Elimination Reasoning — the audit is the archetype applied to a requirements trace web, ruling out unverified claims baseline by baseline.
- Consumes: Falsification Test Harness (and its execution records) produce the passing verification artifacts whose presence or absence the audit traces.
- Sibling mechanisms: Eligibility Element Exclusion Review · Falsification Test Harness · Negative-Evidence Reliability Review · Modus Tollens Checklist · Required Consequence Table · Elimination Decision Log
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Requirements Traceability Exclusion operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it rules out the claim that a requirement is satisfied when its mandatory downstream trace — the test or evidence it must link to — is missing, scoped to a specific build or baseline.
Independent corroboration: The frozen evidence defines Requirements Traceability Exclusion as 'Rules out the claim that a requirement is satisfied when its mandatory downstream trace — the test or evidence it must link to — is missing, scoped to a specific build or baseline', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Decision, Gate & Allocation — Requirements Traceability Exclusion includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, 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: Single lineage
Present-day reach: Multi-domain
Rationale: Rejecting satisfaction when mandatory verification trace is absent is a systems-engineering assurance rule.
Related originating lineages:
- Computer Science & Software Engineering — Build-baseline and test-coverage practice materially operationalized missing-trace exclusions.
Review resolution: Both blind reviewers agree that engineering_design is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement adopts reviewer_a's evidence: Rejecting satisfaction when mandatory verification trace is absent is a systems-engineering assurance rule. The selected record uses alternates=computer_science, origin_mode=single_lineage, and domain_reach=multi_domain; the other review proposed alternates=computer_science, philosophy, 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.
Notes¶
[n1] Assurance standards such as DO-178C for airborne software (and IEC 62304 for medical-device software) require a requirements traceability matrix in which each requirement links forward to its verification evidence; a requirement lacking a passing forward trace cannot be claimed as verified. The audit is that standard's contrapositive: no trace, no verified-claim — for the baseline under review. ↩