Your safety case is rotting in a spreadsheet

Every safety program I have joined owned at least one load-bearing spreadsheet. The requirements matrix. The FMEDA. The verification tracker with the colored cells. Each one was created by a competent engineer solving a real problem quickly — and each one was quietly destroying the program’s ability to defend its safety case.

This is not a tooling-snobbery argument. Spreadsheets are excellent at what they were built for. The problem is specific: a safety case is a living claim structure that must survive change, and spreadsheets have no defensible relationship with change.

How the rot actually happens

The failure is never dramatic. It accumulates:

• A requirement is reworded in the requirements sheet, and the eleven analysis rows that referenced its old wording keep referencing it. Nothing flags this. The trace looks intact; it is now fiction.
• A column gets sorted while a filter is active, and half the verification statuses silently migrate to the wrong rows. Anyone who has run a large program in spreadsheets has a version of this story, and most found out months later.
• “Final_v3_reviewed_JK.xlsx” and “Final_v3_reviewed_JK(1).xlsx” both exist, both diverged, and both have been sources for downstream documents.
• The assessor asks: when was this requirement last changed, by whom, and which analyses were revisited as a consequence? The honest spreadsheet answer is silence. There is no history, only the current state — and a safety argument without history is an assertion, not evidence.

That last question is the one that matters. An assessment is not a review of your documents; it is an interrogation of whether your evidence chain survives your own change process. Impact of change is exactly where spreadsheets have nothing to say.

What evidence management actually requires

Strip away vendor language and the requirement list is short:

1. Identity. Every requirement, analysis, and piece of evidence has a stable identifier that survives rewording and reorganization.
2. Traceability as data, not convention. Links between safety goals, requirements, analyses, and verification results are first-class objects that can be queried — “show every safety goal whose evidence is not up to date” must be a question the system can answer, not a two-day manual audit.
3. Append-only history. Changes are recorded, attributed, and immutable. Not because engineers are dishonest, but because impact of change is a safety activity, and you cannot assess the impact of changes you cannot see.
4. Suspicion propagation. When a requirement changes, everything that depends on it becomes suspect until re-reviewed. This single mechanism is most of what “living safety case” means in practice.

Commercial requirements platforms provide this, and for large organizations they are often the right call. But there is a real gap in the middle: teams too small or too fast-moving for a heavyweight deployment, for whom the practical alternative has been — spreadsheets.

What I built instead

On my current program I closed that gap by building the tool: a requirements-management web application with append-only history enforced by database-level immutability triggers, attributed sessions, and traceability as the core data model — delivered end-to-end as a solo engineer, with AI-assisted development doing the acceleration. I am not claiming every team should build its own tooling. I am claiming the barrier has collapsed: purpose-built evidence management, shaped exactly to one program’s safety workflow, is now weeks of effort rather than a procurement cycle. The technology in that sentence matters less than the design decision it enabled: immutable history and queryable traceability are not enterprise luxuries anymore.

A test you can run today

Pick one safety requirement at random and try to answer, from your current tooling, in under ten minutes: What is its verification status? What evidence supports that status? When did the requirement last change, and was the evidence produced before or after that change?

If the answer involves opening more than two files or asking a colleague what they remember, the safety case is already rotting — the assessment just hasn’t found the soft spot yet. Fixing it is not a documentation exercise. It is an engineering project with a data model, and it is smaller than you think.