The Living Safety Case: What Happens After Certification

There is a moment in every robotics program that feels like the end of a marathon. The assessor signs off, the certificate arrives, and a team that has lived inside hazard logs, requirements, test plans and reports for a year or more finally exhales.

That milestone deserves a celebration. Certification is hard-won proof that a system was engineered with rigor and independently confirmed to meet demanding safety requirements. The strongest teams treat it as the foundation for everything that comes next, because products keep evolving, and the safety case does its best work when it evolves with them.

No robot stays the robot that was certified

After certification, the question we hear most is a practical one: which changes mean reworking the safety case, and which only need a targeted retest? The standards already describe how to manage change. The hard part is judging when a change is significant. During the push to certification, attention rightly sits on the risk assessment, the safety requirements, and the allocation of safety functions to hardware and software. As a result, few teams have a defined way to tell a minor change from one that reopens the safety case.

A safety case is the argument for why a system is safe in its intended application. Every successful product outgrows its first version: a changed resistor, a fixed diagnostic, a less expensive sensor, a firmware fix. Each one asks whether the original argument still holds.

That is what we mean by a living safety case. It is not a different kind of document. It is a safety case with its own lifecycle, running alongside the product's, kept current as the product changes instead of rebuilt from scratch each time.

Three sources of change

The software. Code changes daily, but building a version isn’t releasing it. A certificate covers what receives formal sign-off. Software changes are often safety-driven and easy to underestimate: even a one-line fix can affect a safety function.

The hardware. A sensor goes end-of-life, or a supplier switch saves cents per unit. Hardware changes less often than software but are harder to fix in the field. A replacement part may also lose a safety margin that nobody documented.

The operating environment. A mobile robot moves from behind a fence to an open floor, where its safety function must account for obstacles in an uncontrolled environment. These changes rarely originate with the safety team. They come from leadership or commercial strategy, and safety inherits them after the decision is made.

Each of these lands the same question on the safety case: am I allowed to make this change, and what does it touch?

The standards planned for this all along

Functional safety standards like IEC 61508 already account for this. The safety lifecycle extends well beyond validation through operation, maintenance, repair, modification, and retrofit, ending only at decommissioning. The authors expected safety work to last as long as the system.

After a modification, the standard directs teams back to “the appropriate overall safety lifecycle phase.” Which phase depends on the change. A firmware patch might require renewed verification; a new environment might send teams back to hazard analysis. Impact analysis determines where to return, a topic that we’ll cover later in this series.

Robotics also sits between two traditions. Industrial safety grew up around one-of-a-kind installations validated where they were run. Product safety grew up around proving a design before thousands of identical units shipped. Autonomous robots are built like products and deployed like installations, which makes life after certification harder to plan for.

Why it matters now

Physical AI adds learned behavior. Connected fleets receive remote updates. Commercial teams push proven platforms into new markets. All of it is change, and all of it affects the safety case.

Trust matters, too. In pharmaceuticals, new medications undergo controlled clinical trials, but their full effects emerge only through widespread use. Robots face a similar challenge, with one difference: machine-related harm can be immediate. People working alongside robots won't give the industry the benefit of the doubt. A certificate earns a place. Keeping the safety case current is how you keep it.

What staying certified takes

Across a large number of programs, three things make the difference.

A connected safety case. Every hazard, risk reduction measure, safety function, requirement, and test stays linked to what it depends on, so a change becomes a question you can answer instead of an excavation.

Functional safety management that plans for change. Most organizations have a process for hardware and firmware changes. Fewer define how a change is judged from a safety perspective: who decides whether it is significant, what analysis it triggers, and how the decision is recorded.

Testing that can rerun what moved. Much of an impact analysis ends in a list of tests to repeat. Validation tests from six months ago have to be repeatable when a component or build changes, with results flowing back into the safety case.

None of this comes with a certificate or a press release. It is the work that keeps the first certificate meaningful and makes the next one faster.

Next in this series: the V-model gets you certified. What keeps you there looks more like an iterative loop. Stay tuned and we’ll continue our deep dive into “the living safety case” next week.