Compliance matrix
Compliance-matrix evidence review for software assurance teams
This review checks that a software compliance matrix still says something true, entry by entry. It runs before a submittal, during a finding response, or after a change churns the evidence the matrix points at, and it is done by or with the software assurance team that owns the compliance argument. The work examines objective coverage, the means of compliance claimed for each line, and whether the cited evidence still supports the claim it is attached to. It flags every entry that points at a document that has moved, changed, or stopped substantiating the objective. You receive a gap list, an evidence map tying each matrix line to live evidence, and a closure sequence for software assurance leadership.
When this review is needed
- A software compliance matrix is about to be submitted and each entry needs checking against the evidence it cites.
- A finding questions whether an objective marked satisfied is actually supported by the referenced document.
- A change churned the evidence base and the matrix has not been re-walked against the current artifacts.
- The matrix was maintained across a long program and links have quietly gone stale.
The problem
A compliance matrix is only as honest as its most out-of-date cell. It is built early, marked up as work completes, and then relied on as the map an authority follows through the data package. But the evidence it points at keeps changing: a report is reissued, a plan is revised, a review record is superseded, and the matrix cell still cites the old artifact by a reference that no longer resolves to what it claims. The team maintaining the matrix rarely re-reads every citation, so the rot is invisible until someone follows a link.
What gets reviewed
- Objective coverage checked so every applicable objective at the software level has a matrix entry
- The means of compliance claimed for each entry checked for consistency with the evidence type it cites
- Evidence citations resolved to confirm the referenced artifact exists and is current
- Each cited artifact read enough to confirm it still substantiates the claim on the line
- Entries affected by recent changes re-checked against the artifacts as they now stand
- Matrix references checked against the certification basis and the applicable software level
What gets validated
- Every applicable objective for the software level appears in the matrix with no silent omission
- The means of compliance on each line matches the kind of evidence the citation actually points to
- Each cited reference resolves to a real, current artifact rather than a superseded or missing one
- The cited artifact, when read, still supports the specific claim the matrix makes for it
- Entries touched by the most recent change reflect the artifacts as they now stand
Evidence normally required
- The software compliance matrix in its current state
- The evidence artifacts the matrix cites, at their current revisions
- The applicable objectives for the software level under review
- The change history covering recent churn in the evidence base
- The certification basis and any prior findings on the matrix
Common discrepancies
- A matrix entry citing a report that has since been reissued at a revision the reference does not point to
- An objective applicable at the software level that has no matrix entry at all
- A means of compliance that does not match the evidence type the line actually cites
- An entry marked satisfied whose cited artifact no longer contains the result it is credited with
What is at stake
A matrix entry that cites dead or changed evidence sends an authority to a document that does not substantiate the objective, which reads as a compliance gap even when the underlying work was done. Chasing down the real evidence mid-review costs time the schedule did not budget, and a pattern of stale citations undermines confidence in the whole matrix, inviting deeper scrutiny of entries that were actually fine.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm objective coverage
Check that every applicable objective for the software level has a matrix entry.
Resolve every citation
Follow each reference to confirm the artifact exists at the revision the line claims.
Read the evidence
Confirm the cited artifact still substantiates the specific claim the entry makes.
List and order the gaps
Record each stale or mismatched entry and sequence re-citation before dependent re-verification.
What the buyer receives
- A gap list naming each entry with missing, stale, or mismatched evidence
- An evidence map tying every matrix line to a live artifact at its current revision
- A closure sequence ordered so re-cited evidence is settled before dependent entries are re-verified
Who uses the output
- Software assurance leadership confirming the matrix holds up before it anchors the submittal
- Assurance engineers correcting the entries flagged as stale or unsupported
- Certification leadership judging whether the matrix is submission-ready or needs a currency pass
How the work fits into the transaction or program
The review runs over the matrix once the evidence exists but before the matrix is used as the authority's map through the package. It confirms every line still resolves to live support, and its gap list drives the re-citation and re-verification that keep the matrix honest at submittal.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-178C objectives as the software compliance framework the matrix is built on, but they attach the matrix to their own submittal and stage-of-involvement expectations. The review notes where a matrix structured for one authority needs re-mapping or additional annotation to serve as the compliance map for the other.
Regulatory limits
The review checks that matrix entries cite live, supporting evidence. It does not accept the matrix, make a compliance finding on any objective, or determine that the software meets its assigned level. Those determinations rest with the applicant's authorized representatives and the authority.
What this review does not cover
- Producing the underlying software life-cycle evidence the matrix cites
- Accepting the matrix or making a compliance finding on any objective
- Assigning or changing the software level for the item under review
Specific to this review
- A compliance matrix decays by reference, not by content: the cell text stays plausible while the artifact it points at moves out from under it.
- The most damaging entries are the confidently marked ones, because a satisfied objective citing dead evidence is read as a gap the moment the link is followed.
- Objective omissions hide better than stale citations, since a matrix that is internally tidy can still be silently missing an applicable objective for the level.
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
The matrix is under configuration control. Doesn't that keep the links current?
Control keeps the matrix document versioned, but it does not re-check that each cited artifact still says what the entry credits it with after that artifact is reissued. Following the citations and reading the evidence is what the review adds.
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.