Practice 03 · Autonomy & certification

UL 4600 · UL 3115

Engineering evidence is not the same thing as a certifiable argument. This is where IEC 61508 evidence and AI safety evidence become a structured safety case a customer, insurer or certification body can actually evaluate — and, where the AI itself needs its own certificate, where you get one.

Scope

Why evidence alone doesn't get you deployed

UL 4600 and UL 3115 address the gap between having safety evidence and proving safety to someone who wasn't in the room when it was produced.

The test. If the robot is genuinely safe but nobody outside your engineering team could independently verify that from your documentation, the gap is here — not in IEC 61508 and not in your model evaluation.

Component evidence is not an argument

IEC 61508 gives you a SIL figure. AI safety evaluation gives you a set of performance and robustness numbers against a task envelope. Both are necessary. Neither, on its own, tells a reader why the combination is acceptable, what it assumes, or what remains unproven. That connective structure — claim, argument, evidence — is a separate discipline, and it is usually the first thing missing when a robot that has clearly been engineered carefully still fails a customer's due-diligence review.

UL 4600 was written to be technology-agnostic on purpose: a safety case built from explicit claims about the system, arguments for why those claims hold, and evidence supporting the arguments. It applies as well to a delivery robot or an AMR fleet as it does to a self-driving car, and it does not prescribe how you built the robot — only how you show that what you built is safe enough, and what is still open.

UL 3115 answers a narrower, newer question

Published in October 2025, UL 3115 is an outline for the safety of AI-based products specifically — both AI-embedded products such as autonomous robots, and pure digital AI products. It functions as a universal safety layer for AI features, complementing hardware and electrical safety rules rather than replacing them, and it maps its criteria onto ISO, IEC and NIST frameworks so evidence built for one recognises the others.

In practice, UL 3115 certifies the AI component; UL 4600 argues the product as a whole. A robot with a certified AI perception stack still needs a product-level safety case — and a product-level safety case is far easier to write when the AI evidence inside it already has a recognised shape.

The practical consequence. Teams that treat certification as a paperwork exercise at the end of development consistently discover the gaps too late — a claim with no evidence, an assumption nobody wrote down, a test that proves less than the report implies. Structuring the case from the start turns it into a live map of what's actually done.

How they fit together

One certifies the AI. The other argues the product.

They are not sequential gates you pass once — but for a robot with a meaningful AI component, UL 3115 evidence typically becomes one of the strongest pieces of evidence inside the UL 4600 case.

UL 3115

Certify the AI

The AI-embedded or digital AI component is evaluated against UL 3115's safety criteria, cross-mapped to ISO, IEC and NIST frameworks — producing a certified, recognised piece of evidence about the AI specifically.

UL 4600

Argue the product

The UL 3115 certificate, the IEC 61508 functional safety case and every other relevant piece of evidence are assembled into one claim-argument-evidence structure covering the whole robot — with an explicit residual risk statement.

Deliverables

What we deliver

A safety case is only as strong as its weakest linked claim. We build the structure so every claim actually traces to evidence that supports it.

  • 01
    Safety case architecture. A claim-argument-evidence skeleton scoped to your product, built around UL 4600's structure from day one rather than reverse-engineered at the end.
  • 02
    Operating envelope definition. The explicit scope the safety case is claimed over — tasks, environment, people present — so every claim has clear boundaries.
  • 03
    Hazard evidence reconciliation. Mapping your IEC 61508 hazard analysis and AI risk analysis into a single, coherent claim structure instead of three disconnected documents.
  • 04
    Evidence catalogue & traceability. Every claim linked to the specific test, analysis, certificate or field data that supports it — and a flag on every claim that isn't yet supported.
  • 05
    UL 3115 readiness. Mapping your AI safety evidence onto UL 3115's criteria and the ISO/IEC/NIST frameworks it cross-references, before submission.
  • 06
    V&V strategy alignment. Making sure fault injection, model evaluation and field data collectively prove what the safety case claims — and nothing more than that.
  • 07
    Independent pre-review. A review before the UL evaluator or notified body sees it, so gaps are found by us, not during the submission.
  • 08
    Submission support. Organising the case, evidence and supporting documentation into the form an evaluator expects, and representing the argument through the review.

Signals

You probably need this if…

  • You have strong component-level evidence but no single document connecting it to a residual-risk statement.
  • A customer's insurer has asked for a safety case and you've sent them a spec sheet.
  • Your AI evaluation results exist in a data-science report that nobody outside that team has read.
  • You're targeting UL 3115 certification but haven't mapped your evidence to its criteria yet.
  • A contract requires "a UL 4600-conformant safety case" and nobody on the team has built one before.
  • Your safety argument lives in one engineer's head and changes every time that person changes teams.

Could a stranger evaluate your safety case?

Not "is the robot safe" — could someone who has never met your engineering team read your case and reach the same conclusion, from the evidence alone.