Certification-basis compliance matrix: EASA Part 21 and FAA

A certification-basis compliance matrix is the table that lists every requirement of the certification basis, states whether and how it applies to the design, names the means of compliance, and points to the compliance document that carries the evidence. EASA calls it the compliance checklist and expects it inside the certification programme under AMC 21.A.15(b). The FAA asks for the same document in the certification plan under Order 8110.4C. AI can populate most of the columns from the applicable specification and your design description. The applicability decision, the choice of means of compliance and the compliance statement remain engineering decisions that a named person signs.

What the regulators expect the matrix to contain

Under Part 21, point 21.A.15(b) requires the certification programme to include a proposal for the certification basis and a breakdown of the programme into compliance demonstration items, each with its proposed means of compliance and related compliance documents. AMC 21.A.15(b) turns that into a document: the applicant should provide a compliance checklist addressing each requirement, the proposed means of compliance using the codes in Appendix A, and the related compliance documents. The same AMC asks for the industry standards and methodology documents that will be followed, a description of test articles and test methods where testing is involved, and the tools and their validation where analysis is involved.

FAA Order 8110.4C, in paragraph 2-3d, requires every type certificate applicant to submit a certification plan and keep it current. The plan must contain the proposed certification basis with the applicable regulation paragraphs and sub-paragraphs at their amendment levels, exemptions, ELOS findings and special conditions, a description of how compliance will be shown, and a list of the documentation that will be submitted. The order states that the way to ensure all showings have been made is a compliance checklist addressing each applicable section of the regulations. The FAA side, including the scope rules for changes and STCs under 21.101, is covered in full in the guide on the FAA compliance checklist under 14 CFR Part 21; the military counterpart under EMAR 21 and STANAG 4671 is in the guide on the STANAG 4671 compliance matrix.

The means of compliance codes

Appendix A to AMC 21.A.15(b) defines ten codes and, for each, the kind of compliance document that goes with it. The codes are the vocabulary the matrix speaks with the authority, so use them exactly.

The columns of a matrix that survives the programme

A matrix that only satisfies the application is rebuilt three times before the type certificate. One that is built as the register the programme runs from carries these columns from day one.

• Requirement reference, with the amendment in the header and any special condition or equivalent safety finding numbered in the same series.
• Requirement summary, a few words, so the row can be read without opening the specification.
• Applicability, as applicable, not applicable or partial, and the rationale in a separate column. A "not applicable" with an empty rationale is a finding waiting to happen.
• Means of compliance, as codes, one row can carry several.
• Compliance document, by number and issue, one column per document if a row needs more than one.
• Compliance demonstration item, and its novelty, complexity and criticality flags, for an EASA programme.
• Owner, the engineer accountable for the row.
• Status, and a column for authority comments and findings.

Eight steps to build the matrix

1. Fix the certification basis before you open the spreadsheet. Record the certification specification and its amendment, the special conditions, equivalent safety findings, deviations and any elected requirements. Under the FAA, record the regulation paragraphs with amendment levels, exemptions, ELOS findings and special conditions. Put the basis in the header of the matrix and never build rows against "the latest" text.
2. Enumerate every requirement down to the sub-paragraph. List each paragraph and each lettered or numbered sub-paragraph of the applicable specification at the frozen amendment, one row each. Do not stop at section headings. This step is mechanical, which is why it is the first thing worth automating and the place where hand-built matrices silently lose rows.
3. Decide applicability and write the rationale. Mark each row as applicable, not applicable or partially applicable against the design description and the kind of operation requested. Every "not applicable" carries a one-sentence reason: the configuration is not present, the operation is not sought, the requirement addresses another product class. The rationale is what the authority reads first.
4. Assign the means of compliance. Give each applicable row one or more means of compliance codes, MC0 to MC9 under EASA, or ground test, flight test, analysis, similarity or another acceptable means under the FAA. The choice tells the authority how you intend to show compliance and defines the compliance documents you will have to produce.
5. Group rows into compliance demonstration items and classify them. For an EASA programme, group related rows into compliance demonstration items and state whether each item is novel, complex and critical. EASA uses that classification to set its level of involvement. Keep obvious cases short and explain the ones that are not.
6. Link every row to a numbered compliance document. Reference the compliance document by number and issue. Under AMC 21.A.20(c) each document should cite the certification specifications, special conditions or environmental protection requirements it addresses, contain the substantiation data, carry a statement by the applicant that it provides the proof of compliance it was created for, and an authorised signature, and be unequivocally identified by its reference and issue date. A row is not closed until that document exists.
7. Track status and findings row by row. Add a status per row, for example planned, in work, submitted, accepted or finding open, and a column for authority comments. The matrix becomes the register the programme is run from, not a deliverable that is produced once.
8. Keep the matrix under configuration control. Issue it like any other certification document, with a number, an issue and a date, and update it together with the certification programme as 21.A.15(c) expects. Any change to the design description reopens the applicability decision on the rows it touches.

What AI can draft and what the engineer decides

Most of the matrix is derivation from two controlled inputs: the specification at its frozen amendment and the design description. That is work a language model does well, provided it works only from those documents and cites the paragraph behind every proposal. The rest is judgement.

The conditions that make this safe are the ones set out in Can AI be trusted for aviation compliance documentation?: a controlled corpus that holds the specification at the right amendment and nothing else, citations at paragraph level on every proposed row, a boundary that stops users from altering that corpus, and a review that leaves a record of who accepted each row.

Five mistakes that produce findings

• Rows built against the wrong amendment. The specification was reissued between the application and the matrix, and the rows quote text that is not in the certification basis. Freeze the amendment first.
• "Not applicable" without a rationale. The authority cannot accept a decision it cannot read.
• A means of compliance with no document. A code is a promise. Rows that carry MC2 with no substantiation report number are open items, not compliance.
• The previous programme's matrix, renamed. Applicability was decided for another design and another operation. Reuse the structure, redo the decisions.
• A matrix that stops being updated after the application. Design changes reopen rows. If the matrix does not move with the design, the final statement of compliance under 21.A.20(d) rests on a document that no longer describes the product.

How Wingman360 Teammate builds one

The compliance-matrix workflow in Wingman360 Teammate starts from the certification specifications and special conditions that the organisation's administrators have ingested at the agreed amendment, together with the design description. It enumerates the requirements to sub-paragraph level, proposes applicability and means of compliance for each row with a citation into the source, and produces the matrix for engineering review. Engineers accept, edit or reject every proposed row, and nothing is signed by the system. The same approved knowledge base answers questions during the programme, so the matrix and the answers share one controlled source. Each deployment is a dedicated single-tenant instance in the customer's own cloud or on-premise, with a local model option so that no design data leaves the network.