Means-of-compliance map
Means-of-compliance map evidence review for equipment suppliers
This review examines the means-of-compliance map a supplier plans to submit for a piece of airborne equipment. It reads every requirement against the method chosen to show compliance, then confirms that method actually produces an artifact and that the artifact traces back to the certification basis. An engineer who knows how compliance findings are structured runs it before a data submittal, ahead of a finding response, or when a design change reopens methods already claimed. You get a gap list of requirements assigned a method but no evidence, a corrected evidence map, and a closure sequence engineering leadership can work.
When this review is needed
- A data package is about to go to the authority and the compliance map has not been checked end to end against the artifacts it points to.
- A finding asks the supplier to justify why a chosen method is adequate for a specific requirement.
- A design change alters an interface or function and the methods previously claimed for affected requirements need to be revisited.
- A program inherited a compliance map from an earlier baseline and no one has confirmed the methods still match the current requirement set.
The problem
The compliance map often reads cleanly on its own: every requirement has a method in the cell next to it. The trouble sits one layer down, where the method points at an analysis that was never finished, a test that covered a different configuration, or a document reference that no longer resolves. Suppliers discover this only when a reviewer follows the pointer and finds nothing at the other end.
What gets reviewed
- Requirement-by-requirement read of the assigned compliance method against the artifact it names
- Confirmation that each method resolves to a specific, dated piece of evidence rather than a placeholder
- Trace from every mapped requirement up to the applicable certification basis paragraph
- Check that the method chosen is credible for the requirement type, not merely present
- Identification of requirements carrying a method but no evidence path at all
- Review of how the map handles derived requirements that have no parent in the basis
What gets validated
- Every requirement in the map names a compliance method and the method points to a locatable artifact
- Each cited artifact covers the requirement's configuration and function, not an adjacent one
- The certification basis paragraph behind each requirement is the current applicable one
- Test, analysis, and inspection methods are matched to requirements they can actually substantiate
- Requirements marked closed have an artifact that a reviewer could open and read today
Evidence normally required
- The means-of-compliance map or compliance matrix in its current revision
- The requirement set the map is built against, with derived requirements flagged
- The certification basis or issue paper set the program is working to
- References or links to the artifacts each method cell points at
- Any authority correspondence that has already questioned a method
Common discrepancies
- Requirements assigned a method that resolves to a document not yet written
- Test-by-similarity claims where the similar article differs in a way that matters
- Derived requirements sitting in the map with no basis trace and no rationale
- Method cells copied forward from a prior program that no longer fit the current design
What is at stake
A method with no artifact behind it turns into a finding at exactly the moment a supplier can least absorb it, late in the review with the delivery date fixed. Each unsupported cell forces a scramble to generate evidence retroactively or renegotiate the method, and every such cell erodes the reviewer's confidence in the cells that are actually sound.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Read the map against the artifacts
Walk each requirement from its assigned method to the specific evidence the method names and record where the pointer fails to resolve.
Trace up to the basis
Confirm each requirement links to a current certification basis paragraph and flag derived requirements lacking a rationale.
Test method credibility
Judge whether the chosen method can actually substantiate the requirement type rather than merely occupying the cell.
Sequence the closures
Order the missing evidence by lead time and dependency so the longest-pole artifacts start first.
What the buyer receives
- A gap list naming each requirement whose method lacks a supporting artifact
- A corrected evidence map linking method, artifact, and basis paragraph for every requirement
- A closure sequence ordering the missing artifacts by dependency and lead time
Who uses the output
- Engineering leadership deciding what evidence must be generated before submittal
- Certification leads assembling the compliance argument for the authority
- Project engineers who own writing the missing analyses and test reports
How the work fits into the transaction or program
The compliance map is the spine the rest of the data package hangs from, so it is checked before the individual reports are polished. Findings here feed the requirements trace and verification trace reviews, which confirm the artifacts the map now points at hold up on their own.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect a legible line from requirement to method to evidence to basis, but they organize the certification basis differently, and issue papers or certification review items can add project-specific requirements the map must also carry. The review notes where a method that satisfies one authority's expectation would draw a question from the other.
Regulatory limits
This is a review of the supplier's own evidence logic. It makes no airworthiness determination, grants no approval, and does not decide whether a method is acceptable to the authority. That determination stays with the certifying authority and its delegated engineers.
What this review does not cover
- Writing the missing analyses, test reports, or substantiation the map points at
- Negotiating method acceptability directly with the authority
- Assessment of the physical equipment or its installation
Specific to this review
- A compliance map can be complete on its face and still be hollow, because a filled method cell says nothing about whether the artifact behind it exists.
- Derived requirements are the usual weak point: they enter the map without a basis parent, so they are easy to leave without a rationale or a method.
- The most expensive gaps are late test-driven ones, because a missing test cannot be closed by writing prose the way a missing analysis sometimes can.
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.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Do you decide whether our chosen methods are acceptable to the authority?
No. We check that each method resolves to real evidence and traces to the basis so your argument holds together internally. Whether a specific method is acceptable is a determination the authority and its delegated engineers make, and this review is meant to have your package ready before that conversation.
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.