The Safety Case Goes to Work

The newly completed R15.08 standard puts site operators’ responsibilities in writing. A safety case continues after a robot ships, for as long as the robot is in service.

Posted by Fennec

Nov 10, 2026

This year, the Association for Advancing Automation (A3) released ANSI/A3 R15.08-3-2026, the third and final part of the American National Standards Institute (ANSI) safety series for industrial mobile robots (IMRs) [1]. Part 1 covers the robot itself. Part 2 covers integrating robots into systems and applications [2]. Part 3 covers what happens next: the responsibilities of the people and sites that operate those robots every day [1].

Those responsibilities include risk assessment, management of change, employee training, and periodic reviews and inspections across the life of the machinery [1]. A3 developed Part 3 alongside Part 3 of the R15.06 industrial robot standard, so sites running fixed and mobile robots get consistent guidance for continued operation [1].

The completed series makes something explicit that safety engineers have long understood. A safety case is not finished when a robot ships. It continues at the site, for as long as the robot is in service.

What changes after the robot arrives

A risk assessment describes a robot in a particular setting at a particular moment. Sites rarely stay still. Racking gets moved, traffic patterns shift, new people start shifts, and the robot's software receives updates.

R15.08-3 addresses this directly. It calls for managing change in both the robot application and the current operating environment around it [3]. In practice, that means a change to the floor plan can matter as much to safety as a change to the robot.

This is where a safety case either stays useful or quietly drifts out of date. Each change raises the same questions: which hazards does it touch or does it create new hazards, which requirements and safety functions are affected, and what needs to be checked again before operation continues?

Why the lifecycle view is getting more attention

The legal community is noticing the same shift. A recent Foley Hoag analysis observes that as robots are increasingly delivered as a service, installed at a customer site and supported with remote monitoring, software updates, and maintenance, the traditional line between a product and a service is becoming less clear [4]. Courts have shown more willingness to apply product liability principles to software and AI-driven systems [4].

Investors are paying attention too. Foley Hoag notes that robotics due diligence now routinely looks at safety documentation and incident history [4]. Its recommendations include keeping design records that capture safety trade-offs, standards applied, and hazard analyses as decisions are made, and setting data retention policies for sensor, telemetry, and model data before any incident occurs [4]. The firm's conclusion is that outcomes often depend on the quality of documentation and the discipline of release and incident processes [4].

Law firm MLT Aikins made a similar point earlier this year, describing robotics risk as dynamic because the environments robots work in are dynamic [5]. In Europe, the revised Product Liability Directive brings software into scope, and one analysis expects embedded monitoring to play an important role in responding to claims [6].

None of this changes what good safety engineering asks for. It does raise the value of being able to show, at any point in a robot's service life, what the safety case says and how it has kept pace with all manner of change.

What a site-ready safety case looks like

The three parts of R15.08 map onto three groups who each hold part of the safety case: the manufacturer who builds the robot, the integrator who designs the application, and the site that operates it.

A safety case that holds up in service tends to have a few things in common.

It connects across those hand-offs. The site can see the assumptions the manufacturer and integrator made, such as speed limits, zone definitions, and the conditions the robot was validated for, and can tell when its own changes move outside of them.

It treats change as a trigger. A new layout, a software update, or a new task type prompts a defined review (and subsequent impact analysis) rather than an informal judgment call.

It takes in evidence from the field. Inspections, near misses, and operational data flow back into the hazard analysis, so the safety case reflects how the robot actually behaves on that floor.

It is easy to show. When a customer, an auditor, an investor, or an insurer asks what the safety case says today, the answer is current and traceable.

Questions worth asking now

If your floor layout changed tomorrow, would you know which hazards and safety functions it affects? Would it create new hazards?
Can the site see the assumptions the robot was validated under?
Do software updates go through the same change review as physical changes?
Is field data, including near misses, feeding back into your hazard analysis?
If someone asked for your current safety case today, how long would it take to produce?

At Fennec, we build for the full life of a robot, not just the run-up to deployment. The ASAP Platform keeps hazards, requirements, safety functions, and test evidence connected in one place, so when something changes, teams can see what it affects and what needs another look. ASAP Testing provides the physical testing infrastructure to confirm behavior after a change, including testing that deliberately pushes a robot toward the conditions where its safety functions are most likely to fall short. And because we are a team of functional safety engineers, we also work alongside manufacturers and integrators as they build the risk assessment and change management practices that R15.08-3 describes.

Getting a robot ready for the floor is a milestone. Keeping it ready, through every layout change, software update, and new shift, is the work that follows.