Almost every DO-178C programme starts with the same honest intention: keep a traceability matrix in a spreadsheet, update it as work progresses, and hand it over at the audit. Almost every one of them discovers, somewhere around SOI-3, that the matrix and the artifacts no longer agree.
This is not a discipline problem. Teams that fail this way are not lazy — they are usually the ones working hardest, because keeping a separate document synchronised with a moving project is genuinely enormous manual effort. The problem is structural, and it is worth naming precisely.
The structural problem: a copy, not a view
A spreadsheet matrix is a copy of relationships that live somewhere else. The requirement lives in a requirements document. The test procedure lives in the verification cases. The code lives in the repository. The spreadsheet holds identifiers that point at all three — and nothing in the system forces those pointers to remain true.
Rename a test procedure and the spreadsheet does not know. Split a requirement into two and the spreadsheet does not know. Delete a function and the spreadsheet still cheerfully claims coverage. The matrix is correct only for as long as a human keeps making it correct, and it fails silently rather than loudly.
Why auditors sample rather than read“For sampled requirements REQ-1042 and REQ-1187, the traceability matrix references test procedures that do not exist in the delivered verification cases index.”
An auditor does not need to check every row. They pull a handful and follow each one end to end. A matrix that is 98% accurate is not 98% of the way to compliance — it is one unlucky sample away from a finding, because the sample is chosen to find exactly this.
What DO-178C actually asks for
The word usually used is bidirectional. It matters more than it sounds. Forward traceability answers “is every requirement implemented and verified?” Backward traceability answers the harder question: “does every piece of code and every test exist because a requirement asked for it?”
Backward traceability is what surfaces derived requirements that were never fed back to the safety assessment, and code that nobody can justify. A spreadsheet can represent both directions in principle. In practice, the reverse direction is the one that rots first, because nothing in the daily workflow of writing code and tests ever prompts anyone to update it.
Trace data is also not one relationship but a chain: system requirements to high-level requirements, HLRs to low-level requirements, LLRs to source code, and requirements to test cases and their results. Each link has to hold. Each additional artifact multiplies the number of pointers a human has to keep aligned by hand.
Side by side
| Situation | Spreadsheet matrix | Single thread |
|---|---|---|
| A test procedure is renamed | Link silently becomes wrong. Discovered at audit, if at all. | The link follows the artifact. Nothing to update. |
| A requirement changes | Impact assessed from memory. Affected tests found by asking around. | Impacted design, code, and tests listed before the change is committed. |
| Coverage question at review | Someone rebuilds the matrix the week before, from the artifacts as they now stand. | Coverage is a current view, available at any moment. |
| Requirement is split in two | One row becomes two by hand. The old identifier lingers in other tabs. | Both parts inherit and extend the existing links. |
| Auditor samples a requirement | The team traces it manually to confirm the row is still true. | The record answers, with versions and review history attached. |
| Evidence versus baseline | Matrix reflects today. The baseline may be three revisions behind. | Each link carries the artifact version it was established against. |
The right-hand column is not a claim about a product. It is a description of what changes when trace data stops being a separate document and becomes a property of the artifacts themselves.
The tell-tale symptom
There is a reliable way to know which side of this line a programme sits on. Ask how long it takes to answer this question:
The five-minute test“REQ-2210 changed yesterday. What else is affected, and what has to be re-verified?”
If the answer takes minutes, the thread is intact. If it takes days, requires two engineers and a meeting, or produces an answer nobody fully trusts, the matrix has already decayed — the audit simply has not found it yet.
The same test predicts cost. Programmes that answer in minutes spend their certification budget on engineering. Programmes that answer in days spend it on reconstruction: rebuilding evidence that was never captured as the work happened, and repeating reviews because the records did not show what was checked.
Spreadsheets are not the enemy
A spreadsheet is an excellent tool for a small, stable, finished set of relationships. Plenty of Level D projects ship perfectly well with one, and there is no virtue in tooling for its own sake.
What a spreadsheet cannot do is stay true across a multi-year programme where requirements move, tests are rewritten, staff turn over, and an auditor arrives at the end expecting the record to speak for itself. At that scale the matrix is not documentation of the work — it is a second project running alongside the first, staffed by the same people, and the first project always wins when schedule pressure arrives.
This is the problem PES was built around: one thread connecting requirements, their versions, their reviews, their change authorisations, and the evidence that verifies them. When a requirement changes, impact is a lookup rather than archaeology. When an auditor samples REQ-1042, the record answers before you do.
