Requirements Traceability Matrix

01 Why a production RTM traces to acceptance, not completion

On a software program, a requirement is satisfied when its code is written and its test passes — the trace terminates in completion. On a fixed-price production program, that is not enough. A characteristic is not satisfied when a panel is made; it is satisfied when a panel is accepted — verified against the drawing, substantiated by evidence, and either passed at First Article or shown to be in control at rate. A part can be manufactured and still be rejected; a manufactured-but-rejected characteristic is not a satisfied one. So this matrix, like the program's fixed-price commercial reality, terminates in acceptance.

The chain is manufacturing-specific and four links wide: Control Plan characteristic → verification method → FAI evidence record → acceptance path. The first link is the requirement (what the part must be), the second is how it is checked, the third is the objective evidence that the check happened and passed, and the fourth is the standard by which that evidence is judged — once at First Article, and then continuously in production. Reading a row left to right is reading a single characteristic from its definition to its acceptance.

Why the evidence record is a first-class link, not a footnote

In a software RTM the evidence is a test result, and one automated test can be re-run on demand to reproduce it. On a production program the evidence is a physical record of a physical event that happened once and cannot be repeated: the autoclave cure cycle that produced a specific panel, the ultrasonic scan of that panel, the certification of the prepreg lot it was built from. Those records are the AS9102 First Article evidence, captured on Form 3 Characteristic Accountability, and they are auditable objects with retention requirements — a characteristic is not accepted on an assertion that it was verified, but on the retained record proving it. That is why this matrix names the specific evidence record for each characteristic rather than a generic "verified" flag: the record is the traceability, and for a flight-structure part it must survive long after the people who made it have moved on.

02 Coverage summary

Why there is no priority column

The commercial and software RTMs in this portfolio carry a MoSCoW priority (Must / Should / Could) because their requirements can be descoped — a "Should" can slip to a later release. This matrix has no such column, and its absence is deliberate. Every characteristic on a flight-structure drawing is mandatory; there is no "Should" edge trim and no "Could" bond-line. What varies on this program is not whether a characteristic must be met but how intensively it is inspected once the process proves capable — and that is exactly what the class and acceptance columns capture. Replacing a priority column with a class-and-acceptance scheme is the single clearest way this production RTM differs from its software siblings: nothing here is optional, so the interesting axis is inspection intensity over the life of the program, not scope.

03 Key Characteristics (6 — accepted 100%, for the life of the program)

Key Characteristics affect fit, structure or safety, so their acceptance never relaxes. Each is verified 100%, substantiated by an FAI evidence record at First Article, and then held at 100% with SPC monitoring at rate — the sampling transition that applies to standard characteristics never reaches them.

04 Critical process parameters (5 — accepted per cure cycle)

Critical process parameters are accepted differently because they are not features on a part — they are conditions during its making. Their acceptance evidence is the automated cure record for the cycle that produced the part, retained for 100% of cycles. A part cannot be accepted if the cure record for its cycle shows an un-dispositioned excursion, because the property that excursion affects cannot be recovered by inspecting the finished part.

05 Standard characteristics (3 — the only class eligible for sampling)

Standard characteristics are fully traced and fully verified at First Article — I-01 (edge trim, a standard characteristic) proved they can stop an inspection — but their acceptance basis relaxes to sampling once the process demonstrates statistical capability, and reverts to 100% automatically if capability is lost.

06 The three families of acceptance evidence

The evidence column in the tables above resolves to a small number of record types, and grouping them shows how a composite part's traceability is actually assembled. Each family substantiates a different kind of characteristic, and together they cover the part from the material it started as to the finished geometry it became.

07 The acceptance chain in the program timeline

The matrix's acceptance column maps onto real program milestones. First Article Inspection is the one-time validation that every characteristic can be met; production acceptance is the ongoing confirmation that it continues to be.

08 Traceability gaps — recorded, not hidden

An RTM that reports flawless coverage is not being maintained. These are the genuine open items this matrix surfaces about the current state of the traceability apparatus.

09 How this matrix sits in the suite

This matrix is the binding layer between the aerospace suite's requirements and its quality evidence. It traces from the Control Plan (the characteristics), through the Inspection, Test & Verification Strategy (the methods and the sampling transition), to the First Article Inspection (the AS9102 evidence and the acceptance gate), with the Material Review Board as the path for any characteristic that fails acceptance. Together with the Control Plan it gives the aerospace suite the same requirement→verification→acceptance discipline the PM, Federal and Catalyst suites carry — expressed in the language of AS9100 production quality rather than software requirements, because that is what this program actually is — a fixed-price manufacturing effort whose deliverable is an accepted physical part, not a body of tested code.