UL 4600 for LLM-Backed Autonomy: A Safety Evidence Crosswalk

UL 4600 evaluates a safety argument for autonomous products that operate without expected human supervision or intervention in the dynamic driving task. The active third edition was published and ANSI-approved on March 17, 2023. Its scope covers safety principles and risk mitigation. It also covers the tools and techniques used to build and evaluate that argument, along with its lifecycle processes.

An LLM call can contribute evidence to one narrow claim in that safety case. It cannot stand in for perception testing or actuator behavior. It also cannot replace road testing, hazard analysis, or a separate risk-acceptance decision. I would strike any architecture diagram that paints one gateway box across the entire autonomy stack. A bright blue rectangle does not create evidence where the request path never existed.

TL;DR

• Build a UL 4600 safety evidence crosswalk for the exact autonomous item and operating context.
• Assign every safety claim to a system boundary and evidence owner, then identify its test and record before naming the acceptance authority.
• Use routed LLM records only for authenticated HTTP model calls; keep sensors, local inference, planning, control, and actuators in their own evidence lanes.
• Treat gateway logs as supporting evidence, never as proof of UL 4600 conformity or acceptable vehicle safety.

UL 4600 evaluates a safety argument

The official UL 4600 standard record lists Edition 3 as active and gives March 17, 2023 as both its publication and ANSI approval date. The published scope covers vehicles operating in an autonomous mode, including an individual item or part of a team such as a platoon. It assumes normal operation without human supervision and without expected human intervention in the dynamic driving task.

UL's publication notice for the standard describes a safety argument that includes risk analysis and safety-relevant design processes. It also includes testing and tool qualification. Its scope covers autonomy validation, data integrity, plus human-machine interaction for non-drivers. UL calls the standard technology-neutral.

The safety case starts with the autonomous product and its operating assumptions. Its hazards and risk controls follow from that boundary. The model call appears only where the product architecture actually depends on one. Begin with the autonomous AI agent governance guide for enterprise agent ownership, then keep vehicle or product-safety claims in this UL 4600 crosswalk.

Define the autonomous item before mapping evidence

Write the item boundary at the top of the crosswalk. Name the product configuration and software release. Add the hardware revision, operating environment, external services, support processes, and fallback behavior. If an LLM participates, name its exact function. A route that summarizes maintenance messages has different safety consequences from a route that proposes a maneuver or alters a mission plan.

For each LLM dependency, record:

• Caller: software component and workload identity, plus the release and accountable owner.
• Request: trigger and input fields, plus data classes, context sources, and maximum permitted age.
• Destination: provider and model identifier, plus the endpoint, region, and named account.
• Decision use: advisory output and gated proposal, or input to another safety-relevant component.
• Failure behavior: timeout and malformed response, plus refusal, policy denial, unavailable provider, and stale context.
• Downstream authority: component that validates or rejects the response before any action.

Keep embedded and local inference in a separate row. A local model that receives sensor data over an in-process call produces no authenticated HTTP exchange for an AI gateway to inspect. The evidence owner remains the product team and its validation systems.

Build the claim, argument, and evidence crosswalk

A useful crosswalk forces one safety claim into a testable chain. Give each row a stable claim ID and write the claim at the level the evidence can support. "LLM output is safe" is too broad. "Release 8.4 rejects model responses that fail the signed maneuver schema before planner ingestion" identifies a boundary and observable behavior.

Each row should contain:

• Claim: the bounded safety assertion and the product configuration it covers.
• Argument: the reasoning that connects the control and test to that claim.
• Hazard link: hazard identifier and causal path, plus the severity method and risk-control owner.
• System boundary: sensor, perception, localization, planning, model request, controller, actuator, operator interface, or support service.
• Evidence: test case and environment, plus the input corpus, result, timestamp, tool version, and retained artifact.
• Independence: author and reviewer, plus the approver and any separation required by the safety process.
• Validity window: release and model version, plus the policy version, operating domain, and named change triggers.
• Residual decision: accepted limitation and compensating control, with the named acceptance authority.

Print one completed row during the review. The claim should fit on the left side of the page, and every evidence identifier should resolve without opening a team member's personal notebook.

Route register for LLM-backed autonomy

The route register sits beneath the crosswalk. It identifies which model calls can produce gateway evidence and which paths require another control. One row represents one caller-to-model route in one deployed configuration.

For a deliberately routed external LLM call, capture the verified caller or agent identity supplied by the application and the route. Record the model destination and request classification. Add the policy version, policy outcome, request and response identifiers, response validation result, and timestamp. Join that record to the product release and scenario test, then connect the hazard link and downstream acceptance event.

Then mark exclusions plainly:

• Sensor acquisition and calibration
• Perception and localization pipelines
• Embedded or local model inference
• Planner state and control-loop timing
• Actuator commands and physical response
• Road and track testing
• Simulation validity and development-tool qualification
• Operator training and human-machine interaction
• Risk acceptance and conformity decisions

The agentic AI audit trail guide can help define identity and lineage for software agents. Vehicle telemetry and safety-test results still need their own records and owners, as does physical-system evidence.

Test changes that can invalidate the evidence

A model route can change without a vehicle binary changing. Provider model updates and endpoint moves can affect the safety argument. So can prompt revisions, retrieved context, policy changes, schema revisions, and account configuration. Put those triggers in the crosswalk before release.

For each routed model dependency, run a controlled set that includes an approved request and a denied data class. Add an unauthorized caller, a provider timeout, an invalid schema, contradictory context, and a response that reaches the downstream safety limit. Preserve the raw response under the approved handling policy. Preserve the validator result and final downstream disposition with it. Repeat the set after any listed change trigger.

The safety team also needs a route-loss test. Remove access to the external model or force the gateway to deny the call. Observe the product's documented degraded state and verify that the physical system remains within the approved fallback behavior. Gateway evidence can show the denial and timestamp. Product telemetry must show what the autonomous item did next.

UL 4600 leaves major decisions to the safety case

UL's publication notice says the standard does not define safety performance pass or fail criteria. It also excludes road-testing requirements and acceptable risk levels. Ethical release decisions and ethical aspects of product behavior are excluded as well. Those limits should appear in the review packet because they prevent a standards reference from becoming a substitute for the organization's own acceptance decisions.

A conformity claim therefore needs evidence and authority beyond a route log. The safety organization owns hazard analysis and argument completeness. It also owns acceptance criteria and independent review. The final product decision belongs to it. An LLM gateway owner can attest to a tested request path and its records. That owner cannot declare the autonomous product safe.

My blunt view is that a large volume of model logs can make a weak safety case harder to inspect. Keep only records tied to a claim and test, with the applicable configuration and decision. Ten million unjoined events are storage, not an argument.

DeepInspect

DeepInspect can provide evidence for authenticated calls from an autonomous application or agent to an external LLM when the application deliberately routes those HTTP calls through the proxy. It can evaluate supplied identity and request classification. It can also evaluate the model destination and policy, then record the outcome and response association with its timestamp. A signed audit record can help preserve that route decision independently of the calling component.

DeepInspect remains outside sensors, perception, localization, and planning loops. It also remains outside actuators, embedded inference, road testing, tool qualification, autonomy validation, human-machine interaction, and risk acceptance. Put its records into the claim crosswalk only where the route supports a named claim. Never present the records as a UL 4600 conformity decision. Book a demo today.