Every Part 21J design office has a compliance matrix. Very few have one they trust.
The pattern is consistent. At the start of a certification programme, someone builds a careful spreadsheet: one row per applicable requirement, columns for the compliance document, the means of compliance, the verification evidence, and the status. On the day it is finished, it is accurate.
Then the programme moves. Documents get revised, evidence gets superseded, requirements get reinterpreted after a meeting with the authority — and each of those changes has to be manually reflected in the matrix by whoever remembers that the matrix exists.
Within a month, the matrix and reality have quietly diverged. Within six, the office has two sources of truth: the matrix everyone reports from, and the actual state of the documents, which only a few people know.
This article is about why that decay is structural, what it costs, and what a compliance matrix has to look like to stay correct without heroic maintenance.
Why Compliance Matrices Rot
A traceability matrix is a set of links: requirement to compliance document, document to verification evidence, evidence to approval. The spreadsheet version fails because none of those links are real.
A cell that says "CS 25.561 → Stress Report SR-042, Rev C" is not a link. It is a claim about a link, written by a person, at a moment in time. Nothing connects the cell to the actual document, so nothing updates the cell when the document changes.
That single design flaw produces every familiar failure mode:
- Revision drift. The matrix says Rev C; the approved document is now Rev E. The matrix is not wrong enough to be noticed, just wrong enough to be dangerous.
- Orphaned evidence. A test report is superseded after a re-run, but three matrix rows still point at the old one.
- Silent scope changes. A requirement's interpretation changes after an authority meeting, and the row's "compliant" status survives unexamined.
- Split ownership. Engineers own the documents; a compliance manager owns the matrix. Every update needs a handoff, and handoffs get skipped under deadline pressure.
None of this is carelessness. It is the predictable behaviour of a system where the record of the links is maintained separately from the things being linked.
What Rot Actually Costs
The decayed matrix does not fail loudly. It fails at exactly the moments when it is being relied on:
| Moment | What happens |
|---|---|
| Authority audit | A sampled row points at superseded evidence; a finding is raised on the process, not just the row |
| Submission preparation | Weeks of "matrix reconciliation" are added to the schedule to re-verify every row by hand |
| Change impact assessment | Nobody trusts the matrix to answer "which requirements does this document support?", so impact is assessed by memory and meetings |
| Engineer departure | The person who knew which rows were stale leaves; confidence in the whole matrix drops to zero |
The reconciliation cost is the most visible: offices routinely spend two to six person-weeks per major submission re-verifying traceability that was supposedly being maintained continuously. The audit exposure is the most expensive: a traceability finding invites the auditor to distrust everything else.
The Three Properties of a Matrix That Stays Correct
A compliance matrix that does not rot has three properties, and all three are about where the links live.
1) Links Are Attached to the Artefacts, Not Recorded Beside Them
The requirement-to-document relationship must be a first-class object in the same system that holds the documents. When the document is revised, the link is still attached — and the system can flag every requirement whose supporting document changed since the link was last reviewed.
This is the property spreadsheets structurally cannot have, and it is the one that eliminates revision drift.
2) Status Is Derived, Not Declared
In a spreadsheet, "compliant" is a value someone typed. In a living matrix, status should be computed from verifiable conditions: the linked compliance document exists, is at an approved revision, its evidence links resolve, and no linked artefact has changed since the compliance statement was approved.
If any condition breaks, the status degrades automatically — from "compliant" to "review required" — without waiting for a person to notice.
3) Every Link Change Is Attributable
When a link is created, redirected, or removed, the record should show who did it, when, and against which revisions. This turns the matrix from a reporting artefact into evidence in its own right: not just "we comply", but "here is the maintained, timestamped chain showing how we comply and how that chain has been kept current."
The Working Practices That Make It Stick
Tooling provides the properties above; discipline makes them routine. Four practices matter most.
Make Linking Part of Document Creation, Not a Separate Task
The moment a compliance document enters the system, its requirement links should be mandatory metadata — the document cannot progress to review without them. Traceability maintained as a separate periodic exercise is traceability that gets deferred.
Review Flagged Links, Not All Links
Once status is derived, the weekly traceability workload shrinks from "re-verify everything" to "disposition what the system flagged": documents revised under existing links, evidence superseded, requirements touched by a change. A programme with hundreds of requirements typically generates a handful of flags per week. That is a standing agenda item, not a project.
Treat Requirement Interpretation Changes as Change Events
When an authority meeting changes how a requirement is read, record it as an event against the requirement — which flags every linked compliance statement for review. This is the failure mode spreadsheets handle worst, because nothing in a spreadsheet connects a conversation in a meeting room to twelve rows that are now questionable.
Report From the Matrix, Never Beside It
The moment programme reviews use a separately maintained status slide, the matrix starts rotting again, because the slide becomes the thing people correct. Compliance dashboards should be views over the live links, with no manual re-keying in between.
Migrating Without Re-Keying Everything
The usual objection: "we have three years of programme history in this spreadsheet; we cannot start over."
You do not need to. Migration works best scoped and incremental:
- Pick the active certification programme, not the archive. Historical programmes can stay in the spreadsheet; they are no longer decaying in ways that matter.
- Import the matrix as claims, not facts. Each spreadsheet row becomes a draft link in the new system, marked unverified.
- Verify rows as they are touched. When a document is next revised or reviewed, its links get verified as part of that work. High-activity areas of the matrix — the ones where rot matters — get verified within weeks, naturally.
- Set a cutoff for the remainder. After a defined period, bulk-review whatever was never touched. Untouched rows are usually stable rows.
This spreads the verification cost across normal work instead of front-loading it as a project nobody has time for.
Signals Your Matrix Has Already Rotted
If two or more of these are true, assume the matrix diverged from reality some time ago:
- Submission preparation includes a scheduled "matrix reconciliation" phase
- The matrix has a single named owner, and updates queue behind that person
- Engineers describe the matrix as "the compliance manager's document"
- The last full verification of every row happened more than three months ago
- An auditor or reviewer has ever found a row pointing at a superseded document
Final Takeaway
A compliance matrix is not a document. It is a set of relationships between requirements, documents, and evidence — and relationships can only stay correct if they live where the artefacts live.
Spreadsheet matrices rot because they record claims about links instead of the links themselves. Every hour spent reconciling one is an hour paid for that design flaw.
The offices that walk into audits with confidence are not the ones with the most carefully maintained spreadsheets. They are the ones where traceability is a property of the document system itself — attached, derived, and attributable — so the matrix is correct for the same reason the documents are correct: it is the same system.