Type-design package, compliance matrix
Type-design data package compliance matrix support
This support readies the compliance matrix at the center of a type-design data package so it holds up under FAA or EASA review. It confirms every requirement in the certification basis has a stated means of compliance and a current piece of evidence, then flags entries whose cited evidence no longer supports the claim. A certification engineer runs it while the package is being assembled. You receive a gap assessment against basis coverage, an evidence map from each matrix line to its source, and a closure plan for the stale or empty entries.
When this review is needed
- A type-design data package is being assembled and the compliance matrix has to map every basis requirement to evidence.
- The certification basis was updated and the matrix has not been re-checked against the new requirements.
- Evidence has been revised since the matrix was built and some citations may point at superseded data.
- A dual FAA and EASA submission needs a matrix that satisfies both authorities' expectations.
The problem
The compliance matrix is the map a reviewer uses to navigate an entire data package, so a broken entry misdirects the whole review. It ages badly: requirements shift when the basis is updated, and evidence gets revised underneath citations that still point at the old version. A supplier building a package over months ends up with a matrix that looked complete when written but has drifted from both the basis above it and the evidence below it.
What gets reviewed
- Coverage of every certification basis requirement by a matrix entry
- A stated means of compliance appropriate to each requirement
- Evidence citations confirmed to point at current, supporting data
- Entries reconciled after any update to the certification basis
- Consistency of the matrix across FAA and EASA expectations where both apply
- Traceability from each matrix line to the artifact that substantiates it
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 in the certification basis appears in the matrix with a means of compliance
- Each evidence citation resolves to current data that actually supports the claim
- The means of compliance stated fits the requirement rather than a generic default
- Basis updates are reflected in the matrix rather than left against superseded requirements
- The matrix addresses both authorities' requirements where the submission is dual
Evidence normally required
- The current certification basis for the type-design change
- The compliance matrix in its present state
- The evidence artifacts the matrix cites
- Any revisions to the basis or the evidence since the matrix was built
- The submission scope, including whether it is FAA, EASA, or both
Common discrepancies
- A basis requirement with no corresponding entry in the matrix
- An evidence citation that points at a revision superseded by later data
- A means of compliance stated generically where the requirement needs a specific method
- A dual-submission matrix that satisfies one authority but leaves the other partly addressed
What is at stake
A matrix with entries that cite evidence no longer supporting the claim sends the reviewer to the wrong place and erodes confidence in the rest of the package. On a dual submission, a matrix built for one authority's expectations can leave the other's requirements only partly addressed, splitting the project into two reconciliation efforts late in the schedule.
How the work runs
Anchor to the basis
Confirm the current certification basis and that every requirement in it has a matrix entry.
Verify the citations
Check that each cited piece of evidence is current and actually supports the claim it backs.
Reconcile after changes
Update entries left against superseded basis requirements or revised evidence.
Close the gaps
Sequence the empty, generic, or stale entries for correction before the package is submitted.
What the buyer receives
- A gap assessment against certification basis coverage
- An evidence map from each matrix line to its supporting artifact
- A closure plan for the stale, generic, or empty entries
Who uses the output
- Certification leads confirming the matrix covers the basis before it goes out
- Engineering leads correcting entries that cite evidence no longer supporting the claim
- Configuration management keeping the matrix aligned with the evidence baseline
How the work fits into the transaction or program
The compliance matrix is the index to the whole type-design package, so this review runs across the package rather than one artifact. It confirms the map is accurate before a reviewer follows it, which is what keeps the review moving line by line instead of stalling at the first entry that leads nowhere.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA expect the same basis coverage demonstrated in different structures, so a dual submission needs the matrix checked against both rather than built for one and assumed to satisfy the other. The review notes where an entry sufficient for one authority leaves the other's requirement only partly addressed.
Regulatory limits
The review confirms the matrix covers the basis and cites current evidence, and marks the entries that fall short. Making a compliance finding, accepting a means of compliance, approving the data package, and determining airworthiness all rest with the authority.
What this review does not cover
- Producing the evidence a matrix entry depends on
- Accepting or approving a means of compliance on an authority's behalf
- Any approval or airworthiness determination on the type-design change
Specific to this review
- The matrix is the reviewer's index to the package, so one entry that leads nowhere slows the read of everything after it.
- Matrix entries age when the basis is updated above them or the evidence is revised beneath them, often silently.
- A dual FAA and EASA matrix has to be checked against both authorities, because coverage for one does not guarantee coverage for the other.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Why does the matrix drift even when nothing seems to have changed?
The basis and the evidence move independently of the matrix. A basis update adds or changes a requirement, and an evidence revision replaces the data a citation points at, both without touching the matrix line. Over a long package build, those small shifts accumulate into entries that no longer support their claims.
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.
Talk through the aircraft, records, evidence, deadline, and next useful step.