Ask anyone who has sat through a Stage of Involvement review or a functional safety assessment, and they will tell you the same thing: most findings are not about bad engineering. They are about evidence that could not speak for itself.
The requirement was implemented. The test was run. The review did happen. But the records live in five different places, maintained by hand, and somewhere between the spreadsheet, the review minutes, and the change log, the thread broke. The auditor is not obliged to assume the thread exists — they are obliged to see it.
Here are five findings we have seen repeatedly across DO-178C, ISO 26262, and EN 50128 programs. Each one is written the way an auditor would actually record it. And each one has the same root cause.
01 - Traceability could not be demonstrated from software requirement to test case
As written by the auditor“For sampled requirements REQ-1042 and REQ-1187, the traceability matrix references test procedures that do not exist in the delivered verification cases index. Bidirectional traceability between software requirements and test cases could not be established.”
What actually happened: The trace matrix is a spreadsheet, maintained separately from the test procedures. A test procedure was renamed during a late verification cycle. The spreadsheet was not updated. Nobody noticed, because nothing forced the two artifacts to agree.
The root cause: Traceability maintained beside the artifacts instead of between them. The moment trace data is a copy of reality rather than a view of it, it starts to rot.
02 - Requirement changes implemented without documented change authorization
As written by the auditor“Software requirement REQ-2210 at baseline BL-4.2 differs from the version reviewed at SOI-2. No problem report or change request authorizing the modification was presented.”
What actually happened: During integration, an engineer clarified the wording of a requirement — a “harmless” edit. The change went into the document. The CR was going to be raised later. Later never came, and the baseline now contains a requirement version that no review record covers.
The root cause: The requirement text, the change record, and the review record live in three systems that do not talk to each other. Nothing in the workflow makes an unauthorized edit visible, so it survives until an auditor samples exactly that requirement.
03 - Review records do not demonstrate that review criteria were applied
As written by the auditor“Review records for the software requirements data consist of signed checklists with no evidence of findings, dispositions, or the requirement versions reviewed. The records do not demonstrate that the review criteria defined in the SVP were applied.”
What actually happened: Reviews genuinely took place — around a table, with markups on printouts or comments in email. The checklist was signed at the end as a summary. The substance of the review (what was checked, what was found, what was fixed, against which version) evaporated because it was never captured in a structured way.
The root cause: Review evidence is reconstructed after the fact instead of accumulating during the review. A signature proves attendance; it does not prove scrutiny.
04 - Verification evidence does not correspond to the baselined requirement version
As written by the auditor“Test results presented for REQ-3104 were produced against requirement revision C. The certification baseline contains revision E. No re-verification analysis or delta justification was provided.”
What actually happened: The requirement changed twice after the test campaign. The impact was assessed informally — “the change does not affect the test” — but that judgment was never recorded. On paper, the program is presenting evidence for a requirement that no longer exists.
The root cause: No live link between requirement versions and the evidence that verifies them. When the link is a human memory, re-verification decisions are invisible, and invisible decisions are findings.
05 - Lifecycle data inconsistent across plans, records, and delivered artifacts
As written by the auditor“The SVP defines a two-stage review cycle with independence for Level B requirements. Sampled review records show single-stage reviews. The SCI lists document revisions that differ from those presented during the audit.”
What actually happened: The plans were written at the start of the program. The process evolved under schedule pressure. The records reflect what the team actually did; the plans reflect what the team intended to do two years earlier. Each document is internally consistent — they are just not consistent with each other.
The root cause: Cross-document consistency is checked manually, occasionally, usually right before an audit. Disconnect between plans, records, and artifacts is not an event; it is a slow drift that nobody owns.
One root cause, five symptoms
Look at the pattern. In every finding, the engineering work was done — or very nearly done. What failed was the connective tissue: trace data copied instead of linked, changes made without a visible authorization path, reviews summarized instead of captured, evidence detached from the versions it verifies, and documents drifting apart in silence.
Spreadsheets and file shares cannot fix this, because the failure mode is the manual synchronization between them. Every additional artifact multiplies the number of threads someone must keep aligned by hand — and audit sampling is designed to find the one that snapped.
This is the problem PES was built around. One thread connects the requirement, its versions, its reviews, its change authorizations, its downstream design and test artifacts, and the evidence that verifies it. When a requirement changes, the impact is a lookup, not archaeology. When an auditor samples REQ-1042, the record answers before you do.
Audit readiness should be a standing state, not a scramble.
