Traceability
Certification-data traceability review for equipment suppliers
A certification-data traceability review walks each requirement from its source through design, verification, and the document that substantiates it, then confirms the chain is unbroken and consistent. It is used by avionics, equipment, and aircraft-modification teams whose data has been built across phases by different people and tools. It reviews the requirements set, the design and verification artifacts, the trace links, and the evidence each link points at. You receive a trace map by requirement, a register of broken or stale links, and a closure order ranked by review exposure.
When this review is needed
- Requirements were captured in one tool and verification recorded in another, and the link between them was never reconciled.
- A program absorbed scope changes and nobody confirmed that the trace followed the changed requirements.
- New derived requirements appeared during design and the team is unsure whether they reached verification and the safety assessment.
- An examiner or internal gate is about to test whether the data forms one chain rather than a stack of separate documents.
The problem
Trace links rot quietly. A requirement is edited, a test is re-run under a new identifier, an artifact is re-baselined, and the link that joined them still points at the old object. The documents each look finished on their own, so the break only surfaces when a reviewer follows a single thread end to end and it dead-ends.
What gets reviewed
- The requirements set and the source each requirement derives from
- Forward links from requirements into design and verification artifacts
- Backward links from test cases and analyses to the requirements they cover
- Derived requirements and whether they reached verification and the safety assessment
- The trace through the assigned design assurance level for software and hardware items
- Consistency between the trace tool, the verification records, and the means-of-compliance plan
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Every requirement resolves to at least one verification activity with a recorded result
- Every verification activity traces back to a requirement rather than standing orphaned
- Trace links point at the current baseline of the object, not a superseded revision
- Derived requirements are captured, verified, and fed into the safety assessment
- Identifiers are consistent across the requirements set, the trace, and the verification records
- Coverage matches the objectives expected at the assigned assurance level
- Open verification items are visible in the trace rather than absent from it
Evidence normally required
- The requirements set with identifiers and their sources
- The current trace data or traceability matrix
- Verification records, test cases, and analysis reports
- The means-of-compliance plan the trace is meant to satisfy
- Baseline and configuration history for the traced artifacts
Common discrepancies
- Requirements with a met status but no verification result behind the link
- Test cases that verify nothing in the requirements set
- Links pointing at superseded artifact revisions after a re-baseline
- A derived requirement verified in design but never returned to the safety assessment
- Identifier drift where the same object carries different references across tools
- Coverage below the objectives the assigned assurance level expects
What is at stake
A broken trace reads as missing compliance even when the engineering exists, because the reviewer cannot get from the requirement to the proof. Threads that dead-end generate questions that reopen artifacts already considered closed, and the schedule absorbs the rework.
How the work runs
Inventory the links
Pull the requirements set, trace data, and verification records, and reconcile their identifiers.
Walk both directions
Follow each requirement forward to verification and each verification item backward to a requirement.
Test the derived path
Confirm derived requirements reached verification and the safety assessment.
Rank and hand off
Produce the trace map and a link-repair order ordered by review exposure.
What the buyer receives
- A trace map by requirement showing forward and backward coverage
- A register of broken, stale, or orphaned links with the affected objects
- A closure order ranked by review exposure
Who uses the output
- Systems and verification engineers repairing the trace
- Certification leads confirming the chain before submittal
- Program management sequencing the link-repair work
How the work fits into the transaction or program
The review concentrates on the connective tissue of a certification package rather than the contents of any one artifact. It runs ahead of a fuller evidence review when the worry is that the pieces no longer join, and it leaves the team with a trace an examiner can follow without stalling.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
Endeavor Elements reviews the applicant's traceability data. It does not make compliance findings for the authority, accept the package, or determine airworthiness. The applicant owns the data and the authority retains its findings role.
What this review does not cover
- Authoring the missing requirements or verification artifacts
- Making compliance findings or issuing any approval
- Re-running the verification activities themselves
Specific to this review
- Bidirectional trace is checked in both directions: forward from requirements and backward from verification, because a break can hide on either side.
- Re-baselining is a frequent cause of trace decay, since links survive the version change but quietly point at the prior revision.
- Derived requirements are the trace's weakest point, often verified in design yet never returned to the safety assessment that should evaluate them.
- A trace can read complete by count while still failing the assurance-level objectives that govern how the coverage must be shown.
Sources
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
Is this different from a compliance matrix review?
Yes. A matrix review checks that each requirement has a means of compliance and current evidence. This review checks the links themselves, that the trace is unbroken in both directions and points at current objects.
Can you work directly in our trace tool?
We work from exports of the trace data, verification records, and requirements set. We do not need to modify the tool to confirm whether the chain holds.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Walk through your situation with an engineer who has done this work.