Compliance matrix evidence review for quality teams

When this review is needed

• A data package is about to leave the building and quality wants the matrix pressure-tested before it does.
• A reviewer's finding disputes whether a specific row is actually supported or only marked complete.
• A design change reopens requirements the matrix still presents as fully compliant.
• The matrix was assembled by several engineers and no one has read every row against its evidence.

The problem

A compliance matrix ages badly. A row gets a means of compliance early, the requirement wording shifts, the substantiating report is revised twice, and the matrix still reads compliant because the cell was filled months ago. Quality inherits a document that looks finished, but the link from claim to evidence lives in an engineer's memory rather than in the record, and that engineer has moved to the next project.

What gets reviewed

• Every requirement in the certification basis reconciled against a matrix row so no basis item is silently uncovered
• The means of compliance recorded for each row checked against what the cited evidence actually demonstrates
• Cited evidence located and opened rather than accepted on the strength of a filename
• Rows marked compliant sorted into supported, partially supported, and unsupported
• Currency confirmed so each row points to the released revision, not a superseded draft
• Cross-references between related rows checked so a shared piece of evidence closes each claim it is cited for

What gets validated

• Each basis requirement maps to at least one matrix row and each row maps back to a basis requirement
• The means of compliance stated in a row matches the method the evidence documents rather than an aspiration
• Every cited artifact opens to the revision the matrix names, not an earlier or later one
• Rows touched by the most recent change show re-verified evidence or a written rationale for why none was needed
• No two rows cite the same evidence to close claims that piece of evidence cannot both support

Evidence normally required

• The compliance matrix as currently maintained, with its column definitions
• The certification basis and any issue papers or special conditions that shaped it
• The reports, analyses, and test records the matrix cites, at their released revisions
• The means-of-compliance agreement for the project
• Change records for any requirement or evidence altered since the matrix was last reconciled

Common discrepancies

• A basis requirement with no matrix row, uncovered because coverage was tracked by requirement count rather than by requirement
• A row citing a report revision the configuration process later superseded
• A means of compliance that reads as test in the matrix but is actually satisfied by analysis in the evidence
• A shared analysis cited to close two rows when it substantiates only one

What is at stake

A matrix that reads closed but does not resolve to evidence hands a reviewer an easy finding. They ask for the report behind one row, the report is not the revision the matrix cites, and a submittal that quality already blessed goes back into rework. Each disputed row pulls its dependent rows into question, and the schedule the program committed to slips while the trail is rebuilt.

How the work runs

What the buyer receives

• A gap list naming each row whose evidence is missing, stale, or mismatched to its claim
• An evidence map tying every compliant row to the artifact and revision that supports it
• A closure sequence ordering the gaps so enabling items are cleared before the rows that depend on them

Who uses the output

• Quality leadership deciding whether the matrix is fit to sign before the package ships
• Certification engineers who need a concrete list of rows to re-evidence or re-verify
• The team writing finding responses that must cite a row a reviewer can open and confirm

How the work fits into the transaction or program

The compliance matrix is the index a reviewer reads the whole data package through, so a weak matrix undermines evidence that is otherwise sound. This review sits between the engineering that produced the substantiation and the quality sign-off that releases it, catching detached rows while there is still time to reconnect them rather than after a reviewer has reached the same verdict.

Jurisdiction-specific considerations

FAA and EASA both expect the matrix to trace to the certification basis, but they arrive through different mechanisms: FAA project-specific certification plans and delegated findings on one side, EASA certification review items and means-of-compliance acceptance on the other. The same matrix often has to answer both, so the review reads each row against whichever basis and finding path the project is actually running under.

Regulatory limits

This review reads your own compliance matrix and reports where each row holds and where it breaks. It does not make an airworthiness determination, does not issue or accept a compliance finding, and does not replace the authority's or the delegate's review of the substantiating data.

What this review does not cover

• Authoring the missing reports or analyses a gap calls for
• Re-running the tests or analyses behind a row
• Rendering the compliance finding an authority or delegate reserves

Specific to this review

• Coverage gaps hide most easily when a matrix is checked by counting filled cells, because a missing requirement leaves no empty cell to notice.
• The most common failure is not an absent report but a report pinned to a requirement wording that has since been revised, which no cell count reveals.
• A row can read compliant and still fail review when the means of compliance in the matrix does not match the method the evidence used.
• Rows that share one piece of substantiation are a recurring trap, because a single analysis gets cited to close more claims than it actually supports.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits