Every Robot Has a Safety Story. Here Is How to Tell It.

A safety case isn’t a single artifact. It’s a defensible, evidence-backed argument woven throughout your entire development lifecycle. The strongest safety cases aren’t assembled at the end; they’re built intentionally from the very beginning of the design process.

When people ask what belongs in a safety case, they are usually expecting a checklist. But the more useful question is: what does your safety case actually need to argue? Because a safety case is less like a filing cabinet and more like the brief a lawyer constructs that contains an entire legal narrative. It tells a story. It says: here are the identified risks, here is why our design addresses these potential risks, and here is the body of evidence that proves our design is safe and works as intended.

That story looks different depending on what you are building, especially in the new landscape of robotics, autonomous systems, and physical AI. A warehouse robot that moves packages along a fixed conveyor in an isolated corner of a facility has a very different safety story than a humanoid robot navigating unpredictably alongside workers on a factory floor. Before you can structure your process, you have to understand your business case, your operating environment, and your scope.

Start With The Business Story, Not The Safety Story

First of all, it is important to understand that the safety case is downstream of the business case. And a business case starts by asking several questions, “What problem are you solving in the marketplace? Where will this system operate? Who is around it? Are you hoping to reduce cost, increase throughput, or replace a task that is inherently dangerous for humans?” The answers to these questions and others like them will directly shape what your risk assessment needs to cover and how complex your mitigations will need to be.

There is also a question of role. Are you the builder, designing and manufacturing a robot you intend to sell to the open market? Or are you the integrator, purchasing an existing system and deploying it in your facility? The builder carries more responsibility in the safety case because the integrator can only go as far as the builder's safety ratings allow. If the builder has not considered safety in the design of their system, then the integrator is constrained in how they can deploy the product in a working environment.

This is exactly why functional safety must be a design input from day one, and not an output at the end of the process. Building safety in from the start means you can define the use case, set the safety targets, and make design decisions that support compliance based on the actual risk you are mitigating. It means that you are able to prioritize a risk-based approach for your safety case. For example, a low risk may need a less robust safety function than a high risk. Think of this as safety by design, a philosophy that goes far beyond the usual way of thinking that sometimes entails treating safety as a review stage after the design is complete. The former means clarity, alignment, and momentum and the latter means rework, missed targets, and unnecessary operational risk.

Lifecycle Phases that Frame Your Safety Case

Functional Safety Management: The Foundation

Before any technical work begins, you need a functional safety management plan. This document defines how you are going to run your safety program. It is not optional, and it is certainly not something you can write after the fact.

The plan needs to answer: who is doing what, who is reviewing what, and who is qualified to do it? Safety standards require a level of independence between the people doing the safety work and the people reviewing it. That is why large organizations like Amazon maintain both a safety department and a separate regulatory and compliance team. For smaller organizations and startups that cannot staff two teams, this independence typically means bringing in a third-party assessor or Nationally Recognized Testing Laboratory (NRTL).

Whether you choose to go to an NRTL for formal certification or pursue self-certification, a safety management plan is going to be a necessary and highly useful document either way. An NRTL will expect it as a starting point. And if you are self-certifying, it becomes one of the most important things you can bring to a customer or into a new market. It is evidence that your safety program was planned, structured, and executed deliberately rather than assembled after the fact.

The plan also needs to document the competency of everyone involved. An assessor needs 

clear evidence that the people making critical safety decisions have the training, technical expertise, and practical experience to make them responsibly. That means defining roles, qualifications, decision-making authority, and relevant experience early rather than treating competency as an afterthought once development is already underway.

The Concept Phase: Risk Assessment First

The first real technical activity in your safety case is the risk assessment, and it starts with your concept of operations. What is the system supposed to do? What is its operating environment? What does the business need it to achieve? These become the inputs to your hazard and risk analysis.

The outputs of the risk assessment are the mitigations you prescribe. Some will be functional safety mitigations: obstacle detection, speed monitoring, stability control, emergency stop systems. Others will be non-functional: physical fencing, administrative controls, restricted access zones. Both categories belong in your safety case, and both are driven by what the risk assessment uncovers.

Risk assessment inputs: Concept of operations, operating environment, business goals, system scope, use case definition.

Risk assessment outputs: Functional mitigations (obstacle avoidance, speed limits, emergency stops, stability control, etc) and non-functional mitigations (physical fencing, access controls, administrative procedures, etc).

Certification Vs. Trustworthiness

Here is a question worth sitting with: what is the actual goal of this entire safety-first process? Is it to get your product certified, or to get your product trusted? Those are not the same thing, and conflating them can create real-world problems for startups.

Third-party certification through an NRTL can take months or even years. For a startup that needs to get a product into the marketplace to stay solvent, waiting that long is simply not financially viable. That said, the alternative is not to ignore or bypass safety standards, which, incidentally, can increase liability, financial risk, and potentially land you in legal hot water. The alternative is to build your product in alignment with standards like IEC 61508, treating compliance as a north star even before the formal assessment happens.

Building to the standard from the start means that when certification becomes possible, you are not looking at years of rework to ensure compliance. It also means your customers can see a coherent, traceable safety story, instilling trust in your brand and confidence in the integrity of your system. That trustworthiness is often what customers are actually evaluating in your product, and not just the certification mark itself.

This is also where safety culture becomes relevant. In organizations where safety is driven from leadership down, teams across hardware, firmware, and software buy into the process. In startups where no one has explicitly made safety a priority, the safety engineer often finds themselves fighting an upstream battle for resources and buy-in. Safety culture is not a soft concept. It is a practical variable that determines how well your safety lifecycle actually runs and if done right, it can become a conduit for innovation and success in an increasingly crowded marketplace.

What A Complete Safety Case Covers

Think Ecosystem, Not Documents and Spreadsheets

Perhaps the most useful reframe for the safety case is this: it is not one document with moving parts. It is an ecosystem. There are stakeholders who contribute to it (your safety team, hardware engineers, firmware developers, third-party assessors). There are artifacts each party creates (management plans, hazard analyses, test reports). And there is a process that ties all of the artifacts together into a coherent argument about your product's safety.

Who should be in your ecosystem? What artifacts should they produce? How do those artifacts connect to each other, and how does the whole thing roll up into telling the safety narrative of a product that can be trusted operating in the world? Those are the questions your safety process needs to answer. The lifecycle phases above tell you what evidence to collect. The process you design tells you how to get there.

The Safety Ecosystem

When considering your safety case and structuring your process, starting early does not mean slowing down. It means building a product you can defend, and one your customers can trust, whether or not the certification mark is ready when you release it into the wild.