This is the sixth and final part of a guest blog series titled "The Death of Static Safety". Today, we wrap things up by discussing how to keep safety cases alive - extending certification into runtime. But first, if you haven't read any of the previous articles, we invite you to do so by following these links.
Part 1. Why Safety Certification Assumptions Don’t Survive Reality
Part 2. Validating Operational Assurance as a Safety Mechanism
Across this series, a consistent pattern has emerged. Static safety decays after deployment. Any mechanism that influences behavior at runtime must be treated as a safety mechanism. Centralized enforcement creates unacceptable risk. Even well-architected enforcement can introduce hazards if it is not analyzed as a control.
These are not isolated concerns. Together, they point to a single conclusion: certification alone is no longer sufficient to ensure safety over the operational life of modern systems.
ISO 26262 has always relied on assumptions. That is not a weakness. It is the only way complex systems can be certified at all. A safety case demonstrates that, under defined conditions, the system is acceptably safe. ISO 26262 was designed for stability. It was never intended to address the functional inadequacy or ODD completeness challenges (the SOTIF domain) that now dominate the SDV landscape.
What certification does not do is guarantee that those conditions will remain true indefinitely after deployment.
Historically, that gap was manageable. Vehicles changed slowly. Software was largely fixed. Operational environments were predictable enough that assumption drift was limited.
That is no longer the world these systems operate in.
Software-defined vehicles evolve continuously. Operating domains expand. Fleets accumulate long-tail experience. Machine-learned components interact with the environment in ways that cannot be fully bounded at design time. The system running is no longer the one that was certified.
The safety case does not fail. It becomes historical.
As systems evolve, the underlying question begins to change. Increasingly, the issue is no longer only whether a system was certified. The issue becomes whether it was behaving as certified at the time of operation.
That shift is subtle, but it has significant implications. A certificate is evidence of due diligence at a point in time. Operational behavior is evidence of whether that diligence remains relevant. When those diverge, certification alone is no longer sufficient.
This is the assurance gap: the space between a static safety argument and a dynamic, evolving system.
Operational assurance does not exist to replace the safety case. It does not redefine hazards, rewrite safety goals, or introduce new safe states. All of those remain grounded in the original certification work.
What operational assurance provides is continuity.
It monitors whether certified assumptions remain valid. It enforces constraints that were already derived during development. It produces evidence that the system remains within its validated safety envelope, or that it transitions safely when it does not. Without that continuity, certification becomes a historical artifact. With it, certification remains a living claim.
The Systems Chain of Record (SCoR) provides a "Golden Thread" of evidence that keeps the safety case alive after deployment.
Safety cases have always depended on evidence. Traditionally, most of that evidence was produced before deployment. In modern systems, that is no longer sufficient.
Runtime monitoring, enforcement outcomes, and immutable operational records become part of the safety argument. They do not replace design-time evidence. They extend it by showing that assumptions have not silently expired.
This is not about predicting every failure. It is about detecting when the boundaries of certification are being approached or crossed and responding in ways that have already been analyzed and approved.
The most important shift is conceptual. Safety can no longer be treated as something that is achieved and then assumed. In software-defined, continuously evolving systems, safety is an operational property. It must be maintained, evidenced, and defended over time.
Operational assurance enables that shift without abandoning the discipline of functional safety. It works precisely because it respects existing standards rather than bypassing them.
Static safety is not disappearing because it was wrong. It is giving way because the systems it governs have changed.
Certification remains essential. But without operational assurance, it describes what was once true about the fault-logic and functional performance, not what is true in the field today.
Keeping the safety case alive requires extending it into runtime. Anything less leaves organizations relying on assumptions they can no longer verify.
LHP Operational Assurance Systems (OAS) was spun out of LHP Engineering Solutions to address a growing gap in safety-critical, software-defined systems: certification at launch no longer guarantees safe operation over time. As complex platforms began receiving continuous software updates and evolving functionality, LHP OAS recognized that traditional "certify-once" models could not prevent runtime drift between validated safety intent and real-world behavior. Drawing on decades of leadership in functional safety, cybersecurity, and systems engineering, LHP OAS was formed to focus exclusively on extending certified intent into live environments and developed a platform, Operational Assurance Sentinel, that embodies this concept. LHP's Operational Assurance Sentinel platform delivers deterministic runtime enforcement, operational assurance scoring, and tamper-evident evidence chains that transform safety from a static milestone into a continuously verifiable discipline, enabling organizations to deploy advanced autonomous and intelligent systems with measurable, provable confidence.