Deployment Release

16 Deployment Release

Purpose

Physical AI stack focus for this chapter.

Why can a machine that completes every trial still lack the evidence to be allowed among people?

A successful trial shows what a machine did under the conditions it happened to meet, while permission to operate is a claim about every condition it may meet next. Thousands of clean runs on a dry floor say nothing about the stop on a floor no trial touched, and a brake that stopped the machine last month may not stop it inside the same distance after its lining wears. A machine granted authority on demonstrations therefore carries untested premises into service, where the first test of each one is the event it was meant to prevent. Deciding to deploy requires stating which physical claims the evidence supports, under which conditions and for how long, refusing or narrowing operation wherever a premise remains unknown, and withdrawing the grant when brakes wear, sensors shift, or software changes. At the causal boundary, authority must expire when its physical justification does, because a later software correction cannot undo motion already produced.

Learning Objectives

• Construct a claim-argument-evidence (CAE) safety case as an auditable engineering assertion DAG linking bounded operating envelopes to qualified measurements, analysis, and operating conditions
• Distinguish input provenance from premise status, and select the verdict (UNCOND, COND, or REFUSE) the supported operating claim permits
• Join task-success, cycle-time, and intervention evidence to the physical measurements and restrictions supporting a conditional release
• Specify standing-condition cadences and validated responses, from brake wear to calibration drift, separately from execution leases
• Diagnose unsupported warrants, hidden contextual assumptions, and compound defeaters through adversarial review of a release argument
• Specify the records a release manifest binds by digest and the conditions under which its gate refuses motion
• Determine which claims a policy or software update reopens, and why shadow operation cannot substitute for closed-loop qualification

16.1 The Decision to Deploy

Verification left the machine with a signed set of fault records. Each pairs an observed trace under an injected fault (a stalled proposer, a stale frame, lost fieldbus frames, a sagging bus) with an oracle fixed before the trial, and the set names the operating regimes no trial reached. Beside it sit the records the earlier chapters produced: the authority record of arbitration and fallback outcomes, the placement record of compute scheduling and isolation, and the evaluation record of closed-loop task performance. Those records say how the machine behaved under the conditions tested. They do not say which operating claim the machine may now be granted, because a fault record proves nothing outside the envelope it sampled, and an untested mode is a gap rather than a pass. Offline validation accuracy and clean laboratory demonstrations sit in the same position. Release is the step that decides, claim by claim, what this evidence licenses across a named operational design domain.

↩︎ The empirical verification evidence backing release claims is established in Fault Injection on Hardware.

That step is a threshold every machine operating among humans eventually crosses, the point where builders formally grant it authority to act outside the laboratory. In conventional software engineering, deployment is largely reversible; an operator can recall a defective build within minutes, bounding the cost of failure to the time required to roll back the binary. For physical systems, that release grant differs fundamentally. Every action authorized by the runtime delivers energy across the causal boundary into the physical environment. When a release decision errs, the failure appears as an actuator driving past an obstacle clearance line or a gripper exerting uncalibrated force against human tissue, and no software rollback can recall kinetic energy already transferred. Aerospace, rail transit, and industrial robotics manage this risk through an explicit safety case, a structured and auditable argument stating what the machine is claimed to do, under what operating conditions, and on what evidence. Physical AI inherits this burden with an added difficulty. A learned policy cannot be proven safe by inspecting its weights, and finite field trials cannot surface every rare tail failure, which is where the worst consequences lie.

A release decision determines which operational claims the available evidence actually supports, under what physical conditions, and for how long. Rather than boiling deployment readiness down to a single benchmark score, the decision is a bounded, revocable judgment, and this chapter builds it in the order an adjudicator meets it. The claims are first written as physical inequalities over a bounded operating envelope, then organized into an argument whose every link names its evidence. The argument resolves into one of three verdicts (full operational authorization, restricted operation inside enforced limits, or refusal), and standing conditions define when a granted verdict expires. A worked adjudication applies all of this to the running machine, an adversarial review then tries to break whatever case survives, and a signed release manifest binds the final decision to the executing machine, so that every later software update, retrained checkpoint, or hardware modification must pass through the same gate.

The warehouse mobile manipulator shows why past operational success cannot by itself license deployment. In an active logistics depot it must travel narrow aisles past protruding rack ends, unlatch a spring-latched cage door, and hand a ceramic mug to a human coworker. Each subtask turns on a distinct physical claim: a stopping distance inside the clear distance at maximum payload, a bounded peak force on the latch, and a limited contact force during the handover. A spotless test run shows only that the machine executed those motions under the exact conditions of that single trial. A sound release decision must instead bound the physical variations the machine will face in production and show that verified plant dynamics and low-level safety interlocks keep risk within limits across that entire envelope.

A deployed system must also do useful work inside its certified envelope. Closed-loop evaluation logs show whether an end-to-end policy completes its tasks, how often humans must intervene, and which environmental conditions cause the policy to break down. Engineers must weigh these task metrics against the speed limits, payload caps, and spatial restrictions required by the safety case. A mobile base that trips safety stops every few meters avoids collisions while failing its service target; conversely, an agile policy that finishes every nominal trial cannot be given actuator authority until deterministic guardrails enforce safe bounds during perception failures. The release decision brings these two requirements together into one operating profile.

↩︎ The closed-loop evaluation record of task success, intervention rates, and breakdown conditions is established in The Evaluation Record.

Because different facilities have different lighting, floor friction, and foot traffic, an initial release case applies to a single facility. Cryptographically signed fault records show how the system behaved under injected faults, while the physical criteria draw on site clearance surveys, loaded braking trials, and calibrated impact-force measurements. Before engineers can tie each record to a safety claim and log the remaining unverified assumptions, they must write the claims themselves as testable physical inequalities.

↩︎ The signed fault records a release case consumes are established in Fault Records for Release.

16.2 Physical Criteria for Release

A deployment review that signs off on aggregate benchmark scores or smooth demo videos leaves the machine with no testable rule for when it may move. At a rack end, the base must stop inside the available clearance; during handover, the arm must stay within the assessed contact-force limit; and both claims depend on the permission path finishing its check before its deadline. Together, those requirements give release authorization three testable physical criteria: \[\StoppingDistance(\SpeedAtDetection, \PrebrakeDelay, \CredibleBrakingDeceleration, \LocalizationBound, \TrackingErrorBound) \le \ClearDistance, \quad \CollaborativeContactForce(\SpeedAtDetection, \EffectiveImpactMass, \HertzianContactStiffness) \le \AssessedContactForceLimit, \quad \WorstCasePermissionCycleTime \le \CompletionDeadline. \tag{1}\]

The first term abbreviates the full stopping budget of equation 12.1, whose protective margin is charged as well. In the third criterion, \(\WorstCasePermissionCycleTime\) is the worst-case execution time of one permission-path cycle and \(\CompletionDeadline\) the deadline that cycle must meet inside its tick (Execution timing in the sub-millisecond loop). A permission computed after its deadline cannot be credited for that cycle, and the qualified fallback must contain the resulting delay.

Because each criterion is a physical inequality, release authorization cannot rest on intuition, demonstrations, or aggregate benchmark scores. Authorizing deployment requires an auditable safety argument that links every inequality to measured observation ages, worst-case execution time bounds, empirical braking and contact trials, and a validated fallback. These physical bounds also depend on the individual machine’s calibration: its camera and lidar sensor transforms, joint encoder zero offsets, and motor torque constants. A lost or drifted calibration invalidates the certified stopping budget even when software binaries remain unchanged. A sensor mount that shifts in service erodes the localization allowance \(\LocalizationBound\) (section 16.5.1), and a firmware update that overwrites measured sensor extrinsics and joint offsets invalidates the budget just as quickly, so the deployment pipeline must preserve and re-verify calibration records before restoring the operating permit (section 16.9.1).

For the warehouse mobile manipulator, the release question asks whether empirical and analytical evidence satisfies these criteria for each of its three tasks inside a scoped operating envelope. The release case defines the assessed physical bounds, the specified hardware fault model, and the validated permission and fallback ladder. This argument is the safety case, which section 16.3.1 gives a formal structure, and it justifies granting a revocable operating permit while those physical conditions hold. The permit is the signed authority under which the permission path may admit the policy’s tracking commands (section 16.4). Finite test runs cannot establish protection against uncharacterized or unmodeled hazards.

A release case is scoped by the operating envelope: the target operational design domain (ODD) paired with the machine’s internal hardware, thermal, and timing invariants. Deployment release authorizes a system configuration under standing operating conditions, complementing rather than replacing the short execution leases that bound individual action chunks. Site inspections, calibration checks, and per-tick permission checks operate at the distinct cadences dictated by their respective failure mechanisms. The envelope also fixes what each of the three possible verdicts, defined in section 16.4, refers to: unconditional operation (UNCOND) covers the full verified envelope, conditional operation (COND) a separately evidenced subset with constrained kinematics or environmental fences, and refusal (REFUSE) none of it. For the mobile manipulator, the proposed nominal operating envelope specifies aisle travel up to 1.3 m/s (chosen; see the Reader Guide) with the tote rack loaded to at most 50 kg, on floors surveyed to a friction coefficient of at least 0.204, and past rack ends with at least 1.10 m of clear distance. The friction floor is an optimistic screen with all weight on the driven wheels; actual qualification must include loaded wheel forces, drive settings, and stopping traces. For manipulation, the proposed envelope specifies door approaches at 0.03 m/s and coworker handovers at 0.10 m/s tool center point (TCP) speed.

↩︎ The operational design domain and its known absences are established in Choosing a tractable coverage table.

Inside these boundaries, the learned neural policy proposes actions across the nominal task envelope, but every proposed action requires independent, per-tick permission from an isolated safety enforcer. Mode-specific conditions (table 1) narrow that envelope. The takeover analysis of Clearance-derived fallback deadlines supplies candidate intervention speeds, screening an in-loop request at 0.75 m/s and an out-of-loop crawl at 0.15 m/s. Neither screen qualifies as a standalone release limit, because each depends on a human response time that the release case has not measured. The in-loop slow-down holds only for an operator answering an expected stimulus, and the out-of-loop crawl already fails the 99th-percentile response. The robust design therefore runs the base’s own local stop first and hands over control from standstill, where waiting costs time but no clearance. The restricted mode of a COND verdict narrows the envelope further. On a floor characterized only through the site inspection regime, the machine runs at 1 m/s, below the 1.23 m/s optimistic all-weight inspected-floor screen, while still charging dispatch-to-admission delay and maintaining a positive stopping reserve.

The rules in table 1 follow a strict priority ladder: refusal conditions override mode-specific restrictions, which in turn override nominal limits. Because speed ranges overlap across operational contexts, these thresholds define operating modes rather than disjoint numerical intervals. The payload row shows how a mode differs from an interval. If the tote-rack load estimate has gone stale since the last pick, the base may not transit, because its stopping budget assumes a known mass, but the stationary arm may keep working under its own separately evidenced claim; an invalid estimate or a measured overload refuses both. A conditional state restricts admitted proposals through enforcer clamping. A refusal state revokes the operating permit, so the permission path admits no further tracking commands, and commands a validated fallback trajectory. Onboard wheel slip estimation cannot provide prospective clearance guarantees because it detects low friction only after traction has already been lost. A thin film of clear oil (\(\CoulombFrictionCoefficient \approx\) 0.05) can be visually indistinguishable from dry concrete to the navigation cameras. By the time a loaded base moving at aisle speed (1.3 m/s) initiates braking on an oil patch and measures slip, it has already committed to a stopping distance that exceeds the clear distance. Consequently, the release case must justify how site surveys, contamination exclusion, and bounded inspection and response procedures preserve the assessed friction floor throughout the authorized interval. Periodic surveys alone cannot exclude a spill between inspections.

↩︎ The ladder of resident fallback responses that a refusal commands is established in The Fallback Ladder.

The safety case must also document machine behavior when operation encounters an envelope boundary. Event-triggered edge telemetry freezes circular buffer traces for post-incident review (section 16.9.5), while the deterministic permission path enforces physical boundaries in real time. Table 1 summarizes the physical dimensions maintained by runtime monitors and administrative site controls. Internal environmental conditions, such as ambient temperature, DC bus rail voltage, and compute system-on-chip (SoC) utilization, enter the release case through fault injection and stress tests conducted across their qualified ranges.

↩︎ The internal qualification ranges for temperature, bus voltage, and compute load that the release case inherits are established in The Operating Envelope.

Table 1: Operating envelope of the warehouse mobile manipulator: Refusal rules take priority over restricted-mode rules and nominal limits. Conditional operation requires every relied-on premise to remain supported; stale payload evidence permits only separately supported stationary work, while an invalid estimate or overload refuses. The takeover speeds are preliminary screens, not qualified motion limits. The friction floor and inspected-floor ceiling assume all weight on driven wheels and require loaded stopping qualification. The displayed speed ceilings are partial calculations before dispatch-to-admission delay; signed limits require that delay and a positive reserve. Sensor rates and stopping response are plant validation obligations.

Envelope Dimension / Invariant	Nominal Envelope	Conditional Boundary	Hard Refusal	Runtime Monitor & Rate	Enforcer Action & Latency
Aisle Speed	\(\SpeedAtDetection\le\) 1.3 m/s	Preliminary takeover screens: 0.75 m/s in-loop and 0.15 m/s out-of-loop; the robust design stops before any handover	Measured speed above the signed 1.3 m/s (ceiling 1.44 m/s), or invalid speed estimate	Encoders and IMU, every 1 ms permission tick	Clamp admitted speed; refuse above the signed speed
Floor Friction	Surveyed \(\CoulombFrictionCoefficient\ge\) 0.204 (dry concrete near 0.60)	Qualified assessment and maintained site regime (\(\CoulombFrictionCoefficient\ge\) 0.12): restricted 1 m/s, below the 1.23 m/s ceiling	Unsurveyed floor or reported film; a clear oil film (\(\CoulombFrictionCoefficient\approx\) 0.05) can evade the installed cameras	Floor survey and site spill procedure; no on-board measurement	Restrict speed by floor zone; refuse the aisle
Tote-Rack Payload	\(0\le \Mass\le\) 50 kg, valid load estimate (total at most 368 kg)	Estimate stale since the last pick: stationary arm tasks only	Load above capacity or invalid estimate	Rack load cells, at each pick	Refuse aisle transit until re-weighed
Rack-End Clearance	Surveyed \(\ClearDistance\ge\) 1.10 m at every rack end	Shorter surveyed clearance: lower signed speed from the same budget	Unsurveyed rack end, or obstacle inside the clear distance	Site survey; lidar and navigation camera at frame rate	Speed limit per rack end; stop for a detected obstacle
Door Latch Approach	\(\SpeedAtDetection\le\) 0.03 m/s, strike plate at its nominal position	Original policy: nominal plate only; changed recovery candidate needs its own evaluation and release case	0.10 m/s approach or plate condition outside the selected policy case	Arm contact-force sensing in the 2 ms contact loop	Trip at 15 N; refuse the unsupported approach
Coworker Handover	TCP speed \(\le\) 0.10 m/s under accept_item	Coworker present without accept_item: hold short of the handover point	TCP speed above the signed 0.10 m/s (transient ceiling 0.24 m/s), or a clamping geometry outside the assessed transient case	Joint encoders every permission tick; arm contact-force sensing	Clamp TCP speed; refuse above the signed speed

The nominal latch row in table 1 scopes the baseline policy release case. Although the separately stipulated recovery campaign in Qualifying a recovery update evaluates a changed candidate across nominal and displaced-plate conditions, that experimental provenance does not silently extend the contact-force or timing bounds established here. Deploying the recovery policy requires its own evaluation and safety case update.

A defensible release claim must specify its plant dynamics, assumed contact geometry, and modeled fault set. The release case for the mobile manipulator rests on three criteria: the base stops inside the 1.10 m clear distance before reaching a pedestrian who has stepped out at a rack end and stopped, the arm unlatches the door without exceeding the 100 N structural limit, and an item handover does not exceed 50 N of peak contact force against the coworker. The base’s stopping claim assumes that the person, once in the path, stands still. A person who keeps walking toward the moving base closes the gap during the whole reaction and braking interval, and Sizing the composite stopping budget showed that sizing the budget for that approach would cut the aisle speed to the much lower walking-person ceiling. The site therefore controls aisle-end crossings procedurally, and that site crossing rule is itself a premise the release case must evidence. A complete release argument demonstrates which human contacts are excluded before impact, which detected contacts fall within the compliance model, and which single-point faults trigger the isolated fallback. Halting motion after impact occurs does not reduce the initial shock force.

The contact criteria arrive as premises from the enforcement record rather than as calculations derived during release review. The spring-mass impact peak that grows linearly with approach speed (equation 6.7) was first met as the soft-spring exploit of the latch simulator; Intentional contact and in-contact energy barriers specializes it to an unbraked elastic contact with a coworker’s hand (equation 12.13), using the arm’s effective mass and the ISO/TS 15066 biomechanical hand model.¹ The release case evaluates the operational consequences of those physical results. At the arm’s maximum free-space limit of 1 m/s, even the transient impact model predicts 207 N, exceeding the 50 N criterion by a factor of 4.1×. Consequently, unseparated coworker proximity cannot be permitted at full free-space speed without additional physical containment. When encountering a free hand that recoils upon impact, the criterion admits approach speeds up to 0.24 m/s, and the model predicts a transient force of 20.7 N at the chosen handover speed of 0.10 m/s, below the case criterion. If the coworker’s hand is clamped against a rack upright or structural frame, however, the ceiling drops to 0.053 m/s. At that same 0.10 m/s approach speed, a clamped collision generates 94.9 N, which breaches the limit. The handover claim is therefore strictly a transient-contact claim, inheriting two essential premises: that the lumped-mass body model and effective mass accurately describe the collision, and that the handover geometry excludes pinching or clamping hazards. Because physical calculations alone cannot guarantee workspace clearance, the release case must establish both premises through empirical evidence and site inspection.

¹ ISO/TS 15066 Values as Case Criteria: The document supplies a body model and body-region force and pressure data for transient and quasi-static contact (International Organization for Standardization 2016). ISO 10218-2:2025 incorporates the collaborative-application requirements formerly published as ISO/TS 15066; ISO/TS 15066:2016 itself remains published and is under revision (International Organization for Standardization 2025b). The 50 N handover criterion is none of those tabulated values and not an injury boundary; the site assessment chooses it for one body region, contact type, and geometry, so a change to any of the three reopens the claim instead of inheriting its margin.

International Organization for Standardization. 2016. ISO/TS 15066:2016: Robots and Robotic Devices, Collaborative Robots. International Organization for Standardization.

International Organization for Standardization. 2025b. ISO 10218-2:2025: Robotics, Safety Requirements, Part 2: Industrial Robot Applications and Robot Cells. International Organization for Standardization.

Unlike the arm’s instantaneous force criteria, the mobile base’s claim is an integrated distance budget. Validating this claim requires empirical evidence bounding the perception observation age, communication bus latencies, and execution lease durations. Sizing the composite stopping budget sized that budget term by term at aisle speed (The warehouse mobile manipulator's stopping budget), integrating equation 12.1 with the jerk-limited \(\Glyph{C}^2\) braking profile from The C^2 stopping suffix and jerk-limited braking, and found the spare and the reserve that dispatch-to-admission travel leaves. Release inherits those terms as premises. In deployment authorization, the critical engineering metric is the margin of clear distance that remains unspent, and the question release adds is how large an error in a single input would spend it. Notebook 16.1 recapitulates the enforcement budget and adds that question as step 4.

Napkin Math 16.1: The aisle spare

Problem: At the 1.3 m/s aisle speed, how much of the 1.10 m clear distance does the stopping budget leave unspent, what error in a single input would spend it, and how much remains once dispatch-to-admission work is charged?

Variables:

• Aisle speed \(\SpeedAtDetection =\) 1.3 m/s (Chosen); clear distance \(\ClearDistance =\) 1.10 m (Illustrative, standing in for a site survey)
• Pre-brake delay \(\PrebrakeDelay =\) 133.6 ms (Derived from illustrative terms: 51.6 ms observation age plus 82 ms from the last valid renewal to brake onset)
• Credible deceleration \(\CredibleBrakingDeceleration =\) 2 m/s² (Illustrative) and jerk bound \(\JerkLimit =\) 7.11 m/s³ (Derived, The C^2 stopping suffix and jerk-limited braking)
• Allowances \(\LocalizationBound =\) 50 mm and \(\TrackingErrorBound =\) 40 mm (Illustrative); margin \(\ProtectiveClearanceMargin =\) 100 mm (Chosen)
• Dispatch-to-admission allocation \(\DispatchAdmissionInterval =\) 63.3 ms (Illustrative allocation, The board-link budget and the dispatch-to-admission interval)

Math:

1. Reaction: \(\SpeedAtDetection\,\PrebrakeDelay =\) 1.3 m/s \(\times\) 133.6 ms \(=\) 173.7 mm.
2. Braking: Because \(\SpeedAtDetection \ge \CredibleBrakingDeceleration^2/\JerkLimit\), the stop reaches full deceleration, and \(\SpeedAtDetection^2/(2\CredibleBrakingDeceleration) + \SpeedAtDetection\,\CredibleBrakingDeceleration/(2\JerkLimit) =\) 422.5 mm \(+\) 182.8 mm \(=\) 605.3 mm.
3. Spare: 173.7 mm \(+\) 605.3 mm \(+\) 50 mm \(+\) 40 mm \(+\) 100 mm \(=\) 969.0 mm, leaving 1,100 mm \(-\) 969.0 mm \(=\) 131.0 mm.
4. One input wrong: As extra delay, 131.0 mm \(/\) 1.3 m/s \(=\) 100.8 ms. As weaker braking, setting step 2 equal to the 736.3 mm braking room gives \(\BreakEvenBrakingDeceleration =\) 1.39 m/s², a 31 percent shortfall.
5. Admission charged: \(\SpeedAtDetection\,\DispatchAdmissionInterval =\) 1.3 m/s \(\times\) 63.3 ms \(=\) 82.3 mm, leaving a reserve of 48.7 mm, or 37.5 ms at aisle speed.

Result: The budget spends all but 131.0 mm of the clear distance before admission work, and all but 48.7 mm after it.

Systems insight: The validity of the stopping guarantee \(\StoppingDistance \le \ClearDistance\) hinges on the narrow margin of unspent distance rather than the nominal distance consumed. Measured against the partial spare of step 3, a credible deceleration overstated by 31 percent spends the whole of it. The reserve that step 5 leaves after admission work is less than half that spare, so once \(\DispatchAdmissionInterval\) is charged a smaller braking error suffices.

This reserve must also absorb any unmodeled runtime uncertainty, so it cannot be treated as extra allowable latency or repurposed as a margin for control handovers. The reserve left after admission work, 37.5 ms at aisle speed, tolerates less unbudgeted delay or braking shortfall than the break-even values of step 4. Unless each component of the timing and kinematic chain is measured, nothing shows that the reserve survives the latencies and friction variation of a production floor. Each of the three criteria (stop, latch, and handover) therefore depends directly on premises about achievable deceleration, sensor-to-actuator latency, and contact stiffness that no calculation can certify. Because these physical properties can degrade over mechanical operating life, an auditable safety case must expose these runtime dependencies so that certification engineers can judge whether the empirical evidence supports deployment.

The partial budget leaves only 131.0 mm of the 1.10 m clear distance spare.

16.3 Safety Cases and Claims

A photograph of a clear aisle cannot establish that a loaded mobile base will stop before reaching an obstacle. A valid stopping claim depends on guaranteed physical clearance, actual braking capability, and end-to-end response timing, with each parameter supported by empirical evidence gathered under documented operating conditions. A safety case connects these physical premises to the release claim step by step, so an assessor can see which guarantees rest on measurements and which remain unverified assumptions.

16.3.1 Claims, arguments, and warrants

A bundle of test logs and benchmark plots gives a release reviewer no way to tell which physical claims the data actually support or where an unstated assumption hides. A safety case is auditable only when its logic is written down in a form that another engineer can inspect and challenge link by link. Two notations are widely used in practice, and both capture the same structure. The claim-argument-evidence (CAE) framework divides the case into three parts: the claim, a statement about system behavior that is either true or false; the argument, the causal or inductive reasoning connecting the claim to retained support; and the evidence, the calibrated measurements, justified analyses, and validated operating procedures (Bishop and Bloomfield 1998; Bloomfield and Netkachova 2014). Goal Structuring Notation (GSN) draws the same structure as a directed graph: top-level goals (claims) split through explicit strategies (arguments) into concrete solutions (evidence items), while context and assumption nodes state the operating envelope within which each link holds (Kelly 1998; Kelly and Weaver 2004). The fault injection records enter this graph directly as solutions supporting each named sub-claim. Because release adjudication turns an assurance graph into a binding operational authorization, the safety case of definition 16.1 evaluates directly to an enforceable release verdict.

Bloomfield, Robin, and Kateryna Netkachova. 2014. “Building Blocks for Assurance Cases.” IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW), 186–91. https://doi.org/10.1109/ISSREW.2014.72.

Kelly, Tim, and Rob Weaver. 2004. The Goal Structuring Notation: A Safety Argument Notation.

↩︎ The fault-record set, in which every record names the one release claim it supports, is established in The fault-record set specification.

² Toulmin’s Argument Anatomy: The Uses of Argument (Toulmin 1958) splits practical reasoning into claim, data, warrant, backing, qualifier, and rebuttal. Safety cases preserve this anatomy: evidence supplies the data, stated confidence acts as the qualifier, and the rebuttal becomes the defeater evaluated during adversarial review (section 16.7).

Toulmin, Stephen E. 1958. The Uses of Argument. Cambridge University Press.

Koopman, Philip. 2023. “UL 4600: What to Include in an Autonomous Vehicle Safety Case.” Computer 56 (5): 101–4. https://doi.org/10.1109/MC.2023.3236171.

Favaro, Francesca, Laura Fraade-Blanar, Scott Schnelle, Trent Victor, Mauricio Peña, Johan Engstrom, John Scanlon, Kris Kusano, and Dan Smith. 2023. “Building a Credible Case for Safety: Waymo’s Approach for the Determination of Absence of Unreasonable Risk.” arXiv Preprint arXiv:2306.01917.

This decomposition comes from Stephen Toulmin’s model of practical argumentation² (Toulmin 1958). In industrial practice, standards such as ANSI/UL 4600 require goal-based safety cases for autonomous physical products (UL Standards & Engagement 2023; Koopman 2023). Production autonomous fleets use this same structure; for example, Waymo organizes the safety case for its driverless ride-hailing operations around layered, dynamic claims showing the absence of unreasonable risk, arguing separately that its risk acceptance criteria are complete and that their empirical evaluation is sound (Favaro et al. 2023). For an embodied robot, the root claim \(\AssuranceClaim_0\) states a testable physical invariant, such as a stopping distance inside the surveyed aisle clearance (\(\StoppingDistance \le \ClearDistance\)) or a bounded collaborative contact force (\(\CollaborativeContactForce \le \AssessedContactForceLimit\)). Supporting sub-claims name the required mechanical, electrical, and computational conditions, and retained measurements, derivations, or validated procedures back each leaf. Writing these relationships as a directed acyclic graph (DAG) exposes intermediate dependencies and rules out circular reasoning, so a reviewer can trace any operational claim down to its physical measurements and operating assumptions.

Definition 16.1: Claim-argument-evidence safety case

Claim-argument-evidence safety case is a structured argument that a named machine, in a stated operating envelope and under a stated fault model, meets explicit physical criteria, written as claims that decompose through stated arguments into retained evidence.

1. Significance: It makes a release decision checkable one link at a time. For the warehouse machine, the three inequalities of equation 1 become six claims whose leaves are individual premises, and a reviewer can find the one premise, such as a braking deceleration no loaded trial has measured, on which the verdict turns.
2. Distinction: A test report or benchmark score records what happened under the conditions sampled. A safety case states why that evidence supports a claim about conditions the machine has not yet met, and names the assumptions under which the reasoning stops holding.
3. Common pitfall: A frequent misconception is that the case is paperwork assembled after development for a regulator. It is written with the design, and in this book’s architecture its verdict decides what the permission path lets the machine do.

The soundness of this argument DAG depends on keeping evidence distinct from demonstration. A demonstration records successful task execution across an uncharacterized test set, such as a string of clean door openings with the strike plate at its nominal position or a thousand collision-free warehouse runs. Demonstrations show nominal performance across observed runs, but they give no mathematical or statistical bounds on tail behavior, sensor faults, or corner cases outside those logged runs. Evidence, by contrast, consists of falsifiable, calibrated records with stated uncertainty bounds: an execution-time distribution measured on a hardware logic analyzer paired with worst-case execution time (WCET) bounds, loaded stopping trials across degraded friction surfaces, or hardware-in-the-loop (HIL) fault-injection traces at envelope corners. The evidence must match the scope of the claim. Nominal trials can support nominal capability claims, and calibration logs can validate sensor coordinate frames, but bounding an envelope limit or worst-case response requires systematic coverage, stated uncertainty margins, and an explicit warrant.

Connecting evidence to a claim requires a warrant, the reasoning principle that explains why the measured data support the claim. For a learned neural policy, teams often reach for an inductive warrant, arguing from thousands of failure-free test episodes to future operational reliability. The exposure wall analyzed in Verification Ceilings and the Exposure Wall shows why purely inductive warrants cannot support catastrophic hazard claims. At 95 percent confidence the zero-failure exposure wall of equation 7.9 becomes \(\Time \ge 3.0/\ConstantHazardRate\) (because \(\ln 20 \approx 3.0\)), where \(\ConstantHazardRate\) is the failure rate per operating hour to be demonstrated, so statistically proving an ultra-low failure rate of \(10^{-9}\) per operating hour requires billions of operating hours without a single failure (Butler and Finelli 1993; Kalra and Paddock 2016). Deciding what target rate is acceptable in the first place is an engineering and societal judgment that empirical testing cannot make on its own (Koopman 2022).

Koopman, Philip. 2022. How Safe Is Safe Enough? Measuring and Predicting Autonomous Vehicle Safety. Independently published.

Hawkins, Richard, Colin Paterson, Chiara Picardi, Yan Jia, Radu Calinescu, and Ibrahim Habli. 2021. “Guidance on the Assurance of Machine Learning in Autonomous Systems (AMLAS).” arXiv Preprint arXiv:2102.01564.

A sound safety case bridges this gap with deterministic architectural warrants. Rather than betting physical safety on policy generalization, the system grounds its top-level safety claims in an independent permission path. That path evaluates the control barrier functions of Safe Sets as Conditional Permission to clamp actuator commands, and commands an assessed safe stop whenever a learned proposal approaches the boundary of the viable set \(\ForwardInvariantSafeSet\). The architectural warrant narrows the claim rather than escaping physical limits: the permission path protects only against monitored hazards that the actuators can arrest within the available stopping clearance, while the learned proposer still needs its own operational argument to show task capability and handle unmonitored tasks. Recent standards formalize these complementary roles: ISO/PAS 8800:2024 adapts automotive safety lifecycles, data curation rules, and assurance arguments to AI components (International Organization for Standardization 2024b), while the Assurance of Machine Learning in Autonomous Systems (AMLAS) framework supplies safety-case patterns for machine learning pipelines across autonomous systems (Hawkins et al. 2021). In this book’s architecture, the permission path carries the safety argument for all monitored physical hazards, anchoring its formal claims to a rated watchdog and to the certified functions beneath it in the drives, the safety-rated laser scanner, and the arm’s safety controller (section 16.3.4). The learned proposer’s argument can then focus on operational availability and unmonitored mission tasks.

↪ How much an architectural shield’s per-command guarantee dilutes into a system-level hazard rate is developed in Conditional shield credit and common-cause bounds.

16.3.2 Contextual assumptions and the weakest link

A stopping test passed on clean, dry concrete under bright warehouse lamps can fail the first time the robot enters a dim aisle if the safety case never stated the lighting assumption behind its camera exposure time. Every physical measurement rests on ambient conditions, and moving the machine into a dimly lit aisle can lengthen camera exposure and observation age even when the mechanical brakes and tires behave identically. An assurance argument must state these contextual assumptions explicitly so that measurements gathered under one set of conditions are never credited outside their verified operating envelope.

When an operating assumption is left unstated, safety depends entirely on whether a downstream check happens to catch the resulting deviation. In the mobile manipulator’s stopping budget, the warrant quietly assumes that warehouse illumination permits the navigation camera to operate at its nominal exposure. If dim lighting doubles that exposure time from 16 ms to 32 ms, the observation arrives 8 ms older than assumed (measuring exposure age from mid-frame). Left unchecked, this additional latency translates to 10.4 mm of extra travel at the robot’s 1.3 m/s aisle velocity, consuming roughly 8 percent of the budget’s 131.0 mm margin. On this machine the permission path’s frame admission age check, the freshness test of the observation contract (The Observation Contract), rejects the delayed frames. Because an active chunk can execute only while its evidence and lease remain valid, the robot instead halts in an aisle where the design assumed it could run. The team meets the unstated lighting assumption as unexplained availability loss rather than as a collision, and what kept the blind spot from eroding clearance was a latency check that knows nothing about illumination. A design without that check would have spent the margin silently.

Assumptions that lack runtime monitors carry far greater danger. Mechanical drift in a camera mount can introduce steady-state calibration offsets while every frame passes freshness and timestamp validations. The safety case must explicitly link localization tolerances to calibration routines and physical inspection logs. Treating fresh telemetry as proof of accurate spatial calibration leaves that critical warrant completely unsupported.

↪ Premises that no sensor on the machine can observe, and the restrictions they force on a release claim, are developed in What the release claim rests on.

A safety case is not an aggregate scorecard in which high performance in one branch compensates for a deficit in another. Benchmark accuracy on an object recognition dataset cannot offset an uncharacterized latency tail on a CAN FD (Controller Area Network with Flexible Data-Rate) bus, nor can millions of simulated training episodes compensate for missing brake-wear measurements. When every child claim is required, the argument is conjunctive, and it is no stronger than its weakest required premise. In practice it is usually weaker, because doubt across independent premises accumulates. For a stipulated probability model, let each event mean that one required premise is valid under its stated conditions, and let \(\RequiredPremiseConfidence_1, \dots, \RequiredPremiseConfidence_n\) be the assigned event probabilities. These are not finite-trial confidence levels and estimate neither this robot’s measured hazard rate nor calibrated assurance confidence. Define the illustrative claim event \(\AssuranceClaim\) exactly as the conjunction of these independent events; its probability is their product: \[\Pr(\AssuranceClaim) = \prod_{i=1}^{\RequiredPremiseCount} \RequiredPremiseConfidence_i. \tag{2}\]

If each of 10 required premises holds with assigned probability 0.99, the conjunction holds with only about 0.90, lower than any individual premise. The mobile base’s stopping claim is conjunctive in exactly this way. Surveyed clear distance, credible braking deceleration, brake onset latency, observation age, and localization and tracking tolerances all enter a single stopping budget. A flawed warrant in any single term invalidates the root claim, regardless of how thoroughly the other terms are documented. An assessor therefore focuses not on the gross volume of supporting documentation, but on the least supported required premise and the number of premises sharing the claim.

This conjunctive degradation has one principled engineering exception. An argument can support a claim through two independent legs, either of which suffices on its own, so that the claim fails only if both legs fail simultaneously (Bloomfield and Littlewood 2003). In a separate stipulated model, define \(\AssuranceClaim\) exactly as the union of \(\ArgumentLegCount\) independent sufficient-leg events with assigned probabilities \(\ArgumentLegConfidence_1, \dots, \ArgumentLegConfidence_{\ArgumentLegCount}\). The event holds unless all legs fail: \[\Pr(\AssuranceClaim) = 1 - \prod_{j=1}^{\ArgumentLegCount} (1 - \ArgumentLegConfidence_j). \tag{3}\]

³ Independence of Diverse Legs: When independently written versions of a software specification were evaluated on identical inputs, they failed coincidentally far more frequently than independent failure models predicted, statistically rejecting the independence assumption (Knight and Leveson 1986). Design diversity does not by itself yield independence in failure.

Knight, John C., and Nancy G. Leveson. 1986. “An Experimental Evaluation of the Assumption of Independence in Multiversion Programming.” IEEE Transactions on Software Engineering SE-12 (1): 96–109. https://doi.org/10.1109/TSE.1986.6312924.

If each of two independent legs holds with assigned probability 0.90, the combined claim holds with roughly 0.99, well above either leg alone. The equality describes the stipulated event model. If sufficient-leg events merely imply a broader physical claim, their union probability supplies a lower bound rather than automatically equaling the probability of that claim. The third law, proposal is not permission, instead supplies a conditional architectural argument: a policy error alone cannot breach a monitored stopping or contact invariant while the qualified enforcer, plant, sensing, timing, and fault premises hold. Having both policy validation and per-tick permission checks does not justify assigning independent probabilities to their success.³ Claim C5 in table 2 requires evidence that shared processors, memory buses, power rails, or sensor pipelines cannot compromise the permission path under the credited fault and interference model. Such isolation evidence addresses common causes within its qualified scope; it does not alone establish every statistical independence assumption. If the event independence is unsupported, the two-leg probability calculation is unavailable; shared causes must be represented explicitly in the argument. The enforcer leg is itself conjunctive across its own physical premises, because claims C1 through C4 must all hold for the enforcer to function. Diverse legs protect against policy failure; they cannot make up for unmeasured brake physics or missing timing margins, so the reviewer must check every leaf against the actual plant.

16.3.3 Matching the argument to the machine

Flawless arithmetic on assumed braking and latency numbers proves only that the robot would stop in time if the numbers were true; it says nothing about whether the physical machine on the floor actually meets them. While analytical stopping models relate brake onset, deceleration, sensor age, and tracking error cleanly on paper, an equation is only as sound as its physical inputs. A release reviewer must check which parameters come from measurements on the production hardware and which remain unverified design assumptions.

For collaborative manipulation tasks, biomechanical thresholds govern the contact force argument once the claim explicitly details the target body region, contact classification (transient vs. quasi-static), pressure distribution, impact geometry, and measurement methodology (International Organization for Standardization 2025b). The mobile base’s claims, which form the core of the release argument, derive directly from empirical stopping distance budgets and site survey logs. Two conceptual frameworks borrowed from automotive engineering organize the fault analysis. Functional safety mitigates hazards arising from hardware malfunctions or systematic software defects (International Organization for Standardization 2018). In contrast, Safety of the Intended Functionality (SOTIF) addresses hazards stemming from performance insufficiencies or specification gaps in the absence of hardware faults, such as an obstacle detector failing to recognize a worker partially obscured by shrink-wrapped pallet staging (International Organization for Standardization 2022). Every leaf of the release argument requires support appropriate to its premise: qualified plant and timing observations, justified analysis, or validated operating restrictions under explicit assumptions. The formal standards governing these subsystems are machinery safety standards, mapped in section 16.3.4 to each component.

Goodenough, John B., Charles B. Weinstock, and Ari Z. Klein. 2013. “Eliminative Induction: A Basis for Arguing System Confidence.” 2013 35th International Conference on Software Engineering (ICSE), 1161–64. https://doi.org/10.1109/ICSE.2013.6606668.

The claim-argument-evidence scorecard in table 2 defines six core release claims, pairing each physical warrant with its adjudication against the evidence developed in this book. Claim C3 shows how a warrant fails. An unnoticed oil slick on a polished concrete floor destroys wheel traction and invalidates the nominal deceleration model. A physically realizable condition that invalidates an assurance warrant in this manner is a defeater (Goodenough et al. 2013). Adversarial safety review hunts for these defeaters (section 16.7). Similarly, Claim C6 depends strictly on test records validating the four supervisory authority handoff rules (A1–A4) established in Per-tick evidence tuples and the fault injection suite. Drawn as an assurance DAG (figure 1), the argument splits C1 into its three physical scenarios (base stop, door latch, mug handover), ends every branch in a premise leaf whose outline records the maturity of its evidence, and attaches the oil-film defeater directly to C3. Because no leaf has been measured on the loaded production configuration, every row of the scorecard evaluates to REFUSE, the verdict that grants no operating permit and commands an assessed stop or hold (section 16.4); section 16.6 works through why, branch by branch.

Figure 1: The release argument as a graph: The top claim C0 decomposes into the six claims of table 2, with C1 split into the base stop, the door latch, and the mug handover. Each leaf is a premise with its value, and its outline marks the status of its evidence. Every leaf is illustrative, declared, or unknown, none is measured on the proposed configuration, and the clear oil film attacks C3 directly, so the graph as drawn supports only REFUSE.

Table 2: Claim-argument-evidence review for the warehouse mobile manipulator: Six claims and their adjudication on this book’s evidence. Displayed stopping distances and waiting allowances are partial calculations; admission work, physical response, and required reserve must be charged at their own events. A failed or unknown branch cannot be compensated by nominal model accuracy.

Claim	Warrant and operating assumptions on the machine	Adjudication on the book’s evidence
C1. Contact and stopping	Base: partial budget of 969.0 mm before dispatch-to-admission delay, at 1.3 m/s (The warehouse mobile manipulator's stopping budget) inside the 1.10 m clear distance to a person standing at the rack end, with the payload untested at 368 kg an open premise; Door: latch force of 39 N at physical braking onset, with the arm stopping within a further 0.15 mm (about 3 m/s²) under the 100 N limit; Mug: picked from the conveyor under the 1 m/s tool center point (TCP) limit on tracked intent and handed to the coworker at 0.10 m/s, under the derived 0.24 m/s transient-contact ceiling, with a contact force of 20.7 N under the 50 N criterion for a free hand, a handover geometry that excludes clamping, and the grasped object taken to be the mug the task names	REFUSE: credible deceleration, brake onset, tracking and localization error, and arm deceleration are illustrative; the hand body model is a standard’s population value, not a measurement of this contact; the no-clamping and grounding premises are unknown
C2. Permission timing	Brake onset no later than 82 ms after the last valid renewal; enforcer WCET of 250 μs inside the 400 μs deadline; declared assumptions: the claim covers only faults the permission path survives, lockstep diagnostics cover the path’s own failure (Two Paths and the Resources They Share), and the INHIBIT rung of the fallback ladder is credited with no stopping distance, so the claim rests on the powered STOP rung (The four rungs of the fallback ladder)	REFUSE: the declared WCET lacks supporting architectural analysis and loaded stress evidence
C3. Braking traction	Optimistic all-weight friction screen of 0.204; qualified loaded stopping at the maintained friction floor is also required; a clear oil film is the defeater	REFUSE; the open premise passes to A residual-claims register
C4. Observation age	Navigation-camera dispatch age of 51.6 ms; evidence continues aging through admission and execution, with event-specific thresholds and a stale-data fallback	REFUSE: the age chain is illustrative
C5. Permission independence	The placement record combines a justified execution bound with loaded stress tests whose observed maxima stay within the declared 250 μs WCET, and so below the deadline, and common causes are tested (The Placement Record)	REFUSE until the placement test report exists
C6. Authority transfer	One writer per actuator channel; no source bypasses a higher authority tier or the permission check; an unacknowledged handover falls back by the clearance-derived \(\HandoverTimeout\) of Clearance-derived fallback deadlines (partial allowances before \(\DispatchAdmissionInterval\): 751.6 ms at the preliminary 0.75 m/s in-loop screen, 100.8 ms for a request at 1.3 m/s; because neither moving screen is a signed limit, the operative design stops the base before handing over); invalid authentication rejects the new packet without revoking an otherwise valid active owner (Per-tick evidence tuples and the fault injection suite)	REFUSE if any of A1–A4 lacks a PASS fault record (The fault-record set specification); restrict to local operation if only the remote-channel cases fail

Checkpoint 16.1: Safety case decomposition and warrants

Before presenting a safety case for adjudication, test its structure:

• Top-level claim falsifiability: Can you state the top-level claim as a falsifiable physical proposition, such as a stop inside the clear distance, rather than an aspiration?
• Warrant validity: Can you name the warrant connecting each test bench to the claim above it, and the premises under which that warrant holds?
• Defeater enumeration: Can you show where a defeater such as lens fouling or bus arbitration collisions appears in the argument graph?
• Evidentiary provenance: Can you trace each empirical evidence node to its signed test trace and current calibration, and each analytical or procedural node to its retained derivation, assumptions, or accountable procedure and validation?

The scorecard enforces a strict separation between physical safety requirements and the empirical records available to substantiate them. Even when every internal warrant is traced to a hardware measurement, however, an engineering team does not choose its own risk-reduction hierarchy or protective ratings in a vacuum. The release reviewer must keep this evidentiary discipline across the entire assurance tree while verifying which external machinery and regulatory standards govern each branch.

16.3.4 The standards map for the running machine

Certifying an industrial mobile manipulator against road-vehicle standards, or against fixed-arm standards that ignore a moving base, leaves the hazards of a moving arm on a moving base uncovered. Before authorizing deployment, an assessor must establish which formal standards and regulations govern each subsystem and verify where the corresponding evidence was gathered. Because this running machine is an industrial mobile manipulator rather than an autonomous road vehicle, its formal certification path follows industrial machinery directives rather than automotive standards. ISO 12100 sets the overall risk-management framework: the engineering team identifies hazards, evaluates risk, and applies a three-step reduction hierarchy—inherently safe design first, engineered safeguards second, and user warnings and operating procedures last (International Organization for Standardization 2010). Every standard in table 3 addresses a specific tier of this hierarchy. Autonomy and automotive standards enter as borrowed engineering methods, supplying vocabulary for learned policies, distribution shifts, and assurance cases that traditional industrial standards are only beginning to adopt.

Table 3: Standards map for the warehouse mobile manipulator (as of 2026): Each document, its edition, what it governs, the part of the running machine it covers, and the section that produces the evidence it asks for. Machinery standards form the certification route; the road-vehicle and autonomy documents are borrowed method. Editions and dates change; a later printing should refresh this table.

Standard or regulation	Edition (as of 2026)	What it governs	Where it applies on the running machine	Applied in
ISO 12100 (International Organization for Standardization 2010)	2010	Risk assessment and three-step risk reduction for any machine	The hazard list behind C1 to C6	Deriving the Fault List
ISO 13849-1 (International Organization for Standardization 2023a)	2023 (4th ed.)	Safety-related parts of control systems, rated by performance level (PL a to e)	The safety MCU’s lease-expiry and heartbeat watchdog that fires STO or SS1; enabling devices. The admission checks are not rated	Certified safety functions beneath the permission path, Two Paths and the Resources They Share, Execution leases and three-position enabling hardware
IEC 61508 (International Electrotechnical Commission 2010)	2010 (2nd ed.)	Generic functional safety of electrical, electronic, and programmable systems, rated by safety integrity level (SIL); parent of the drive and sector standards	The same watchdog and stop trigger as rated MCU firmware, and its freedom from interference	Hardware Isolation and Fault Containment, Silicon Isolation Decisions
IEC 61800-5-2 (International Electrotechnical Commission 2016b)	2016 (2nd ed.)	Safety functions of power drives: Safe Torque Off (STO), Safe Stop 1 (SS1), safely limited speed	Base and arm drives; the stop sequence	Actuation Authority, Industrial stop categories and the safe torque off trap
IEC 60204-1 (International Electrotechnical Commission 2016a)	2016	Electrical equipment of machines, including stop categories 0, 1, and 2	The stop category each fallback rung realizes on the drives	Industrial stop categories and the safe torque off trap
ISO 3691-4 (International Organization for Standardization 2023b)	2023 (2nd ed.)	Driverless industrial trucks and their systems: personnel detection, stopping, operating zones	Mobile base in the aisles; the site crossing rule	Stopping Envelopes, Forward State Propagation and Occlusion Decay
ISO 13855 (International Organization for Standardization 2024a)	2024 (3rd ed.)	Positioning of safeguards with respect to the approach of the human body	The scanner’s protective field; the approach speed \(\HumanWalkingSpeedBound\)	Certified safety functions beneath the permission path
ISO 10218-1 and -2 (International Organization for Standardization 2025a, 2025b)	2025	Industrial robots (Part 1); robot applications and cells, including the collaborative-application requirements formerly published as ISO/TS 15066 (Part 2). Part 2 excludes the hazards of mobility when a manipulator is integrated with a mobile platform	The arm, door opening, mug handover; not the arm moving on the base	Intentional contact and in-contact energy barriers, Execution leases and three-position enabling hardware
ISO/TS 15066 (International Organization for Standardization 2016)	2016; under revision	Body model and body-region force and pressure data for collaborative contact; remains published	The hand values \(\BodyRegionMass\) and \(\HertzianContactStiffness\) in the handover contact case	Intentional contact and in-contact energy barriers
ANSI/A3 R15.08-1 and -2 (Association for Advancing Automation 2020, 2023)	2020 (reaffirmed 2026); 2023	Industrial mobile robots in North America: the robot, including one that carries a manipulator (IMR Type C) (Part 1); IMR systems and applications (Part 2)	The whole machine, including the arm moving on the base that ISO 10218-2 excludes	This chapter; Certified safety functions beneath the permission path
ISO 26262 (International Organization for Standardization 2018)	2018 (2nd ed.)	Road-vehicle functional safety: hazards from random hardware and systematic faults	Borrowed method: fault decomposition, confirmation of safety work	The fault-record set specification
ISO 21448 (International Organization for Standardization 2022)	2022	Road-vehicle safety of the intended functionality: hazards without a fault	Borrowed method: perception and proposer insufficiencies	The fault-record set specification, Operational design domain blind spots and unsafe interpolation
ANSI/UL 4600 (UL Standards & Engagement 2023)	3rd ed., 2023	Goal-based safety case for autonomous products, with safety performance indicators and independent assessment	The release argument and its field monitoring	section 16.3.1, section 16.9.5
ISO/PAS 8800 (International Organization for Standardization 2024b)	2024	Safety of AI elements in road vehicles: AI safety lifecycle, data, assurance argument	Borrowed method: the learned proposer and its data	The Dataset Schema, The Evaluation Record
Regulation (EU) 2023/1230 (European Parliament and Council of the European Union 2023)	Applies from 20 January 2027	EU Machinery Regulation: essential requirements, third-party assessment for machine-learning safety functions, substantial modification	The whole machine on the EU market; its over-the-air updates	section 16.9.1
Regulation (EU) 2024/2847 (European Parliament and Council of the European Union 2024b)	Applies from 11 December 2027	Cyber Resilience Act: cybersecurity requirements for products with digital elements, vulnerability handling, security updates	The update channel, the signed images, and the fleet’s vulnerability reports	section 16.9.1

International Organization for Standardization. 2010. ISO 12100:2010: Safety of Machinery, General Principles for Design, Risk Assessment and Risk Reduction. International Organization for Standardization.

International Organization for Standardization. 2023a. ISO 13849-1:2023: Safety of Machinery, Safety-Related Parts of Control Systems, Part 1: General Principles for Design. International Organization for Standardization.

International Electrotechnical Commission. 2010. IEC 61508:2010: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems. International Electrotechnical Commission.

International Electrotechnical Commission. 2016b. IEC 61800-5-2:2016: Adjustable Speed Electrical Power Drive Systems, Part 5-2: Safety Requirements, Functional. International Electrotechnical Commission.

International Electrotechnical Commission. 2016a. IEC 60204-1:2016: Safety of Machinery, Electrical Equipment of Machines, Part 1: General Requirements. International Electrotechnical Commission.

International Organization for Standardization. 2023b. ISO 3691-4:2023: Industrial Trucks, Safety Requirements and Verification, Part 4: Driverless Industrial Trucks and Their Systems. International Organization for Standardization.

International Organization for Standardization. 2024a. ISO 13855:2024: Safety of Machinery, Positioning of Safeguards with Respect to the Approach of the Human Body. International Organization for Standardization.

International Organization for Standardization. 2025a. ISO 10218-1:2025: Robotics, Safety Requirements, Part 1: Industrial Robots. International Organization for Standardization.

International Organization for Standardization. 2018. ISO 26262:2018: Road Vehicles, Functional Safety. International Organization for Standardization.

International Organization for Standardization. 2022. ISO 21448:2022: Road Vehicles, Safety of the Intended Functionality. International Organization for Standardization.

International Organization for Standardization. 2024b. ISO/PAS 8800:2024: Road Vehicles, Safety and Artificial Intelligence. International Organization for Standardization.

Two standards in the map require a clear boundary because the running machine straddles mobile robotics and fixed manipulation. ISO 10218-2:2025 governs industrial robot systems and collaborative work cells, but it explicitly excludes the kinetic hazards introduced when a manipulator rides on a mobile platform (International Organization for Standardization 2025b), which is this warehouse machine’s configuration. Conversely, ISO 3691-4 treats the mobile base as a driverless industrial truck. The standard that bridges this gap by treating the mobile manipulator as a single unit is ANSI/A3 R15.08. Mounting an active manipulator on a mobile platform classifies the machine as an Industrial Mobile Robot (IMR) Type C, and Part 2 sets the safety requirements for integrating that combined unit into an active facility (Association for Advancing Automation 2020, 2023). In jurisdictions where R15.08 lacks statutory standing, the combined hazards of mobility and manipulation fall back onto the machine’s primary ISO 12100 risk assessment.

Association for Advancing Automation. 2020. ANSI/A3 R15.08-1-2020: Industrial Mobile Robots, Safety Requirements, Part 1: Requirements for the Industrial Mobile Robot. Association for Advancing Automation.

Association for Advancing Automation. 2023. ANSI/A3 R15.08-2-2023: Industrial Mobile Robots, Safety Requirements, Part 2: Requirements for IMR System(s) and IMR Application(s). Association for Advancing Automation.

A second boundary concerns which layers of the permission path carry formal safety ratings. As Certified safety functions beneath the permission path established, the only rated function within the permission path is the safety MCU’s lease-expiry and heartbeat watchdog, which asserts Safe Torque Off (STO) or Safe Stop 1 (SS1) on the motor drives when valid renewals cease; the admission checks that evaluate neural proposals carry no rating, and the certified functions of the motor drives, the safety-rated laser scanner, and the arm’s safety controller sit beneath the permission path. For release, the formal protective claims for every monitored hazard therefore rest on that watchdog and that certified layer. The release argument still uses the software admission checks for operational utility and nominal hazard prevention, but any hazard claim that depends only on unrated software remains an empirical premise rather than a certified safety function.

Statutory compliance reaches physical AI through product-safety law rather than through standalone artificial intelligence rules, and its sharpest consequence for release concerns updates. Under the European Union’s Machinery Regulation (European Parliament and Council of the European Union 2023), a substantial modification is any physical or digital change made after deployment that the original manufacturer did not foresee and that introduces a new hazard or raises an existing risk enough to require additional safeguarding. An organization that pushes an unverified over-the-air model update can therefore become, in law, the manufacturer of the modified machine, with every obligation that role carries (section 16.9.1). The same regulation requires third-party conformity assessment⁴ for machinery whose safety components have fully or partially self-evolving behavior and use machine learning to execute safety functions, so a learned safety function cannot be self-certified. Its essential requirements also constrain learning directly: the limits of each safety function must be documented in the manufacturer’s risk assessment, and no rule or parameter the machine generates, even during a learning phase, may change those limits where the change could create a hazardous situation (Annex III, section 1.2.1). Keeping the learned proposer outside the permission path meets that requirement only if the safety argument does not depend on the proposer’s learned behavior. Two neighboring acts reach the same machine. The EU AI Act, Regulation (EU) 2024/1689 (European Parliament and Council of the European Union 2024a), as amended in July 2026 by Regulation (EU) 2026/1744 (European Parliament and Council of the European Union 2026), places the Machinery Regulation in Section B of its Annex I, so AI-specific safety rules for machines arrive through the machinery framework. The Commission must adopt delegated acts that insert those rules into the Machinery Regulation’s Annex III and that apply by 2 August 2028. Because the robot receives network updates, it is also a product with digital elements under the Cyber Resilience Act (European Parliament and Council of the European Union 2024b), which requires vulnerability handling and secure updates throughout the manufacturer’s support period, at least five years unless the product is expected to be in use for less; its duty to report actively exploited vulnerabilities applies from 11 September 2026, ahead of the rest of the act. Table 3 lists the dates from which the other obligations apply. These milestones do not alter the underlying physics or systems engineering; they set the calendar dates by which statutory authorities will demand an inspectable assurance case.

⁴ Conformity Assessment: The formal procedure through which a manufacturer certifies that a machine fulfills all essential health and safety requirements before affixing the CE marking (European Parliament and Council of the European Union 2023). While manufacturers may self-assess conventional machinery, high-risk systems and self-evolving AI safety components require third-party evaluation by a notified body. Because the conformity assessment path is fixed before market entry, every record in the release manifest must be formatted for independent inspection.

European Parliament and Council of the European Union. 2023. Regulation (EU) 2023/1230 of the European Parliament and of the Council of 14 June 2023 on Machinery and Repealing Directive 2006/42/EC and Council Directive 73/361/EEC. Official Journal of the European Union, L 165, 29.6.2023, p. 1.

European Parliament and Council of the European Union. 2024a. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 Laying down Harmonised Rules on Artificial Intelligence (Artificial Intelligence Act). Official Journal of the European Union, L series, 2024/1689, 12.7.2024.

European Parliament and Council of the European Union. 2026. Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 Amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as Regards the Simplification of the Implementation of Harmonised Rules on Artificial Intelligence (Digital Omnibus on AI). Official Journal of the European Union, L series, 2026/1744, 24.7.2026.

European Parliament and Council of the European Union. 2024b. Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on Horizontal Cybersecurity Requirements for Products with Digital Elements and Amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union, L series, 2024/2847, 20.11.2024.

The standards map also marks the boundary between statutory obligations and the systems architecture developed in this book. Formal standards prescribe documented arguments, rated protective functions, and independent third-party assessments. The verdicts, signed capability descriptors, and release manifest developed in the rest of this chapter are one engineering architecture for carrying those obligations into the runtime system, so that the safety case accepted before deployment stays binding on the machine long after the inspectors have left the floor.

16.4 The Three Verdicts

Treating a release sign-off as an informal paper memo forces teams either to ground a useful machine over an unmeasured corner case or to wave it onto the floor with unproven assumptions. Every row of table 2 ends in an adjudication, and the release decision resolves the entire assertion DAG into one of three verdicts: unconditional operation, conditional operation, or refusal to operate. In this book’s architecture, these verdicts are cryptographically signed capability descriptors loaded into the real-time safety microcontroller before motor power stages are energized, not advisory certificates or administrative paperwork. A valid descriptor is the machine’s operating permit: while it holds, the permission path may admit the policy’s tracking commands inside the envelope the descriptor names, and when it is revoked or absent, the permission path admits none. Although safety standards do not mandate this specific mechanism (section 16.3.4), the qualified gate and permission path enforce the authenticated descriptor’s limits on physical operation. The first verdict, unconditional operation (UNCOND), authorizes tracking proposals across the full operating envelope specified in a signed release manifest, provided its standing conditions remain continuously verified. Each hazard claim in that safety case requires qualified measurements, justified analysis, or validated operating restrictions applicable to the specified physical plant, payload distribution, operational design domain, and fault set. Brake thermal capacity, stopping clearance, and tracking-error bounds must all be qualified for that envelope, and independent permission checks must stand wherever learned policy proposals can reach physical actuators. The verdict does not eliminate residual or newly emergent hazards; it authorizes operation solely under the assessed claims and requires detection and safe withdrawal within the qualified response budget whenever a physical premise fails.

Definition 16.2: Release verdict

Release verdict is the signed decision that sets how much authority a named machine’s permission path may grant: UNCOND for the full assessed operating envelope, COND for a separately evidenced restricted envelope, or REFUSE when any required premise is missing, contradicted, or unknown, in each case only while its standing conditions hold.

1. Significance: It turns the weakest premise of the argument into the machine’s operating limit on \(\StoppingDistance \le \ClearDistance\). On this book’s illustrative evidence every claim carries an unknown premise, so the warehouse machine’s verdict is REFUSE; a stipulated set of loaded stopping and floor records would support a COND at 1 m/s on inspected floors, below the 1.23 m/s optimistic all-weight partial ceiling.
2. Distinction: A test result records the outcome of an individual trial, whereas a degraded mode is an autonomous runtime fallback triggered during execution. By contrast, a release verdict is established before deployment: it names the qualified envelope and the empirical evidence upon which it rests, while leaving the proposal boundary fixed, since the permission path continues to validate every proposed action individually.
3. Common pitfall: A common misconception is that a conditional verdict (COND) can patch an incomplete safety case by ignoring an unproven claim. A restricted envelope instead demands its own dedicated evidence and analytical limits; an unresolved premise in the primary case leaves that operating mode firmly refused.

16.4.1 Restricted operation and access boundaries

When a safety case lacks evidence for full-speed aisle travel or open-floor contact, letting the robot run under an informal operating note leaves the permission path enforcing the wrong limits. The second verdict, conditional operation (COND), applies when empirical evidence supports the stated hazard claims within a restricted subset of the envelope and binds the permission path to those narrower limits. In the running machine, COND selects a pre-validated safety configuration, much like industrial safety controllers and protective optical scanners switch between pre-validated field sets⁵ and speed-monitoring profiles. All restricted kinematic thresholds (\(\SpeedBound \le \RestrictedSpeedBound\), \(\ProfileAccelerationBound \le \RestrictedAccelerationBound\)) and spatial geofences are evaluated and validated as one configuration before release; the runtime verdict selects among these vetted profiles rather than inventing parameters on the fly. Whereas a conditional verdict (COND) is an offline, predeployment contract that restricts the machine’s operating envelope until re-adjudication, a degraded mode is an online runtime fallback, pre-assessed and named in the signed release, that the permission path invokes when an active subsystem loses telemetry or sensor redundancy (section 16.5.3 sizes one for the base). Release then enforces physical, kinematic, or environmental boundaries that exclude unverified hazard states, such as de-rated joint speeds, a restricted illumination range, or a physical barrier that keeps humans outside the manipulator’s workspace. Where contact force cannot be bounded for unseparated co-presence, a restricted release case may require physical separation: figure 2 illustrates yellow perimeter mesh fencing around an industrial workcell. Crediting that separation requires validated access-interlock and stopping evidence showing that the protective response completes before hazardous access.

⁵ Safety Scanner Field Sets: A safety laser scanner stores several protective-field geometries that were configured and validated in advance, and a safety controller selects one of them from encoded speed or position inputs. The scanner never computes a new field at runtime. COND borrows the pattern, so the verdict selects a pre-assessed limit set and no untested parameter can reach the permission path.

Figure 2: Physical separation example: A yellow industrial arm works behind yellow mesh fencing. Fencing can be one condition of a restricted release when a validated access interlock and stopping test support it. (Photo: PEO ACWA, Pueblo Chemical Agent-Destruction Pilot Plant, 2012, Wikimedia Commons, CC BY 2.0.)

Fencing excludes unseparated contact by keeping people out of the hazardous volume. The alternative that lets people share the floor, speed and separation monitoring (SSM, Certified safety functions beneath the permission path), needs a fundamentally different access claim from the stationary-person stopping claim of C1. Its separation clearance must account for human approach velocity across both system reaction time and physical deceleration, robot displacement before brake onset, the executed braking profile, and measurement uncertainty. The warehouse case retains its site crossing rule; engineering teams cannot substitute a stationary-person stopping model into this context and claim to have achieved unseparated, open-floor human-robot collaboration.

Every quantitative condition attached to a release verdict names the operational limit the permission path enforces, maintaining explicit margin below the calculated physical ceiling. Item handover illustrates this margin requirement. The contract signs a TCP speed below the absolute ceiling that the contact criterion admits under equation 12.13. The gap between these two speeds accounts for unobserved physical evolution between discrete sensor samples: velocity growth between sampling instants, encoder quantization noise, and drive lag during an enforcement clamp. A contract signed at the theoretical ceiling leaves zero margin for these physical latency terms, and the release case requires measured empirical bounds on each term before the signed operational speed can be accepted.

The inspected-floor condition follows the same discipline. Where the site inspection regime certifies a friction coefficient of only 0.12, the illustrative all-weight-on-driven-wheels screen uses the optimistic traction ceiling \(\CoulombFrictionCoefficient \Gravity =\) 0.12 \(\times\) 9.81 m/s² \(=\) 1.18 m/s² against the 2 m/s² that the dry-floor budget assumes. Actual loaded credible deceleration also depends on the driven-wheel load share, drive and geometry conditions, and qualified stopping traces. Under the all-weight screening premise, the partial budget that admits 1.44 m/s on surveyed floors admits only 1.23 m/s under this reduced traction. Visual inspection alone cannot establish this lower friction bound because a thin film of transparent oil readily escapes visual detection. The site must qualify both the friction assessment method and the operating procedures (cleaning schedules, spill isolation, and access restrictions) that preserve the assessed floor state between inspections. If that maintenance regime cannot guarantee the exclusion of contaminants over the authorized operating interval, reducing vehicle speed does not salvage the safety case; the aisle remains refused.

The third verdict, refusal to operate (REFUSE), is mandatory whenever the safety case has missing warrants, uncharacterized tail latencies, incomplete fault-injection coverage, or unmonitored failure modes. For systems where torque removal causes immediate physical harm (such as upright bipedal humanoids falling under gravity), REFUSE cannot simply de-energize motor phases to zero torque; it must execute an assessed, powered descent or seated hold. If the safety enforcer’s worst-case execution time under the designated computational placement has never been verified against its 400 μs deadline, or if the fault-injection campaign omitted common-cause failures identified in the deployment topology, the hazard remains unquantified and cannot support release. Refusal is likewise mandatory whenever physical measurements contradict the mathematical model behind a safety budget term, such as loaded stopping trials that yield decelerations below the 2 m/s² assumed by the braking model.

A refusal verdict is an actionable engineering result rather than an administrative dead end. It redirects schedule pressure toward evidence by pointing to the exact broken link in the assertion DAG. If release is refused because loaded stopping trials contradict the braking model, the engineering team does not debate risk tolerance; instead, developers repeat physical braking trials at maximum payload mass until the qualified trial campaign and its uncertainty analysis support a credible lower deceleration bound, re-derive the stopping budget from that lower bound, and submit for re-adjudication only when the aisle budget closes on validated data. The refusal verdict names the exact empirical test that must pass before re-adjudication can proceed.

Accountability for the release decision must rest with a named lead systems adjudicator rather than being split across development teams. When a vision team signs off on perception metrics, an actuator supplier on torque ratings, and a machine learning team on policy convergence, each group can assume that another layer holds the safety margin. The lead adjudicator alone attests that the integrated, physical machine satisfies the safety case. This sign-off binds the release verdict to a specific set of technical records: cryptographic digests of verified policy weights, calibration logs for manipulator contact-force sensing, empirical brake-onset measurements paired with justified worst-case response bounds, and fully loaded stopping trials establishing credible deceleration limits. The adjudicator signs the release manifest with a private key held inside a hardware security module,⁶ binding the manifest to the organization’s signing key and sign-off record; the robot runtime checks this digital signature against a public key anchored in its hardware root of trust before enabling actuators.

⁶ Hardware Security Module (HSM): A tamper-resistant device can generate and retain a non-exportable private key and perform signing inside its own boundary. The signature identifies the signing key; authenticated access, sign-off records, and key-custody controls establish who authorized its use.

↪ The adjudicator’s signature as one of several decisions behind each admitted action, each needing a named owner, is developed in Decisions Behind an Admitted Action.

The adjudicator’s signature records the internal acceptance of the engineering organization, whereas external certification requires independent evaluation. UL 4600 requires independent assessment of the autonomous safety case (UL Standards & Engagement 2023), and machinery whose primary safety functions rely on machine learning falls under regulations, such as the European Union Machinery Regulation, that require third-party conformity assessment (section 16.3.4). An assessor who did not build the safety case brings an independent view to the assumptions that shaped its trade-offs. Organizational separation alone does not establish a probability of coincident error or the statistical independence required by equation 3. The release manifest must therefore retain the full body of raw physical evidence needed for an independent audit, not just the final verdict.

The adjudicator ultimately signs one of the three decisions summarized in table 4. A conditional verdict requires its own independently evidenced restricted envelope; an unresolved gap in the nominal argument cannot simply be relabeled as an operational constraint. No verdict ever moves the proposal boundary. Under both UNCOND and COND, learned policies only propose candidate actions while the deterministic safety enforcer independently admits or blocks every control command, as principle 3 requires. The release verdict sets the physical envelope that the permission path enforces; it never grants learned policies unchecked authority.

Table 4: Three signed release verdicts for the mobile manipulator: Full operation and restricted mode both retain independent per-action permission. Refusal is an actionable engineering result.

Signed verdict	Evidence required	Permission and runtime limits	Expiry or refusal trigger
UNCOND	Full operating-envelope claim, measured plant and timing bounds, independently validated permission and fallback	Policy proposes across full signed task envelope; every action passes the enforcer	Evidence, configuration, calibration, or standing premise fails
COND	Restricted operating-envelope claim and its own evidence, limits, and fault coverage	Policy proposes only within signed reduced limits; every action passes the enforcer	Any restricted premise becomes false or unknown
REFUSE	Missing, contradictory, expired, or unauthenticated critical evidence	No operating permit; execute the assessed stop or hold, the fallback-ladder rung the release case validates for the plant	Re-adjudication with repaired evidence

Each verdict in table 4 is signed against the physical state of the machine at the moment of evaluation. The right-hand column of the table therefore pairs every operational grant with an explicit expiry or refusal trigger, because a brake lining or sensor mount that passed inspection before commissioning does not stay in its commissioning state. As the physical plant wears and drifts over time, a release verdict holds only while runtime checks, scheduled measurements, and enforced site procedures continue to verify its standing premises.

16.5 The Verdict’s Standing Conditions

A signed release can lapse without any change to the underlying software. Brake linings wear down, camera brackets shift under continuous vibration, or warehouse traffic polishes concrete lanes until traction drops. When these physical premises drift, the stopping claim certified by the adjudicator no longer holds. Standing conditions bind the operational verdict to these physical baselines by defining an explicit observation cadence for each premise alongside deterministic fallback responses when a check fails. Because failure modes originate in hardware and environment, their observation schedules must follow physical degradation mechanisms rather than software sprint schedules. An assurance case maintained this way, its validity updated throughout operating life as monitored evidence shifts, is what the safety literature calls a dynamic safety case (Denney et al. 2015).

16.5.1 Degradation, drift, and observation cadence

None of the three verdicts is a permanent grant. Mechanical linkages develop backlash, friction surfaces wear, optical lenses collect dust, and operating environments change. Operating under either an unconditional (UNCOND) or conditional (COND) verdict therefore carries continuous obligations for the life of the deployment. The aisle notebook (16.1) shows how little wear the stopping claim tolerates. A credible deceleration 31 percent below the assumed 2 m/s² spends the whole partial spare, and a smaller loss spends the reserve that remains once admission work is charged, leaving no allowance for perception latency or traction variation. A lining that wears that far is discovered at a rack end as an overrun unless the degradation first trips a standing condition, such as a scheduled loaded deceleration trial or an automated pre-shift brake diagnostic, before the machine is cleared to enter the aisle. Every operational obligation pairs a physical premise with an automated detector and an immediate mitigation, establishing a standing condition tied to the release verdict.

Sensor mounting drift can silently invalidate localization while every camera frame stays sharp and fresh. Daily thermal cycling and machine vibration alter extrinsic sensor geometry, and software rollback cannot realign a physically displaced bracket. The safety case must therefore require qualified online drift detection or scheduled physical recalibrations, setting inspection intervals from the underlying mechanical wear rates. A cryptographic checksum confirms only that the stored calibration file matches its build artifact; it gives no evidence that the physical camera still sits at that modeled pose.

A release verdict depends on physical premises with widely differing observation schedules. For instance, the mobile manipulator’s optimistic all-weight traction screen requires a floor friction coefficient of at least 0.204; the braking claim additionally requires qualified loaded wheel forces, drive conditions, and stopping traces. Dry concrete exceeds this threshold by a wide margin, at roughly 0.60, but a baseline site survey conducted before commissioning cannot guarantee surface conditions against fluid spills or traffic polishing over time. The safety case must therefore specify routine floor maintenance schedules alongside strict exclusion rules whenever surface contamination occurs, supplemented by any onboard traction monitoring. Similarly, the arm’s contact-force sensors require periodic recalibration against reference loads. Every physical premise must be rechecked continuously or periodically at a cadence matched to how fast it degrades. This is the fourth law, permission must be earned (principle 4), applied over time. The verdict grants permission contingent on operating conditions, and that permission endures only while the evidence supporting each premise remains valid.

Every runtime-monitored premise requires a dedicated detector and a pre-allocated fallback response; conversely, premises governed by facility maintenance require accountable operators and enforceable exclusion rules. If a safety case credits a navigation-camera dispatch age of 51.6 ms, the runtime monitor must measure frame arrival latency against hardware clocks, accounting for sensor readout and transport delays separately. Forwarding an unverified metadata timestamp does not confirm that the frame is fresh. Without hardware-synchronized event timestamps, unverified inputs quietly turn safety premises into ungrounded assumptions. Different premises demand different sampling frequencies. The tote-rack load, bounded by its 50 kg mechanical payload limit, can be checked at each load-changing event if access controls exclude unrecorded loading and the check completes before the changed load receives motion authority. Conversely, base velocity, position tracking, and action lease validity must be evaluated deterministically on every 1 ms safety-enforcer tick.

16.5.2 The envelope trichotomy and epistemic gaps

A naive binary health check assumes normal operation whenever no explicit error flag is asserted, mistaking a dead sensor or a diverged filter for safe clearance. Checking monitored premises at runtime instead exposes three states of envelope membership: known-true, known-false, and unknown. Membership is known-true when authenticated telemetry and hardware-referenced timestamps confirm that the plant’s bounded state-uncertainty set remains strictly inside certified envelope boundaries. Estimator convergence or small covariance matrices alone do not prove containment if model assumptions have broken down. When measured telemetry reveals a physical boundary violation, such as base tracking error exceeding the 40 mm bound reserved within the stopping envelope, the state is known-false. Finally, when an optical encoder loses serial communication, a camera frame fails its cyclic redundancy check (CRC), or an extended Kalman filter diverges, the system enters an epistemic gap. In this unknown state, the controller cannot tell whether the physical machine is safely positioned or breaching clearance margins.

When telemetry supporting active motion becomes unknown or known-false, the safety enforcer revokes trajectory tracking and executes the pre-certified fallback procedure for the plant’s dynamic state. This runtime intervention differs from rejecting an invalid future trajectory proposal, because an already active trajectory chunk can continue executing only while its supporting sensor evidence, physical bounds, and lease duration remain intact. The system’s flight recorder must log whether revocation stemmed from unobservable state telemetry or an active boundary breach, while the hardware supplies enough reserve energy and sensing capability to bring the plant to a controlled stop or hold.

Definition 16.3: Envelope trichotomy

Envelope trichotomy is the three-state epistemic classification of cyber-physical system health relative to its signed operating envelope: known-true (qualified state-uncertainty set contained inside the supported envelope), known-false (verified boundary violation triggering deterministic hardware refusal), and unknown (state uncertainty caused by sensor dropout, frame corruption, or estimator divergence).

1. Significance: An unknown state is not evidence of a boundary breach, yet neither condition permits continued tracking. The permission decision is refusal in both unknown and known-false states; the logged cause remains distinct and the response depends on the plant’s validated stop or hold capability.
2. Distinction: Unlike a binary boolean status check (is_safe == true), the envelope trichotomy separates sensor blindness from active violations, ensuring telemetry loss is never mistaken for safe clearance.
3. Common pitfall: Treating a stored command as indefinitely valid after communication fails. An active chunk may continue only within its own still-valid evidence and lease; otherwise the assessed fallback must take over.

The same three-state distinction applies to verification test records. A test trial marked UNOBSERVABLE or INVALID during acceptance testing (Four verdicts and the invalid-test rule) cannot establish the claim its required witnesses or test conditions failed to resolve. It leaves a gap in that coverage; other valid records remain evidence only for the conditions and claims they establish. Verified PASS records support the claims covered by their conditions and witnesses. A valid FAIL contradicts the claim tested under those conditions and withdraws any authorization that relies on it.

16.5.3 Blind travel, kinetic consequences, and cycle limits

When telemetry fails or sensors black out, a machine traveling without sensory feedback moves blind; it must execute a deterministic fallback stop before its forward travel consumes the remaining spatial clearance. How fast that clearance vanishes depends directly on vehicle speed, contact geometry, and available actuator authority. Sizing the response therefore requires calculating the kinetic energy and blind travel accumulated during each millisecond of delay, and matching each sensor loss to a pre-certified fallback path.

How the system responds when a premise cannot be checked must follow from the physics of unmonitored motion rather than from arbitrary severity categories. When the mobile manipulator traverses an aisle at 1.3 m/s with its tote rack fully loaded, its 368 kg mass carries 311 J of kinetic energy. If its primary lidar stops updating, every millisecond of blind travel carries the base 1.3 mm closer to potential obstacles. The safety case pre-certifies three possible fallback paths, two of which apply only when the signed release names them in advance. The first is a degraded mode that permits continued motion while diverse redundant sensors keep state uncertainty bounded, for example throttling the aisle speed to 0.65 m/s (half the aisle speed, a chosen value) while secondary sensors watch the path. The second is a switch to a restricted limit set that a signed COND case pre-validated for that exact sensor loss, if the release includes one; the runtime only selects that profile, it does not create a new verdict. Dead reckoning and wheel odometry may retain qualified position bounds over a brief window, but cannot verify obstacle clearance on their own. The third option, the hardware STOP response, handles complete loss of observability by executing a configured drive and brake sequence. Stopping the vehicle within available clearance margins requires calibrated response timing, sufficient drive traction, and known brake deceleration.

Action leases bound how long an admitted trajectory chunk may run without renewal. Checking this lease on every controller tick does not require re-measuring every long-term site condition. Instead, the runtime permission path checks fresh local sensor telemetry alongside the signed validity windows of slower site inspections and maintenance records. If the proposer stalls or its communication drops, task throughput suffers, but safety holds as long as the enforcer and its fallback path remain decoupled, responsive, and intact.

Any standing condition governing physical motion requires an enforcement path with a measured detection and response budget. In this book’s architecture, an independent safety enforcer checks trajectory proposals and monitored premises before issuing actuator permissions, re-evaluating system state on every 1 ms control tick. A subsystem failure reaches this enforcer along one of two paths: a silent proposer that stops transmitting is caught only when its existing action lease expires, whereas an actively monitored hardware fault raises an immediate interrupt flag. Because detection delays differ between these paths, so does the distance the base travels blind (notebook 16.2).

The lease dominates: a silent proposer reaches brake onset in 82 ms, a flagged premise in 22 ms.

Napkin Math 16.2: The silent-proposer window

Problem: The base runs the aisle at 1.3 m/s. How far does it travel before brake onset when the proposer falls silent, how far when a monitored premise fails and its flag reaches the enforcer at once, and how late may that flag arrive before monitoring stops the base no sooner than the lease would?

Variables:

• Aisle speed \(\SpeedAtDetection =\) 1.3 m/s (Chosen), so 1.3 mm of travel per millisecond
• Chunk lease 60 ms and permission tick 1 ms (Chosen); bus transfer 1 ms and brake onset 20 ms (Illustrative)
• Flag latency \(\FailureFlagLatency\) from the physical failure to a flag the enforcer can read (Unknown; the detector’s qualification must bound it)

Math:

1. Silent proposer: 60 ms \(+\) 1 ms \(+\) 1 ms \(+\) 20 ms \(=\) 82 ms, and 1.3 m/s \(\times\) 82 ms \(=\) 106.6 mm.
2. Monitored premise, immediate flag: 1 ms \(+\) 1 ms \(+\) 20 ms \(=\) 22 ms, and 1.3 m/s \(\times\) 22 ms \(=\) 28.6 mm.
3. Crossover: \(\FailureFlagLatency +\) 22 ms \(=\) 82 ms at \(\FailureFlagLatency =\) 60 ms, the length of the lease itself.

Result: Monitoring can save up to 78 mm of travel, but only for a flag that arrives within 60 ms of the failure; a slower flag stops the base no sooner than waiting out the lease.

Systems insight: The 22 ms local subtotal is not a complete detection-to-stop time; it reflects only controller cycle delay, communication transfer, and physical brake engagement. The decisive term governing whether an active monitor preserves physical clearance is \(\FailureFlagLatency\), the hardware detection latency. If an architectural budget fails to bound \(\FailureFlagLatency\), the safety case cannot claim proactive protection. Every millisecond spent detecting a fault carries the loaded vehicle another 1.3 mm toward whatever the failed premise was protecting against.

When an operating premise transitions to unknown or known-false, the enforcer revokes trajectory tracking and commands the appropriate rung of the fallback ladder, and the signed safety case must specify both this fallback selection and its measured timing. For the mobile base, the certified stopping sequence uses controlled, powered deceleration to bring the wheels to rest before applying electromechanical holding brakes. Because digital controller logic and brake-coil hold-up capacitors cannot deliver drive motor torque, the safety case must confirm drive energy, feedback sensing, and inverter continuity across every fault condition expected to use this active deceleration profile. By contrast, a raw torque-inhibit or free-wheeling cutoff is a fundamentally different physical response; it cannot inherit stopping-distance guarantees calculated for controlled electrical braking.

Entering an unknown or known-false state also triggers local black-box logging. The onboard recorder must preserve the telemetry window leading up to refusal alongside the execution of the fallback trajectory, even if the initiating fault cuts external networking or primary bus power. These records are essential for root-cause investigation, but writing them to nonvolatile storage must never delay the hard real-time safety stop; section 16.9.5 sizes the capture path.

On longer timescales, even when every runtime heartbeat succeeds, the release verdict carries an operational cycle and inspection budget.⁷ Operating hours and mechanical fatigue wear components in ways that high-frequency telemetry cannot observe directly (such as surface pitting on gear teeth, elastomer seal stiffening, or fastener preload relaxation). Once this cycle budget expires, the release case must be re-adjudicated before autonomous motion can resume. Across every timescale, a deployment verdict remains valid only while its supporting standing conditions remain demonstrably known-true, checked at intervals matched to physical wear rates and backed by pre-certified fallback stops with measured latencies. With claims, verdicts, and revocation conditions defined, the six claims of the warehouse mobile manipulator can now be adjudicated against the physical evidence assembled across this book.

⁷ Mechanical Fatigue Budget: A cumulative-damage model such as Miner’s rule (\(\sum_i \AppliedLoadCycleCount_i/\FatigueLifeCycleCount_i\)) (Miner 1945) can organize a measured load spectrum against component-specific fatigue data; it is an approximation, not a universal failure deadline. The assessed loads, uncertainty, inspection evidence, and stopping consequences determine any signed payload derating and cycle limit. An expired limit revokes the applicable release case rather than silently extending service.

Miner, Milton A. 1945. “Cumulative Damage in Fatigue.” Journal of Applied Mechanics 12 (3): A159–64. https://doi.org/10.1115/1.4009458.

16.6 Adjudicating the Safety Case

An algebraically exact stopping equation or contact-force bound still fails to protect a machine if the physical premise beneath its warrant has never been measured on hardware. Adjudicating a safety release case requires checking each warrant against the qualified measurements, justified analysis, or validated operating restrictions that support it. For the warehouse mobile manipulator, the adjudicator takes each of the six claims of table 2 in turn, names the physical premise under its warrant, and grades the evidence behind that premise, isolating the exact boundary where mathematical deduction ends and physical measurement must take over.

The door-opening branch of C1 shows the procedure in full. The contact enforcement record supplies the branch’s underlying mechanics (Intentional contact and in-contact energy barriers). At the guarded approach velocity of 0.03 m/s, equation 12.11 yields an impact force at physical braking onset of 39 N, well below the 100 N latch limit. From there, equation 12.12 leaves the latch plate with only 0.15 mm of additional allowable compression. Bringing the arm to rest within this narrow mechanical travel requires a deceleration of approximately 3 m/s² over a brief 10 ms stopping window. By contrast, at the unconstrained approach velocity of 0.10 m/s, the force at braking onset rises to 95 N, and avoiding structural damage demands a deceleration of 400 m/s², more than an order of magnitude above standard gravity. While this kinematic calculation specifies the stopping performance required for release, mathematical derivation alone cannot prove that the physical arm actuators can deliver it. Consequently, the operating envelope (table 1) excludes the high-speed approach. Raising approach speeds sharply escalates contact braking demands, whereas the system’s training demonstrations offer zero empirical evidence for safe high-speed contact (Choosing a tractable coverage table).

Raising the approach from 0.03 m/s to 0.10 m/s multiplies the arm stop needed 136-fold.

Neither result is in doubt as arithmetic; the algebraic deduction is exact. Formal engineering release, however, cannot rest on closed-form kinematic models alone. The door branch fails authorization because its safety warrant depends on an unverified physical premise. Whether the physical manipulator, carrying its link momentum, payload mass, and reflected rotor inertia, can actually deliver 3 m/s² of deceleration within a fraction of a millimeter depends on transient joint torque limits, motor electrical time constants, and structural stiffness. Without calibrated hardware traces measuring these dynamic properties under load, this mechanical premise remains unknown, and the adjudicator must refuse the claim.

The remaining claim branches fail on similar grounds:

• Base braking corridor (C1): The base stopping budget of 969.0 mm omits dispatch-to-admission delay and rests on illustrative values for braking deceleration, brake onset, path-tracking error, and localization uncertainty. Its remaining margin of 131.0 mm can be exhausted by the illustrative deceleration shortfall in step 4 of notebook 16.1, and step 5 leaves still less once admission work is charged.
• Object handover (C1): The mug handover branch fails on three separate premises. First, the calculated contact force falls below the criterion only for an unconstrained, free-moving hand, and it comes from a standardized biomechanical body model rather than a force measurement of this contact. Second, the evidence packet does not show that the coworker’s hand cannot be trapped against a rigid fixture, so the non-clamping geometry is unproven. Third, perceptual grounding remains unverified: a proposal that mistakes a clear glass jar for the target mug satisfies every geometric affordance check, and no trace in the runtime logs disambiguates the object.
• Enforcer timing (C2): The timing warrant for the runtime safety enforcer assumes a worst-case execution time (WCET) of 250 μs against an unloaded baseline of 135 μs and a 400 μs deadline. The WCET is declared without architectural analysis and loaded stress evidence supporting it under peak memory bus saturation.
• Traction and environmental state (C3): Claim C3 requires a qualified friction floor across every authorized aisle; 0.204 is only the optimistic all-weight traction screen, not a sufficient loaded stopping qualification. A clean concrete floor can be validated through baseline skid testing, but the onboard cameras cannot reliably distinguish dry concrete from a thin film of transparent oil, and no sensor on the machine can exclude liquid contamination ahead of the braking contact.
• Perception pipeline latency (C4): The 51.6 ms dispatch age combines nominal datasheet readout times with uncharacterized pipeline delays rather than verified end-to-end telemetry.
• Permission independence (C5): The placement record’s loaded test report, which would show the enforcer’s maxima under the proposer’s worst interference and test the common causes of Two Paths and the Resources They Share, is described in this book but not produced. Without it, the credited enforcement isolation is unsubstantiated; even supporting isolation records would not by themselves establish statistical independence of every failure event.
• Authority transfer (C6): The argument cites PASS fault records for authority transitions A1 through A4, and no such records exist yet. Local operation could drop the remote-channel cases, but not the local ones.

Because every claim rests on at least one unverified physical premise, the adjudicator must render a verdict of REFUSE. This refusal does not imply that the robot is inherently dangerous. The book’s supporting inputs are illustrative models rather than empirical validation logs, so the verdict is illustrative as well; it models how release is adjudicated and shows why ungrounded claims cannot license physical deployment. The fourth law, permission must be earned, requires an operational restriction wherever the available evidence cannot support a premise. Here, every branch contains an unverified premise. A principled refusal must therefore specify the exact measurements required to turn an unverified assumption into an accepted warrant. Table 5 lists these evidentiary requirements, naming the physical premise each measurement settles and the operational restriction a supporting result would lift.

↩︎ The four bedrock laws, the fourth of which holds that permission must be earned, are established in The Four Bedrock Laws.

Table 5: Measurements that would move the verdict toward COND: Each row names the premise a measurement settles on the warehouse mobile manipulator and the restriction a supporting result would lift; the inference trace bears on service availability only.

Measurement	Premise it settles (value in this book)	Claims	What a supporting result lifts
Stopping trials at the loaded mass	Low-tail credible deceleration (2 m/s²)	C1	The base’s budget and its 1.44 m/s ceiling, so an aisle speed can be signed
Brake-onset trials	Brake onset (20 ms)	C1, C2	The 82 ms bound from the last valid renewal to brake onset
End-to-end age trace	Dispatch age (51.6 ms) and subsequent evidence aging	C4	The age term of the budget and the stale-data threshold
Tracking-error and localization tails	Tracking bound (40 mm) and localization bound (50 mm)	C1	The inset and overhead terms of the budget
Site survey	Rack-end clear distance (1.10 m)	C1	A signed speed at each surveyed rack end
Floor survey	Dry-floor friction (0.60) against the 0.204 needed	C3	Assessed route only, with maintained contamination exclusion and loaded stops at the qualified friction floor; reduced speed alone cannot exclude oil
Inference trace	Chunk inference at the 99th percentile (40 ms)	None	Service availability: characterize renewal within the 60 ms lease; a percentile does not guarantee each renewal, and C2 depends on independent fallback
Loaded enforcer timing	Enforcer WCET (250 μs, declared)	C2, C5	The 400 μs deadline under the placement’s worst load
Arm stopping trials	Arm deceleration from the guarded approach (about 3 m/s² needed)	C1	Door opening at the guarded approach
Handover force trials	Peak contact force at the handover speed (20.7 N derived for a free hand) and absence of clamping geometry	C1	Handing the mug to the coworker at 0.10 m/s under accept_item
Operator trials	Takeover and authority-handover timing	C6	Remote takeover, once A1–A4 each have a PASS record; otherwise local operation only

Neural network inference latency primarily governs system availability rather than baseline safety. An inference overrun will not violate physical containment so long as the independent hardware safety path and powered fallback controllers remain operational; however, repeated deadline misses will degrade throughput and stall task progress. Conversely, resource contention across shared memory, PCIe buses, or CPU caches that delays the runtime enforcer or starves its sensor feeds represents a direct safety failure under claims C2 and C5. Finally, while local autonomous operation can safely omit validation trials for unused remote teleoperation links, deployment still requires verified software placement records, comprehensive common-cause fault coverage, and passing test records for every local authority transition.

16.6.1 Worked restricted service with stipulated evidence

Without calibrated hardware measurements, the mobile manipulator remains locked out under a REFUSE verdict. To see how an engineering organization moves from initial refusal to conditional deployment without relaxing its structural safety limits, consider a stipulated release case in which an engineering packet supplies the measured traces specified below. (The uncalibrated evidence currently available in this book continues to dictate REFUSE.)

The target application is restricted inspected-route mug delivery: the robot retrieves a declared mug from a singulated feeder, traverses a designated, surveyed warehouse aisle at a velocity capped at 1 m/s, pauses the mobile base to open an equipment cage latch using the guarded contact trajectory, and hands the mug to a consenting human coworker under the accept_item primitive at 0.10 m/s. Operational authority remains strictly local. The feeder mechanism physically prevents accidental object substitutions, recognizing that singulation alone cannot authenticate identity. Similarly, strict access controls prevent personnel from stepping into the robot’s active stopping corridor during transit.

↪ The difference between a coworker who consents to a machine’s risk, as this one does, and people who bear it without choosing, is developed in Who Bears the Risk.

For claim C1, the safety case stipulates empirical stopping traces under full payload mass, measured tracking and localization variance, dynamic latch-stopping performance, and instrumented handover contact forces that satisfy the bounded thresholds in table 5. For claims C2 and C5, the case stipulates independent hardware fault-injection logs and worst-case execution timing traces gathered under peak synthetic computational load. These records must account for common-cause hardware failures, support the enforcer’s permission deadlines and actuator reaction latencies, separate controlled motor deceleration from passive mechanical braking at rest, and confirm isolated drive-energy cutoff and sensor integrity under all credited fault modes.

For claim C4, the case stipulates synchronized end-to-end hardware timestamp telemetry, bounded clock skew, and a verified upper bound on dispatch-to-admission latency. This latency must be deducted from the dynamic stopping distance budget so that a strictly positive safety margin remains; a theoretical kinematic velocity ceiling cannot authorize transit speeds on its own. Because sensor data ages continuously throughout execution, the chunk lease starts only when a plan is admitted, never when it is computed. The qualification packet must also check the time between admitted plans against the lease renewal deadline rather than assuming that nominal policy inference frequency guarantees admission. For claim C6, the packet stipulates verified PASS audit records across every state transition exercised by the local autonomous executive, while disabling the unverified remote teleoperation interface entirely.

Claim C3 requires substantially more than visual inspection or reduced transit velocity. The case stipulates a qualified site friction survey showing a friction coefficient of at least 0.12 across the surveyed transit corridor, reinforced by active cleaning protocols, chemical containment barriers, and physical access gates that maintain floor integrity throughout the authorized inspection interval. Stopping trials at maximum payload must confirm deceleration on this specific friction surface with the loaded wheel distribution and drive settings of the signed configuration. The complete restricted stopping distance, including the verified dispatch-to-admission delay bound and a positive safety margin, must fit inside the surveyed physical clearance with a positive reserve, the same accounting as step 5 of notebook 16.1. The operating velocity of 1 m/s sits below the partial ceiling of 1.23 m/s, but that comparison is only an initial feasibility filter. The active transit permit is revoked immediately upon any reported spill, expired maintenance inspection, or perimeter breach. If unmonitored oil or other fluid can enter the corridor during the deployment window, the stipulation is invalidated and the verdict reverts to REFUSE. A lower speed cannot repair that premise, because the restricted speed was sized for the inspected friction floor of 0.12, not for a film near 0.05 that removes most of it.

The task capability packet is similarly stipulated. Before evaluation begins, the facility operator defines binding acceptance criteria in the verification plan: a minimum mission completion rate, an upper bound on end-to-end cycle time, and a maximum allowable operator intervention rate, accompanied by sample-size requirements, confidence intervals, and statistical decision rules. A successful mission requires maintaining object identity and physical integrity from retrieval through coworker handover. Cycle time accounting includes transient safety stops, crossing delays, and autonomous replanning; human rescues and aborted deliveries are tracked as explicit mission failures. The safety case stipulates that closed-loop trials of this exact restricted configuration satisfy all three benchmarks. The qualification dossier separates raw neural policy autonomy, system-level task success, and safety interventions into independent metrics, the separation What a Physical Success Rate Measures drew between the policy’s own completions and the completions that protection made possible. Minimal-intervention safety filtering may run during nominal task execution; its clamps are counted separately, so they neither mask the policy’s shortcomings nor count as safety violations.

With these stipulated evidence packets in hand, the adjudicator can sign a verdict of COND (conditional release) for restricted inspected-route mug delivery. The physical records support claims C1 through C6 solely within the restricted operating envelope, while the task evaluation shows acceptable operational utility under identical constraints. The adjudicator binds both the physical safety dossier and the capability evaluation to the release manifest, leaving full-speed autonomous transit and remote teleoperation unauthorized. The result is a conditional safety case, not a blanket deployment permit. Invalidating any underlying assumption or breaching a boundary condition immediately returns the verdict to REFUSE; conversely, gathering qualified operational telemetry and physical measurements over time can justify expanding the envelope toward full-scale release.

Checkpoint 16.2: Refusal and the path to conditional release

Before approving a conditional release of the machine, verify your understanding of how a premise, rather than a calculation, decides a claim:

• Premise vs. arithmetic: Can you explain why the calculated latch force at physical braking onset is not in doubt while the door branch of C1 is still refused?
• Unsupported approach: Can you use equation 12.11 and equation 12.12 to show why the operating envelope admits only the guarded door approach?
• Refusal as a deliverable: Can you name, for one refused claim, the measurement that would lift it and the restriction that would remain after a supporting result?
• Measured-deceleration estimate: Suppose loaded stopping trials put the low tail of the deceleration at 1.6 m/s² under the same jerk bound. Can you rerun notebook 16.1 at 1.3 m/s and decide whether that aisle speed can still be signed once \(\DispatchAdmissionInterval\) is charged?

16.7 Adversarial Review

Confirmation bias steers an engineering team’s data collection toward nominal conditions where learned models succeed, leaving edge-case hazards untested until live operation exposes them. Suppose the measurements listed in table 5 arrive and, as in the stipulated branch, appear to support a conditional (COND) authorization for the mobile manipulator. Before signing, the safety adjudicator submits the safety case to an independent adversarial review tasked with falsifying its warrants. Rather than ratifying a brief, the reviewer actively searches for unsupported warrants, uncharacterized physical transitions, and environmental edge cases that violate the release contract. If an argument collapses on paper when an adversary probes for physical violations, the machine cannot be expected to withstand the hazards of live service.

The review interrogates every evidentiary node in the argument tree using four structured probes. The first challenges empirical sufficiency: whether the physical trials reached the extremes of the operating envelope. Stopping trials with the loaded base on dry concrete, at a friction coefficient near 0.60, support the warrant that the base achieves its certified deceleration under ideal conditions. The restricted operational mode, however, admits facility floors that the site’s inspection regime certifies only down to 0.12, such as an aisle polished smooth by traffic. In those zones, the base may run at the restricted velocity 1 m/s, below the 1.23 m/s ceiling. If the trial set contains no loaded stops on such degraded floors at that speed, the warrant for the restricted mode is unsupported. A coverage audit finds on paper the gap that unvetted service would otherwise find against a warehouse rack. The reviewer also checks whether validation trials covered transient execution states across an A/B partition swap, when a newly flashed software bank takes over from the incumbent one (section 16.9.1); cold-start sensor characteristics before cameras and inertial measurement units reach thermal equilibrium; and the operating boundaries of canary units, the small subset of the fleet that first runs a candidate policy (section 16.9.2). Finally, the reviewer asks whether site procedures actually keep fluid films out of the corridor throughout the authorized interval, since listing oil outside the envelope does not exclude it from the floor.

The second probe examines domain transfer, targeting claims where synthetic simulation substitutes for direct physical measurement. A vision-based human detector may achieve high recall across synthetic, ray-traced warehouse environments, yet fail on physical hardware when encountering coworkers partially obscured by stretch-wrapped pallets whose specular reflections blind the camera’s auto-exposure algorithm. Benchmark recall on curated offline datasets is an indirect proxy metric that scores isolated frames rather than the closed-loop physical causal chain running from visual detection to an arrested base. Likewise, a simulation that omits linkage compliance or fieldbus jitter cannot establish tolerance to those physical mechanisms. The reviewer demands empirical evidence from paired hardware-in-the-loop (HIL) trials on target SoC devices connected to chassis dynamometers⁸ and physical bus emulators under real facility illumination, dust, and reflective geometry.

⁸ Chassis Dynamometer: Powered rollers under the drive wheels absorb or supply torque, so the base can run at aisle speed on a bench while its drive and braking torques are measured. The rollers, not the floor, set the traction. Dynamometer stops can therefore qualify drive and brake response but say nothing about the friction premise of C3.

The third probe attacks structural independence, asking whether the learned model and safety enforcer share hardware resources whose contention could delay sensor delivery or actuation cutoff. On modern robotics edge platforms where neural inference engines and real-time safety enforcers share a single system-on-chip die, internal crossbar interconnects, shared caches, and DRAM memory controllers, unconstrained direct memory access (DMA) transfers from large model forward passes can saturate memory channels. This memory contention induces tail latency spikes that starve deterministic safety enforcer execution ticks, directly invalidating the 51.6 ms observation-age chain of C4. Stress tests and hardware timing analysis under peak synthetic compute and bus loads must establish the worst-case interference bound; unit tests on an otherwise idle bus provide zero evidence of non-interference. The reviewer also checks whether writing frozen edge telemetry ring buffers to non-volatile storage competes with real-time fieldbus DMA buffers across the internal bus fabric, inspects watchdog reset circuits for single points of failure, and verifies whether the supercapacitor power hold-up circuit supplies enough energy to flush in-flight telemetry buffers to persistent flash when an emergency stop opens the main DC bus contactors.

The fourth probe identifies unmonitored state drift. Mechanical wear alters gearbox compliance⁹ and disrupts the dynamic relationship between commanded motor torque and physical joint motion. The reviewer therefore demands paired wear-state braking and contact traces before accepting the arm-stop premise of the door branch of C1 (section 16.6). A static motor-current threshold alone cannot prove that a mechanically worn drive train remains inside certified force and stopping limits. The reviewer also checks whether over-the-air updates preserve the persistent hardware calibration partition intact across schema migrations, or whether an OS reflash can silently reset camera extrinsics and joint zeroes to unverified factory defaults. Finally, the probe checks whether thermal bracket motion stays inside the localization allowance; fresh timestamps and unchanged calibration files on disk cannot establish that physical fact.

⁹ Strain-Wave Gear Wear: The arm’s joints use strain-wave reducers (Transmission compliance, contact impedance, and tooth fracture), and in service their flexspline teeth and wave-generator bearing wear. Wear raises lost motion and torsional hysteresis, which adds phase lag between motor and link, so the arm begins to decelerate later and its first contact peak rises.

Reviewers turn these vulnerabilities into concrete tests by constructing explicit defeaters for each warrant. The hardest failure modes to catch combine minor anomalies that each stay inside their own tolerance bands, the compound faults that Compound faults and coupled disturbances derives from shared causes. Consider the mobile manipulator’s navigation camera operating with three simultaneous sub-threshold degradations: a light film of dust coating its lens, a mount whose fasteners relaxed within tolerance so that it vibrates as the base crosses floor joints, and an interconnect harness whose flexing at those joints elevates the bit-error rate across its serializer/deserializer (SerDes) link. Each individual check reads normal: the optical transmission score exceeds its 85 percent alarm threshold, the mount deflection registers below its 0.15-degree hardware fault limit, and SerDes cyclic redundancy check error counters remain below their warning tripwire. Their timing effects remain contained only if the independent permission path strictly enforces the event-specific observation-age and clock-uncertainty checks of The Observation Contract and retains its validated response time. Any hardware or bus interference that defeats that deterministic path is a safety violation under C5, not a benign availability-only event.

The same anomalies compound within spatial estimation. Dimmed contrast reduces tracked visual features, mount vibration adds motion blur and persistent pose bias, and frame drops extend intervals of uncorrected dead reckoning. A systematic pose bias can quietly erode the localization allowance without forcing estimated filter covariances or innovation residuals to breach trip thresholds. The release reviewer therefore challenges the combined error against the qualified uncertainty bound, rather than inferring containment from individually passing scalar diagnostics. A breach of the combined bound consumes part of the stopping reserve and invalidates the release warrant; exhausting the entire stopping margin requires a quantified combined-error scenario. Statistical residual monitoring protects against only the specific faults its qualification shows it can detect, leaving site operational restrictions or independent physical checks to cover the remaining biases.

The review also audits the execution integrity of the permission path, checking whether inference loops or background services can bypass, corrupt, or starve the enforcer or human overrides, the latter covered by claim C6 of table 2. Below the proposal boundary, both safety monitors and manual overrides maintain non-preemptible execution priority over learned models. The reviewer asks concrete systems questions: whether a runaway policy thread can exhaust shared memory channels, whether an accelerator-runtime exception can lock a kernel spinlock, and whether a telemetry logging burst can brown out a regulated power rail. The reviewer accepts permission path independence, and the held-up power rail that carries it on the mobile manipulator, only after reviewing physical fault-injection trials. These trials must show survival under bus saturation, active feed removal, and an abruptly killed proposer task (fault F1), and they must appear in the signed fault records, because C2 claims only the faults the permission path demonstrably survives. A user-space implementation without qualified scheduling, resource isolation, and response mechanisms cannot supply the justified execution bound and fault isolation the reviewer requires.

When an adversarial probe succeeds, the case cannot be salvaged by editing claim descriptions or inserting arbitrary safety margins. The broken warrant is traced to its root systems failure (an uncharacterized physical boundary, an inadequate dataset, or an unmodeled bus latency), and the defect returns to the owning engineering subsystem. For example, a motor-current observer that fails under gearbox compliance returns to the mechanical specification as wear limits and runtime compliance estimation, while bus contention that delays the enforcer returns to the compute architecture as memory partitioning and real-time scheduling. The case returns to the engineering team with its broken warrants named, and only updated boundaries, re-derived stopping distances, and renewed verification reopen formal adjudication.

Adversarial review must also recur periodically, because a case accepted once can erode in service without any single discrete event forcing a new audit. The normalization of deviance names that operational erosion, in which anomalies that cause no immediate harm come to be treated as acceptable operating noise rather than as evidence against a warrant (Leveson 2011; Vaughan 1996) (war story 16.1).¹⁰ On the mobile manipulator, this erosion unfolds silently across months of fleet operation: localization residuals creep toward the edge of their tolerance, observation-age watchdog trips are dismissed as nuisance stops, stopping distances end slightly longer than the initial trials did, and enforcer trips are cleared on the floor without a trace review. When thresholds are widened, margins trimmed for throughput, and alarms suppressed because nothing has yet gone wrong, the gap between the signed envelope and the machine’s actual physical behavior widens until a routine disturbance exhausts what remains. The defense is to fix each watched quantity’s threshold and response before service begins, as the safety performance indicators of section 16.9.5 do, so that a run of harmless readings cannot move it.

Leveson, Nancy. 2011. Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press.

¹⁰ Normalization of Deviance: The sociologist Diane Vaughan coined the term in her study of the Challenger launch decision (Vaughan 1996). It names a process rather than a decision, in which each anomaly that caused no harm widened what the next review accepted as normal.

Vaughan, Diane. 1996. The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press.

War Story 16.1: Challenger and experience limits (1986)

Context: The Space Shuttle’s solid rocket motors were assembled from cylindrical steel segments whose field joints were sealed by primary and secondary O-rings (Presidential Commission on the Space Shuttle Challenger Accident 1986). No learned model appears in this chain. The adjudication failure it records is the exact failure this chapter’s verdicts exist to prevent: a launch approved for conditions that the evidence did not cover.

Mechanism: The ambient temperature at launch was \(36^\circ\text{F}\), 15 degrees colder than any previous launch. O-ring resiliency falls with temperature, and a cold ring returns to shape too slowly to follow the joint gap as ignition pressure opens it. On the eve of launch, engineers at Morton Thiokol, the motor’s contractor, recommended against launching below \(53^\circ\text{F}\), the O-ring temperature of the coldest previous flight, whose joints had shown the worst blow-by to date. That limit was the outer edge of flight experience, not a qualified bound. NASA managers countered with a qualification temperature that applied to the propellant’s bulk temperature rather than to the joint seals.

Impact: A combustion gas leak through the right booster’s aft field joint, beginning at or shortly after ignition, weakened or penetrated the External Tank. The vehicle broke up about 73 seconds after launch, and all seven crew members died.

Response: The presidential Commission attributed the failure to “a faulty design unacceptably sensitive to a number of factors,” and temperature heads its list of those factors. It recommended that the joint be changed and that the new design be certified by tests “over the full range of operating conditions, including temperature.”

Systems lesson: Thiokol management reversed its engineers’ recommendation at the urging of NASA’s Marshall Space Flight Center. Thiokol’s vice president of engineering testified, “We had to prove to them that we weren’t ready.” The burden of proof had inverted: rather than requiring proof that the joint was safe inside its evidence, adjudicators demanded proof that it was unsafe outside the evidence, where no data existed. The Commission also found that O-ring erosion had recurred on earlier flights and that NASA and Thiokol “accepted escalating risk apparently because they ‘got away with it last time’” (Presidential Commission on the Space Shuttle Challenger Accident 1986), so the flight record itself had been read as evidence of safety. A release verdict keeps the burden where the envelope trichotomy puts it. A condition outside the evidence, such as a seal temperature below all flight experience, is unknown, and the verdict refuses it.

The Tempe collision analyzed in When the Responsibilities Fail Together rested on an unmeasured premise of the same kind as Challenger’s seal temperature. Its vehicle operator was the countermeasure the whole system leaned on, so the premise was that the operator was watching, and nothing measured whether that held. A release case that relies on such a premise must bind its operational response, whether an outright refusal or a restricted case, to verified physical limits, as claim C6 does for authority transfer. Even a case that survives this adversarial review has had its warrants tested only in principle while its verdict still lives on paper. The release manifest turns the surviving argument and the verdict it supports into a signed, tamper-evident record that the machine itself checks before it moves.

↩︎ The operator-monitoring failures that a human-takeover premise invites, from mode confusion to authority ambiguity, are established in Authority Handover Failure Modes.

16.8 The Release Manifest

A safety case that lives only in static documents or procedural sign-off sheets cannot stop a robot from booting with an unverified policy checkpoint or stale sensor calibrations. To make the verdict enforceable on hardware, the adjudicator’s decision is recorded in the release manifest, the fourteenth record in the book’s record chain. This signed, tamper-evident data structure binds every upstream engineering contract, the Goal Structuring Notation argument graph, the operating envelope limits, and live standing conditions to the adjudicator’s verdict by cryptographic digest. The target platform refuses physical motion whenever runtime binary images, silicon attestation measurements, or underlying qualification data diverge from these signed digests.¹¹

¹¹ Cryptographic Manifest and Silicon Attestation: One-time programmable electronic fuses (OTP/eFuse) store the adjudicator’s public verification key in silicon, preventing unauthorized software updates from replacing the root of trust. Secure bootstrap validates each early boot stage before handing over execution control (Arbaugh et al. 1997), while measured boot extends cryptographic measurements into Trusted Platform Module Platform Configuration Registers (TPM PCRs). The hardware verifier checks these measurements against the digests specified in the signed manifest; any unsigned or modified binary image fails attestation and never receives an operational permit.

Arbaugh, William A., David J. Farber, and Jonathan M. Smith. 1997. “A Secure and Reliable Bootstrap Architecture.” Proceedings of the 1997 IEEE Symposium on Security and Privacy, 65–71. https://doi.org/10.1109/SECPRI.1997.601317.

↪ The residual-claims register, the record that follows the release manifest and ties each premise it leaves open to an operational restriction, is developed in A residual-claims register.

The release manifest gathers the engineering contracts established throughout this book. Each upstream record defines an operating boundary or contributes empirical data that the safety case must check; a signature on an isolated contract does not validate the system as a whole. Instead, the manifest links reviewed snapshots of these records into a single argument graph:

1. Physical plant and timing base: The limit record (The six elements of a limit record) documents torque, velocity, and thermal dissipation bounds alongside their qualification data; the proposer’s payload requirements (Information the proposer must supply) specify candidate action horizons that feed the handoff record rather than standing as an isolated contract; and the handoff record (The Handoffs Matrix) establishes deterministic fieldbus jitter, cycle deadlines, and real-time communication premises.
2. Data, policy, and behavioral bounds: The provenance record (The Dataset Schema) captures dataset calibrations, sensor configurations, and operating-domain coverage; the policy manifest (The Policy Manifest) binds frozen neural network weights to the empirical behavioral bounds proven for that candidate model; and the evaluation record (The Evaluation Record) details closed-loop task success rates, human intervention tallies, and stress-tested operational conditions.
3. Perception, belief, and planning: The observation contract (The Observation Contract) enforces observation freshness and multi-sensor synchronization windows; the belief record (The Spatial Memory Handoff and State Invariants) specifies geometric state estimates, state covariance, and validity domains; the intent lease (The Intent Handoff and Bounded Authority) records task objectives, spatial tolerances, and preemption conditions; and the trajectory record (The Trajectory Record) encodes motion profiles, kinematic seam continuity, execution deadlines, and safe stopping continuations.
4. Deterministic containment, execution, and verification: The enforcement record (The admitted command schema) logs the command stream admitted by runtime safety filters, cleanly separated from the signed enforcement contract that specifies barrier functions and fallback triggers; the placement record (The Placement Record) documents the qualified compute scheduling, memory isolation, and processor affinity; the authority record (The Authority Record) documents arbitration switches and fallback outcomes; and the fault records (Fault Records for Release) index tested fault-injection scenarios alongside known coverage gaps.

Beyond linking these upstream contracts, the release manifest adds its own fields: the root claim, the cryptographic digest of the Goal Structuring Notation argument graph, binary hashes across all deployed software (spanning learned policy weights, the deterministic enforcer logic in both nominal and restricted modes, and the real-time operating system kernel), sensor calibration tables, the adjudicator’s digital signature, mandatory standing operational conditions, an accumulated lifecycle wear budget of operating hours and load cycles, and a calendar expiration timestamp. All evidence links must resolve to these exact reviewed record digests, organized hierarchically beneath a single evidence root structured as a Merkle hash tree (Merkle 1988). Each parent digest is computed from its children’s digests, so changing an evidence leaf changes the root that the manifest signs. Only when the hardware root of trust authenticates this complete cryptographic tree will it permit the motor power stages to energize. While traditional release notes or post hoc compliance certificates summarize safety after the fact, the release manifest is an active, machine-checked gate. The robot checks it before closed-loop control begins, and its runtime monitors revoke motor tracking within a bounded detection-and-response window if any underlying evidence or environmental condition expires.

Merkle, Ralph C. 1988. “A Digital Signature Based on a Conventional Encryption Function.” Advances in Cryptology — CRYPTO ’87, Lecture notes in computer science, vol. 293: 369–78. https://doi.org/10.1007/3-540-48184-2_32.

↪ Byte layout: The release manifest’s fields, types, and digests are given in Release manifest.

Figure 3 routes every release attempt through authentication and physical standing checks before an operating permit can issue. The release gate authenticates the manifest, binary images, and complete set of fault records before verifying current sensor calibration, mechanical maintenance thresholds, and operational design domain conditions. Only an exact cryptographic and physical match enables the plant’s certified startup sequence. Table 6 lists the gate result for each combination of signed case and standing check, including the single path by which stale calibration still reaches COND. During active motion, any breached condition commands an assessed safe fallback before any switch of software partition (the A/B banks of section 16.9.1) or electrical isolation.

↪ Protocol: The gate’s step-by-step authorization protocol is given in Release-gate protocol.

Figure 3: Fail-closed release pipeline: The signed verdict and evidence root pass key, image, and complete fault-record authentication, then current calibration, brake, and operating-envelope checks. Every failure path ends in REFUSE. A valid case reaches UNCOND or COND according to what was signed, and stale calibration reaches COND only through a separately signed restricted case; either way, each proposed action is still checked by the permission path. Attribution: Textbook production team (CC BY-NC-ND 4.0).

Table 6: Release authorization truth table: A restricted mode is a distinct authenticated claim, never an unsigned downgrade of the full case.

Signed case	Evidence and standing checks	Restricted case covering stale calibration	Gate result
UNCOND	All valid and current	Not needed	Full proposal envelope under enforcer; UNCOND
COND	All restricted evidence valid and current	Included if calibration stale	Signed restricted envelope under enforcer; COND
UNCOND or COND	Fault-record root/signature mismatch, expiry, image mismatch, or unknown physical premise	Any	Permit off; REFUSE
UNCOND	Calibration stale	No	Permit off; REFUSE
Separately signed COND	Only the named calibration is stale; restricted evidence and limits valid	Yes	Restricted envelope; COND
REFUSE	Any	Any	Permit off; REFUSE

Each empirical evidence leaf in the assurance Merkle tree must identify its raw sensor trace, instrumentation hardware, calibration log, machine configuration, and automated test harness script. Analytical leaves retain their derivations and assumptions; procedural leaves retain the accountable procedure and its validation for the signed envelope. Measured latency profiles enter the safety case as empirical percentiles, whereas deterministic real-time execution guarantees demand the analytically justified upper bounds specified in Real-Time Command Transport and Bus Determinism. Similarly, collaborative object-handover criteria require load-cell time series recorded against standardized anthropomorphic surrogates across specified contact geometries. By cryptographically anchoring these primary records, an independent auditor or verification engine can reproduce the experimental test suite and pinpoint the exact operating boundaries where each safety claim ceases to hold.

The release manifest bounds the physical envelope and hardware configuration under which its verdict remains valid. Modifying a neural policy checkpoint, altering a real-time thread priority, updating a device driver, or replacing an actuator with an unverified component revision immediately invalidates the manifest, requiring a re-adjudicated safety case. On the warehouse mobile manipulator, for example, the manifest enforces signed wear thresholds on harmonic-drive backlash and electromagnetic brake lining thickness derived from stopping-distance and payload trials. Operating envelope tripwires trigger immediate refusal: on-board load cells detect tote-rack overloading beyond rated payload capacity, while facility procedures prevent operation on unmapped or unsurveyed floor surfaces (table 1). The manifest also encodes the isolated, energy-buffered power rail of the permission path as a standing invariant, running a diagnostic self-test on the hold-up capacitor bank before granting boot authorization. Whenever a runtime sensor detects that a state variable has breached a signed threshold, the hardware permission path interrupts closed-loop trajectory tracking within its certified detection-and-response deadline and brings the system to an assessed fallback state.

To preserve traceability across time, the manifest binds all operational telemetry directly to the exact hardware-software revision that generated it. High-resolution local ring buffers capture boundary excursions for post-incident diagnostics, whereas fleet-wide telemetry summaries reveal systematic mechanical drift across hundreds of operating hours. The curation pipelines examined in section 16.9.5 must preserve this cryptographic lineage whenever field data is promoted to support a later release case.

During daily operation, edge telemetry logs motor torque residuals, control-loop cycle times, and safety enforcer interventions for trend analysis, while the hardware permission path checks physical invariants on every 1 ms permission tick. If a routine maintenance check measures a stopping distance exceeding the signed clearance budget, or if a camera calibration certificate expires, the release verdict is revoked automatically. Re-flashing an older firmware image cannot compensate for worn mechanical friction pads. Unless an engineer deploys a separately signed restricted case (COND) that explicitly accommodates that degraded physical state, the controller executes an assessed emergency stop and locks out autonomous motion until certified maintenance and re-adjudication take place (table 6).

Once its powered stop has brought the base to rest, the warehouse mobile manipulator can reach a quiescent state only after the arm and payload are supported and the assessed holding brakes are engaged before drive power is removed. The base rests stably on the floor, but that support alone does not secure its gravity-loaded arm. For other morphologies, severing motor power is itself the hazard, because the machine collapses under gravity once torque is removed (16.1).

Systems Perspective 16.1: When removing torque causes the harm

Question: Which verdict applies when removing torque causes the harm?

A supported wheeled base at rest eliminates its translational kinetic hazard, though its arm and payload still require qualified support. In contrast, an upright bipedal humanoid retains substantial gravitational potential energy. While resting in a support gantry before standing up, a REFUSE verdict safely holds the robot in its mechanically supported state. Once balanced upright, however, revoking locomotion authority cannot simply de-energize the actuators without inducing an immediate dynamic fall; safe shutdown requires an active, validated arrest or controlled descent strategy.

• Torque removal can cause a fall. An unsupported biped with backdrivable transmissions will collapse if motor currents drop to zero: torque removal leaves gravity-loaded joints without support (Actuation Authority), and an upright biped without active balance diverges like an inverted pendulum (Coupling the distance, lease, and supply budgets). Consequently, such physical plants cannot treat torque removal as a fail-safe stopping condition unless accompanied by certified passive catches, lock-up brakes, or an external tether.
• The fall-arrest response is itself an actuation. Executing a controlled squat, brace, or step-down to bring the robot to rest is itself an active trajectory that requires validated sensorimotor claims, verified timing margins, and fault-tolerance guarantees. In this regime, executing a safe REFUSE action depends on the very control systems maintaining upright stability.
• Wear revokes the running permit. Degradation in foot-sole rubber traction or increased backlash in planetary gearheads alters the dynamic margin required for emergency balancing. When telemetry signals that physical wear has crossed the threshold certified in the safety case, the runtime supervisor must revoke high-speed dynamic locomotion well before the safety-critical arrest maneuvers degrade below their qualifying safety margins.

Checkpoint 16.3: Deriving a verdict from your own measurements

Table 5 lists the measurements needed to support a release case but supplies no raw trial results. Make a copy with columns for value, source, provenance, and premise status, fill those columns with empirical data from hardware trials on your own robotic platform or an illustrative benchmark scenario, and evaluate the resulting release verdict:

• Provenance and premise status: For each row, record measured, derived, datasheet, or illustrative provenance; label selected operating requirements as chosen. A derived result retains its inputs and assumptions and remains illustrative when those inputs are illustrative. A selected substitute for an unmeasured brake value is illustrative, whereas a chosen speed cap needs qualified evidence that it fits. A manufacturer’s rating is datasheet evidence, not a measurement of this unit. Separately apply the Reader Guide’s five premise statuses: established by measurement or derivation, assumed, decided by accountable judgment, unsupported, or outside the threat model. Explain why each credited assumption or restriction is warranted for the signed envelope; a status label grants no authority. Runtime known-true, known-false, and unknown describe current envelope membership, not provenance.
• Verdict derivation: A COND case requires adequate support for every relied-on premise: qualified measurements, justified analysis, or validated operating restrictions. Illustrative values alone still support only an actual REFUSE. Recompute the base’s budget and spare margin from your values. If every relied-on premise has adequate support, name the envelope the COND case signs and the premise that keeps the normal mode unsigned. If a relied-on premise lacks adequate support, derive the verdict the table would support given the missing evidence, and label that verdict hypothetical.
• Artifact label: Mark the filled table as your own work, whose values license no physical machine.

A release manifest binds the verdict to an explicit, reviewed system configuration. Any later modification, whether retraining a perception head, tightening an actuator torque limit, or swapping a camera lens, breaks that closure and reopens some of the underlying claims. The question the rest of the chapter answers is which ones, and how the machine stays contained while the reopened claims are requalified.

16.9 Maintaining Release Through Updates

Continuing the stipulated warehouse branch, suppose the mobile manipulator’s restricted mug-delivery policy is retrained to reduce hesitation at the controlled pick station. Pushing that updated checkpoint directly to the fleet would invalidate the signed manifest and expose the machine to unverified bus loads and contact trajectories. Before the candidate neural policy can issue commands to physical actuators, it must pass back through the release decision. A signed safety case establishes which historical evidence remains valid, which hardware-in-the-loop tests must run again, and how the machine maintains physical containment throughout the update.

↩︎ Every updated checkpoint is a new policy whose earlier evaluations no longer apply, the rule established in Real-Robot Fine-Tuning and Residual Control that gives each one its own manifest and regression evidence.

16.9.1 Modular safety cases and over-the-air updates

Retraining a policy directly alters capability evidence, and neural modifications often introduce side effects across the shared hardware platform: increased neural accelerator memory bus traffic, altered sensor frame processing latency, or modified contact force trajectories. An engineer must trace these cross-subsystem dependencies before deciding which containment records remain valid. While over-the-air (OTA) updates swap out a named software payload, modular safety cases isolate dependencies by recording how each claim relies on specific evidence items and platform assumptions (Denney et al. 2015). Whenever an update alters an underlying dependency, the modular case shows exactly which safety claims are reopened.

The containment argument is the defense against physical harm. It binds together the plant model, physical sensor limits, worst-case execution budgets, and the independent permission path. Key engineering premises include the bounded tracking error tube \(\TrackingErrorBound\), the emergency stopping budget, the passivity barrier for physical contact, and hardware watchdog timing margins. Historical verification records for these containment claims remain valid only if the proposed update preserves the exact operating conditions under which they were measured. For example, replacing a backbone network with a higher-capacity model can increase memory bus contention or cause voltage droop on the power rail even if the deterministic safety-filter binary remains byte-for-byte identical. An unchanged enforcer binary does not imply an unchanged containment argument; its guarantees remain bounded by the validated dynamic envelope \(\ForwardInvariantSafeSet\) and the system-level timing margins established during qualification.

↩︎ The tracking-error tube \(\TrackingErrorBound\) that the containment argument consumes as an invariant is established in The Tracker Handoff and Dynamic Reference Envelopes.

In parallel, the capability argument shows that the robot reliably fulfills its mission within its certified operational design domain. Candidate benchmarking, passive shadow traces, and geofenced closed-loop trials test whether a retrained policy reduces hesitation or improves task throughput. While the low-level enforcer can continuously clamp or reject invalid control proposals to maintain safety, an enforcer that constantly intervenes degrades the robot into an unusable, halting machine. Release engineering therefore evaluates capability and containment together. An update qualifies for fleet dispatch only when the candidate configuration delivers acceptable task performance without undermining the empirical premises supporting its containment envelope.

Modern physical AI platforms preserve configuration integrity during deployment through dual A/B OS partitioning. The update agent streams the candidate image onto the inactive storage bank (Bank B) while the incumbent controller continues executing from the active bank (Bank A). Activating the newly flashed partition requires an assessed stationary update state: the robot must be parked with its payload supported, battery reserves must exceed with margin the energy needed for re-flashing and post-boot self-tests, and the independent safety supervisor must hold all motor drives unpowered or mechanically locked so the robot cannot move during bootloader cutover. Hardware watchdogs govern the runtime decision to commit or abort this cutover (section 16.9.4). Because a single fleetwide signing key is a single point of compromise—an attacker who extracts that key from one compromised endpoint could sign arbitrary firmware for every robot in the field—update architectures use role-separated signing structures where distinct root, targets, and release keys live on separate, hardware-isolated machines. The Update Framework (TUF) pioneered this design, and Uptane extended it to automotive and robotics systems where heterogeneous electronic control units require independently authenticated firmware images (Samuel et al. 2010; Kuppusamy et al. 2016).

Overwriting firmware must never destroy the physical calibration history of an individual robot. Persistent hardware calibration parameter retention separates machine-specific measurements from generic operating system binaries, preventing a calibration clashing failure. Camera intrinsic matrices (\(\CameraIntrinsicCalibrationMatrix\)), extrinsic sensor transformations (\([\DirectionalCosineMatrix \mid \RigidTransformTranslation]\)), kinematic joint zero-point offsets, and motor torque constants (\(\MotorTorqueConstant\)) reflect the mechanical and electrical geometry of an individual machine and drift over time with vibration, thermal cycling, and wear. Storing these values in a dedicated, wear-leveled, non-volatile parameter partition keeps calibration intact when an OS image is flashed. When a firmware update introduces a revised parameter schema, the migration utility writes the transformed schema into a new record while preserving the legacy block, allowing direct rollback to the prior image-parameter pair. Cryptographic checksums verify the bit-level integrity of these stored calibration blocks, while physical self-tests at field release verify that the stored parameters still match the physical machine.

Finally, forensic traceability links every running OS image, policy checkpoint, and calibration partition to its training provenance, compiler flags, and reviewed HIL regression records through the signed release manifest (section 16.8). When an unexpected field intervention or trajectory excursion occurs, these links let incident investigators reconstruct the exact configuration running at that millisecond and determine which safety warrants need re-examination. While a cryptographic digest confirms identity, isolating the physical root cause requires detailed sensor traces and causal analysis.

16.9.2 Staging candidate policies before release

Software simulation models timing and electrical behavior only to the accuracy of its mathematical approximations; it cannot catch memory-bus contention, fieldbus noise, or inverter thermal sag on the real processor and drive electronics. A candidate policy must therefore repeat the hardware-in-the-loop (HIL) regression gates affected by its changes on a physical test bench under full thermal and electrical load. The bench tests the specific interference and fault mechanisms on which release claims depend:

1. Worst-case execution time (WCET) and scheduling jitter: Profiling whether safety filter evaluations complete within their hard real-time deadlines (\(\WorstCasePermissionCycleTime \le \CompletionDeadline\)) while neural workloads drive peak memory crossbar contention and DMA transfers, the falsification campaign of Empirical Verification of Silicon Isolation.
2. Deterministic bus arbitration: Measuring fieldbus communication jitter and cyclic transmission integrity across physical EtherCAT or CAN FD networks under simulated telemetry broadcast floods and electrical noise injection.
3. Power-stage thermal dynamics and current ripple: Verifying that high-frequency control chatter or torque ripple proposed by the candidate policy does not induce excessive inverter switching losses, DC rail voltage sag, or thermal runaway in motor windings (Thermal Duty Cycles).
4. Hardware fault-injection survivability: Validating that physical line breaks, power supply brownouts, or deserializer frame dropouts deterministically trigger the hardware watchdog and safe-stop sequence within certified timing budgets before motor power stages can be damaged.

A candidate policy advances through bench staging only when every required regression test passes and empirical records confirm that timing and physical margins remain intact. Observing zero deadline overruns during a finite bench campaign does not by itself establish a mathematical upper bound on worst-case execution time, nor does it show how the policy will behave on the warehouse floor. In cloud software engineering, blue-green deployment can reduce downtime by preparing a replacement cluster and redirecting traffic after readiness checks. In physical AI, however, blue-green cutover cannot happen mid-stride or at speed. Swapping active control authority between an incumbent controller and a candidate policy while mass is moving requires managing actuator state continuity, motor winding back-EMF, and dynamic tracking tubes (Command steps and mechanical drivetrain shock); de-energizing motor windings or inducing sudden torque steps causes severe mechanical shock loads (\(\GearReductionRatio^2 \RotorInertia \LinkAngularAcceleration\)) and loss of traction. An unvalidated policy also cannot be granted partial motor authority in a populated warehouse to “canary test” edge-case performance.

Safe predeployment staging instead relies on shadow mode deployment, the shadow-operation evidence regime of The four evaluation evidence regimes applied to a release candidate. The incumbent controller \(\pi_{\text{incumbent}}\) supplies proposals, while the independent enforcer retains sole actuator-output ownership and checks each command before fieldbus dispatch. Concurrently in the background, the candidate neural policy \(\pi_{\text{candidate}}\) executes on the host compute SoC, consuming identical live sensor streams \(\MultimodalObservation_{t}\) within its qualified shared-resource budget and computing what control command \(\CandidateControlCommand_t \sim \pi_{\text{candidate}}(\MultimodalObservation_{t})\) it would have proposed. The candidate writes its outputs to an isolated telemetry buffer that grants no actuator authority. Consumers can read that record, but neither the buffer nor the candidate can bypass the enforcer. Shadow inference and recording must stay within the interference and power budgets that preserve the active case. Discrepancies between candidate proposals and the incumbent’s admitted commands are logged as high-rate telemetry events without admitting any candidate command to the drives.

Shadow-mode telemetry monitors two instantaneous divergence metrics:

1. Action discrepancy (\(\FiniteChange\ControlCommand_t\)): The Euclidean (or angular) distance between the candidate proposal and the incumbent control action, measured here by the Euclidean norm: \[\|\FiniteChange\ControlCommand_t\|_2 = \| \CandidateControlCommand_t - \IncumbentControlCommand_t \|_2.\] Sustained spikes in \(\|\FiniteChange\ControlCommand_t\|_2\) identify behavioral divergence where the candidate policy introduces unmodeled bias, high-frequency control jitter, or erratic steering commands. In addition, the discrepancy analyzer monitors the command-rate norm \(\|\CandidateControlCommandDerivative_t\|_2\), which is a torque-rate norm only when \(\ControlCommand\) is a torque command, to detect unmodeled control chatter that would excite mechanical resonances.

2. Safety barrier margin discrepancy (\(\FiniteChange \BarrierFunctionRate_t\)): The differential proximity to forward-invariant safety boundaries under a control barrier function \(\BarrierFunction(\MechanicalPlantState)\) (Safe Sets as Conditional Permission): \[\FiniteChange \BarrierFunctionRate_t = \BarrierFunctionRate(\EstimatedPlantState_t, \CandidateControlCommand_t) - \BarrierFunctionRate(\EstimatedPlantState_t, \IncumbentControlCommand_t),\] where \(\EstimatedPlantState_t\) is the state estimated from the sensor streams \(\MultimodalObservation_{t}\). A negative \(\FiniteChange \BarrierFunctionRate_t\) means the candidate has a smaller modeled barrier derivative than the incumbent. Both derivatives can still be positive, so the sign alone does not imply decreasing clearance or a violated boundary of \(\ForwardInvariantSafeSet\) (defined by \(\BarrierFunction(\MechanicalPlantState)\)).

The two discrepancies answer different questions. A large action discrepancy \(\|\FiniteChange\ControlCommand_t\|_2\) can reflect an alternate useful action, while \(\FiniteChange \BarrierFunctionRate_t\) indicates how the proposals differ in their modeled effect on the barrier. Neither sign alone supplies a verdict; review must consider the current margin, uncertainty, and the condition that the independent enforcer would require.

Shadow mode nevertheless has a limit that more traces cannot remove, the trajectory confinement of that evidence regime, which a release reviewer encounters as counterfactual divergence. Because admitted incumbent proposals determine the plant trajectory, the historical state trajectory \((\DecisionProcessState_0, \IncumbentControlCommand_0, \DecisionProcessState_1, \IncumbentControlCommand_1, \dots)\) is conditioned entirely on incumbent actions, and the candidate’s proposals \(\CandidateControlCommand_t\) never alter it. Conflating open-loop agreement with deployment safety is the open-loop replay fallacy: assuming that high action agreement during passive trace replay guarantees closed-loop dynamic stability. The \(\CovariateDriftBound\) result in Recovery and Compounding Error is an expected-cost bound under its stated imitation-learning assumptions, not a universal law for physical tracking error. A candidate that agrees on incumbent trajectories can still visit unfamiliar states or excite unmodeled dynamics when it closes the loop, the covariate shift that interactive imitation learning was designed to correct (Ross et al. 2011). Shadow mode is an essential pre-filter for gross behavioral anomalies, but never a substitute for closed-loop dynamic qualification.

Ross, Stéphane, Geoffrey Gordon, and J. Andrew Bagnell. 2011. “A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning.” Proceedings of the Fourteenth International Conference on Artificial Intelligence and Statistics (AISTATS) 15: 627–35.

¹² Canary (the miners’ sentinel bird): Miners carried caged canaries because the birds succumb to carbon monoxide before people do, so a bird’s distress warned the crew to leave. The metaphor carries this section’s warning. The canary is the unit exposed to the hazard first, so on a physical fleet its exposure must be bounded by containment, not by how few units are chosen.

Phased canary fleet rollouts¹² expose the candidate to closed-loop operation under a separately supported restricted case. Selecting fewer machines limits exposure but does not bound the consequence of any one action. The restrictions must address the physical hazard:

1. Geofenced operational containment: Canary units operate exclusively within dedicated, surveyed low-risk corridors, such as wide transit aisles devoid of blind rack corners, reduced pedestrian density, and high-friction surveyed concrete (\(\CoulombFrictionCoefficient \ge\) 0.60).
2. Enforced kinematic derating: The real-time safety enforcer clamps candidate policy velocity and acceleration below nominal ratings (\(\SpeedAtDetection \le \CanarySpeedBound < \NominalRatedSpeed\)), expanding stopping distance margins and suppressing transient kinetic energy.
3. Supervised human oversight: High-readiness human supervisors equipped with wireless remote emergency-stop (tele-stop) pendants maintain line-of-sight monitoring over canary units, backed by an active-lease watchdog.
4. Targeted regression observability: The trial measures tracking error variance \(\CandidateTrackingErrorStandardDeviation^2\), drive torque ripple, and enforcer intervention frequency to reveal service regressions. The permission path retains only the containment claims validated for the restricted envelope.

Expansion requires predeclared acceptance criteria tied to the service and physical claims. Intervention-rate non-inferiority,¹³ with a margin \(\NoninferiorityRatioMargin\) fixed before the trial so that the upper one-sided 95 percent confidence bound on the rate ratio \(\CanaryInterventionRate/\IncumbentInterventionRate\) must fall below \(1+\NoninferiorityRatioMargin\), and tracking variance \(\CandidateTrackingErrorStandardDeviation^2 \le \IncumbentTrackingErrorStandardDeviation^2\) are possible capability criteria, with their comparison conditions and statistical assumptions stated. With a zero margin, that upper-bound criterion requires evidence that the candidate is better, which may demand more exposure than a small canary provides; the trial arithmetic of Trial Budgets, Stopping Rules, and Comparisons sets how much operation a given \(\NoninferiorityRatioMargin\) requires, and a sequential test can stop expansion as soon as the evidence suffices. None of these criteria replaces the evidence for stopping, observation, or containment. An enforcer intervention also needs causal review, because suppressing legitimate clamps to improve a rollout metric would weaken the release argument.

¹³ Non-Inferiority Testing: The design comes from clinical trials, where failing to find a difference proves nothing, so a new treatment must instead be shown worse than the standard by no more than a margin fixed before any data arrive (Blackwelder 1982). A canary can therefore pass on modest exposure without proving the candidate better, but only if \(\NoninferiorityRatioMargin\) was not chosen after the result was seen.

Blackwelder, William C. 1982. “‘Proving the Null Hypothesis’ in Clinical Trials.” Controlled Clinical Trials 3 (4): 345–53. https://doi.org/10.1016/0197-2456(82)90024-1.

↩︎ The sequential probability ratio test, which stops a trial campaign as soon as the evidence crosses a precalibrated boundary, is established in Sequential probability ratio testing.

16.9.3 From qualification to a new manifest

Reducing a policy’s hesitation rate at the pick station does not justify relaxing its contact-force limits or floor-friction restrictions; if the retrained mug-delivery candidate were promoted on task speed alone, it would bypass the containment premises that keep the restricted route safe. Instead, the reviewer repeats closed-loop capability evaluation under the restricted route and feed conditions, and repeats the loaded timing and fault tests whose dependencies changed. Unaffected plant evidence remains reusable only while configuration, calibration, wear, and site premises still match.

Assume, still within the stipulated branch, that those results satisfy the predeclared capability criteria and preserve the containment claims. The adjudicator issues a new manifest binding the candidate, retained and repeated evidence, current calibration, and the same restricted mission. At the assessed stationary cutover state, the gate authenticates that manifest and checks current standing conditions before admitting new proposals. Field monitoring then compares the running service with the same success, cycle-time, rescue, and protection criteria. Failed qualification leaves the incumbent case unchanged; a failed standing condition withdraws the affected grant.

16.9.4 Over-the-air staging and watchdog-enforced rollbacks

A candidate written to the inactive bank inherits no operating grant from its predecessor, and rolling back to the prior software image cannot repair a worn brake or a stale calibration. Hardware watchdog rollback triggers must therefore distinguish a failure to boot from a failure during motion. Before tracking is enabled, failed image authentication, startup tests, or fieldbus synchronization can reject the candidate and select the retained image, which must still pass current calibration and standing-condition checks before receiving a permit.

During motion, the independent supervisor first commands the assessed fallback within its measured response budget. Where that response ends in torque removal, the supervisor asserts Safe Torque Off after the required controlled stop; a plant needing a powered hold retains the authority needed for that hold. A missed enforcer heartbeat therefore withdraws tracking permission without making software restart the stopping mechanism. Only after the plant reaches its validated update state may the boot selector change banks.

The image and its compatible calibration schema form the rollback unit. If either record is missing, corrupted, or physically stale, the gate selects REFUSE unless a separately signed restricted case covers the actual state and its limits, such as \(\SpeedAtDetection \le \RestrictedSpeedBound\). Retaining the prior binary image provides an immediate rollback target, but operators must re-validate standing physical conditions before the recovered binary receives an operating permit.

16.9.5 Event-triggered telemetry and safety performance indicators

An enforcer trip can reveal a policy failure, a changed physical premise, or both, and the field record must let the reviewer distinguish those causes before choosing retraining, maintenance, or a narrower envelope. Because wireless summaries alone cannot reconstruct the observations and actuator response around the event, detailed traces are retained locally. Edge event-triggered telemetry captures the sensor, proposal, permission, actuator, and timestamp chain around an intervention or boundary excursion. A local rolling buffer preserves the lead-up, and capture continues through the physical response whenever the qualified recording power path survives. Buffer length, write bandwidth, and hold-up energy are sized from the required reconstruction window and verified under the same contention and power faults as the permission path. A logic-rail capacitor does not guarantee that the full sensor and storage path survives, and recording must never delay the stop.

UL 4600 calls the field measurements that keep a claim alive safety performance indicators (SPIs). Each is a metric tied to a named claim, with a threshold and a predeclared response when the threshold is crossed (UL Standards & Engagement 2023). On the running machine, every standing condition of section 16.5 has one. Measured stop distance at scheduled trials and enforcer trips per operating hour watch the base’s stopping claim, age refusals per operating hour watch the observation-age claim, and localization residuals against their allowance watch the sensor geometry. An SPI whose threshold is crossed withdraws or narrows the grant it watches; one that drifts toward its threshold triggers review before it is crossed, which is the defense against the normalization of deviance of section 16.7.

During routine operation, compact health summaries support fleet monitoring while required incident records retain full provenance locally until transfer succeeds. Learning-data filters may prioritize unfamiliar events for training, provided they never discard required safety evidence or hide repeated failures. Once the traces arrive, a reviewer distinguishes policy hesitation from calibration drift, surface contamination, and mechanism wear before assigning the repair: qualified recovery traces can enter the experience pipeline, whereas reconstructed simulations extend test coverage only over their modeled conditions. A captured event therefore changes the release argument only after its physical cause and operating conditions are established. Reconstructed scenes and retraining can improve a candidate policy, yet neither automatically repairs a physical warrant, so the revised claim must return through the relevant qualification stages before a new manifest grants authority. Because the traces the machine keeps also record the people around it, each record that identifies a person carries standing conditions of its own: a declared purpose, a retention period, and a list of readers, audited like any other premise.

↪ The declarations that govern records identifying people, and the access and retention audit that enforces them, are developed in Recorded people as a standing condition.

16.9.6 Fleet evidence and accountable release

Pooling dissimilar routes into a single fleet mileage total or treating an operator intervention count as a collision rate breaks the safety warrant. Fleet exposure can reveal recurring failures, but interpreting it requires knowing the operating domain, the intervention definition, and the exact system configuration. The release reviewer uses fleet records to challenge the same capability and containment claims, rather than replacing them with a mileage ranking. One public fleet record shows what an interpretable version looks like: Waymo publishes its rider-only crash rates by outcome, each against a human-driven benchmark adjusted to the same locations and each with a confidence interval, and it republishes them as rider-only mileage accumulates (Waymo 2026; Kusano et al. 2025). Figure 4 plots the latest release and the history of two of its outcomes.

Kusano, Kristofer D., John M. Scanlon, Yin-Hsiu Chen, Timothy L. McMurry, Tilia Gode, and Trent Victor. 2025. “Comparison of Waymo Rider-Only Crash Rates by Crash Type to Human Benchmarks at 56.7 Million Miles.” Traffic Injury Prevention 26 (sup1). https://doi.org/10.1080/15389588.2025.2499887.

Figure 4: Exposure licenses claims one outcome at a time: (a) Percent change in crash rate against a location-adjusted human benchmark for each outcome in the latest public release, with 95 percent confidence intervals and the number of fleet crashes behind each estimate; orange marks outcomes with fewer than 20 crashes. (b) The same estimate and interval for two outcomes at each release, against cumulative rider-only miles. Common outcomes converge to narrow intervals; the serious-injury and fatal estimates rest on a few events, so their intervals stay wide however favorable the point estimate. Data from Waymo (2026).

Waymo. 2026. Waymo Safety Impact Data Hub.

In the June 2026 release, after 271 million rider-only miles, the injury estimate rests on 183 crashes and its interval spans a reduction of 79 to 85 percent. The serious-injury estimate rests on 3 crashes and spans 83 to 99 percent, and the fatal estimate rests on 2 and spans 18 to 98 percent. The same mileage therefore licenses a tight claim about common crashes and only a loose one about the outcomes a release decision cares about most, because rare events accumulate slowly however many miles the fleet drives. That is the fourth law, permission must be earned (principle 4), measured on a real fleet. Each outcome’s claim may extend only as far as its own interval, and a reviewer reads the interval before the point estimate.

The signed release manifest records the engineering decision and its accountable owner, and together with the records it binds, it lets an investigator follow one admitted action back to the person who signed for it. The enforcement record logs the admitted command; the manifest in force at that moment names by digest the policy weights, the enforcer and real-time operating system binaries, the calibration tables, and the operating envelope behind it; and the signature on that manifest, made with a key held in a hardware security module, is bound to the sign-off record that names the lead systems adjudicator who accepted that configuration or the update that installed it. The manifest does not itself establish regulatory compliance or determine legal liability. Applicable requirements depend on the machine, intended use, and jurisdiction; the release manifest must preserve the evidence needed for that separate assessment. Throughout this lifecycle, release remains a decision about a named machine under named conditions. Shadow traces, staged trials, and field records can strengthen the next argument only when their operating conditions and limits are explicit, while the manifest and independent permission path retain the restrictions that the evidence supports.

↪ Who answers for each decision the manifest binds, and the duty to report an incident completely and on time, are developed in The Approval Record.

16.10 Fallacies and Pitfalls

In purely digital software, a deployment bug manifests as a silent crash, a corrupted database row, or a dropped network packet; in physical AI, software decisions drive heavy actuators through real space where errors bend steel, destroy machinery, and injure coworkers. Releasing an embodied AI system therefore requires uncovering hidden assumptions before kinetic energy is coupled to physical mass. The following fallacies and pitfalls highlight recurring mistakes where teams confuse software statistical confidence with cyber-physical safety.

Fallacy: Statistical coverage substitutes for deterministic architectural warrants.

Engineering teams frequently present millions of simulated hours and thousands of incident-free test cycles as primary justification for deployment release. While physical and simulated exposure provides valuable empirical evidence regarding typical operating regimes, proving the ultra-low catastrophic failure rate required by a safety release claim demands far more operational hours than any physical test campaign can execute. Simulation environments also depend on idealized models, such as rigid-body dynamics, simplified Coulomb friction, and linear actuator response. Empirical performance and architectural warrants answer fundamentally different questions. A massive trial count cannot substitute for architectural enforcement, such as an independent permission path that revokes motion and executes a certified safe stop. The safety case must establish how deterministic runtime guards actively constrain actuator authority to provably safe physical limits when the learned policy encounters out-of-distribution inputs.

Statistical sampling bounds hazard rates only under observed operational distributions; trial volume cannot substitute for deterministic architectural mechanisms that constrain actuator authority.

Architect’s countermeasure: Couple learned policy evaluation with independently qualified safety monitors. Explicitly state the hazard models, plant dynamics, execution deadlines, and safe-stop fallback conditions under which the system’s safety invariants are deterministically enforced.

Fallacy: A release verdict is a permanent certification of safety.

A machine passes formal validation and enters production under a signed safety case. Over months of operation, brake friction material wears down and lengthens stopping distances, kinematic calibration drifts under daily thermal cycling, and dirt or optical scratches degrade sensor fidelity. Even when the deployed software binaries remain bit-for-bit identical, the physical assumptions underpinning the original release case gradually erode. A signed release verdict certifies safe operation only within a bounded maintenance window and under strict operational thresholds. To maintain safety, the release manifest must establish explicit invalidation triggers and scheduled maintenance intervals tied to hardware lifecycle counters, physical wear measurements, and calibration drift estimates. Once these operational limits are exceeded, the system must automatically restrict its capabilities or halt operation until recalibration and service occur.

Software bit-exactness cannot prevent mechanical wear, material fatigue, or sensor degradation.

Architect’s countermeasure: Treat release manifests as perishable operational leases bounded by operating hours, calendar age, and mechanical cycle counts. Implement automated recalibration self-tests at boot, and require diagnostic verification before energizing high-power motor stages.

Pitfall: Relying on unstated environmental assumptions to support a safety claim.

During commissioning, a team verifies a mobile base’s stopping distance in brightly lit warehouse aisles on clean concrete, documenting floor friction in the safety case while leaving ambient lighting unstated. In production, when the robot enters a dimly lit cross-aisle, longer camera exposure times increase image processing latency, which an age check flags at runtime (section 16.3). Concurrently, sparse visual feature matches degrade state estimation accuracy, introducing unmonitored localization drift that consumes the clearance buffer calculated from well-lit testing (section 16.7). The mechanical brake engages exactly as specified and low-level controller diagnostics report all systems nominal, yet the actual stopping distance margin quietly vanishes. Safety claims depend fundamentally on operational surroundings. If an environmental boundary is omitted from the safety case, the deployment architecture can neither verify the operating conditions at release nor enforce them at runtime.

Unstated operating assumptions silently erode safety margins until an ordinary environmental fluctuation precipitates a collision.

Architect’s countermeasure: Formally document every environmental assumption (such as ambient illuminance in lux, surface friction coefficients, and ambient thermal bounds) as an explicit premise in the release manifest. Pair each premise with a deterministic runtime detector or an enforced facility operational specification.

Fallacy: Shadow-mode qualification guarantees closed-loop dynamic stability.

An engineering team evaluates a candidate neural policy in shadow mode across thousands of fleet operating hours, recording near-zero action discrepancy (\(\|\FiniteChange\ControlCommand_t\|_2 \approx 0\)) between the candidate policy and the certified incumbent controller. The team infers that high behavioral fidelity during open-loop playback proves the candidate policy is ready for autonomous deployment. However, because the incumbent controller retains active authority over the plant, the state distribution is entirely dictated by the incumbent’s dynamics. The candidate policy never experiences the compounding physical consequences of its own commands. Even minor discrepancies in control output can excite unmodeled mechanical resonances, induce severe actuator chattering, or generate phase lag that destabilizes the physical plant the moment control authority is transferred to the closed loop.

Open-loop trace replay conceals covariate shift, compounding autoregressive errors, and unmodeled plant resonances.

Architect’s countermeasure: Treat shadow mode strictly as an initial filter to catch gross algorithmic discrepancies, never as proof of dynamic stability. Require closed-loop Monte Carlo sweeps across perturbed plant models, followed by supervised canary execution in isolated physical test facilities, before granting live actuation authority.

Fallacy: Web-style canary traffic routing is directly applicable to physical machines.

In cloud engineering, canary deployments safely route a small fraction of live network traffic to a newly deployed service, rolling back the deployment if error rates exceed a set threshold. Attempting to mirror this practice by assigning a percentage of live operational missions to an unvetted neural policy overlooks the physical reality of mass and momentum. A 368 kg vehicle moving at 1.3 m/s carries 311 J of kinetic energy. If an unverified model issues an erratic actuation command near an operator, the resulting collision cannot be mitigated by rolling back a container image or tearing down a replica set.

Kinetic energy and physical momentum render live production canary routing hazardous without deterministic architectural containment.

Architect’s countermeasure: Restrict canary deployments to physically geofenced zones devoid of human personnel. If testing in active production environments is necessary, encapsulate the unvetted policy within an independent, non-preemptible runtime safety enforcer. This permission path must deterministically maintain the vehicle within its certified viable state space across all declared sensing, plant, timing, and fault models, relying on hardware watchdog leases and certified safe-stop drive functions to override invalid actions.

Fallacy: Over-the-air updates can be treated as stateless software deployments.

In web architectures, stateless services restart cleanly from immutable container images. Treating OTA updates on physical robots as simple container replacements ignores the reality of hardware-bound state. Every physical machine possesses unique hardware calibrations: camera extrinsic matrices, joint zero-position encoder offsets, and load-cell tare values, alongside individual mechanical wear profiles. If an OTA update overwrites non-volatile storage or fails to migrate calibration schemas, the updated model executes with distorted sensor transformations. Even minor coordinate offsets introduce spatial localization errors that rapidly deplete geometric clearance budgets and invalidate the stopping guarantees established in the safety case.

Embodied systems are fundamentally stateful; software updates cannot be decoupled from machine-specific physical calibration.

Architect’s countermeasure: Decouple machine-specific calibrations into an isolated, schema-versioned non-volatile partition (such as EEPROM or write-protected flash) that persists across operating system bank swaps. Use dual A/B system partitions paired with hardware watchdogs that transition the plant into a safe, depowered, or mechanically locked state before changing the active bank. Require automated calibration validation and power-on self-tests before transferring motion authority to the updated partition.

Fallacy: Continuous high-bandwidth wireless telemetry streaming is superior to edge event-triggered buffering.

To achieve comprehensive operational visibility, an engineering team attempts to stream raw multimodal sensor data (high-resolution video, dense lidar point clouds, and 1 kHz motor current logs) continuously over facility Wi-Fi or cellular networks to cloud dashboards. In dense fleet deployments, wireless channel contention, radio frequency (RF) shadowing in industrial bays, and access-point roaming cause severe packet loss and queue bloat precisely during rapid, safety-critical dynamic events. Continuous network serialization also consumes substantial CPU time, DMA channels, and memory bus bandwidth, creating bus contention that can starve real-time safety controllers of deterministic execution guarantees.

Wireless bandwidth is physically constrained and vulnerable to RF fading; continuous raw streaming alone cannot guarantee preservation of telemetry during critical dynamic anomalies.

Architect’s countermeasure: Transmit only compact, low-bandwidth health heartbeats and summary metrics over wireless networks during routine operation. Maintain continuous, high-rate circular telemetry buffers in local non-volatile storage. When a safety fault, anomalous dynamic event, or emergency stop occurs, latch the pre-trigger and post-trigger event windows locally. Size storage write bandwidth and write endurance to prevent memory bus interference with real-time safety enforcers, and offload event packages once the machine establishes a dedicated, high-bandwidth maintenance link.

16.11 Summary

A deployment release formalizes which physical claims the empirical evidence licenses for a specific physical machine, under what operating conditions, and for how long. For the warehouse mobile manipulator examined across these chapters, release resolves to three concrete physical inequalities: the mobile base stops within surveyed clearance, the manipulator unlatches the cage door below the latch’s mechanical force limit, and a mug handover remains strictly below the contact criterion for an unconstrained human hand. A formal claim-argument-evidence safety case links each inequality to its supporting premises and experimental evidence within a clearly demarcated operating envelope. Because required premises combine conjunctively, an argument is no stronger than its least supported premise; empirical confidence cannot be averaged across heterogeneous requirements. Independent sufficient legs strengthen support in the stipulated probability model, which estimates neither this robot’s hazard rate nor calibrated assurance confidence. In the physical argument, a policy error cannot breach a monitored invariant only while the qualified enforcement, plant, sensing, timing, and fault premises hold; C5 isolation evidence does not by itself establish statistical independence. Recognized machinery safety standards govern this argumentation structure. Within the permission path, only the safety microcontroller’s lease-expiry timer and heartbeat watchdog are rated safety functions; the other formal protective claims rest on the certified drive, scanner, and arm safety functions beneath it.

An adjudicator evaluates the safety case to deliver one of three definitive verdicts: unconditional release (UNCOND), conditional release (COND), or refusal (REFUSE). If release is granted, standing conditions enforce operational boundaries in real time, automatically withdrawing authorization whenever any relied-upon premise becomes false or unobservable. Records that identify people carry standing conditions of their own, declared and audited like the physical premises (Recorded people as a standing condition). Against this book’s illustrative input datasets, every primary claim contains at least one ungrounded premise, compelling a verdict of REFUSE. A separately stipulated branch illustrates the empirical evidence that would justify restricted conditional service (COND). Before final authorization, an adversarial review must try to break the entire argument, and that scrutiny must recur throughout the operational lifespan. A cryptographically signed manifest binds the release verdict to reviewed software and calibration artifacts by cryptographic digest, failing closed if any binary or configuration changes. Any subsequent model or firmware update must return through the same safety case, because open-loop shadow operation cannot evaluate the physical consequences of unexecuted closed-loop control actions. Table 7 collects the load-bearing equations governing deployment release, detailing the physical or statistical boundary each expression establishes and noting where each was derived in earlier chapters.

Table 7: Key equations of deployment release: Each load-bearing equation of the chapter, the physical boundary it bounds or decision it settles, and the equation where it is derived. Stopping, contact, latch, and exposure relationships originate in preceding chapters; the release case incorporates their mathematical guarantees as foundational premises.

Equation	What it bounds or decides	Derived in
\(\StoppingDistance \le \ClearDistance,\ \CollaborativeContactForce \le \AssessedContactForceLimit,\ \WorstCasePermissionCycleTime \le \CompletionDeadline\)	The three physical criteria every release claim must evidence: stopping clearance, contact force, and execution timing	equation 1
\(\SpeedAtDetection\,\PrebrakeDelay + \ResidentStopDistance(\SpeedAtDetection) + \LocalizationBound + \ProtectiveClearanceMargin + \TrackingErrorBound \le \ClearDistance\)	The mobile base stopping budget, whose unspent margin every premise of the stopping claim draws on	equation 12.1
\(\UnbrakedImpactForce = \SpeedAtDetection\sqrt{\HertzianContactStiffness\,\ReducedImpactMass}\)	The peak transient handover force (\(\ReducedImpactMass\) is the hand-arm reduced mass), establishing the maximum approach speed permitted by the contact criterion	equation 12.13
\(\BrakingOnsetContactForce = \ContactTripwireForce + \LatchPlateStiffness\,\LatchApproachSpeed\,\ContactLoopResponseTime\)	The contact force developed against a door latch before arm braking begins	equation 12.11
\(\BrakingOnsetContactForce/\LatchPlateStiffness + \LatchApproachSpeed^2/(2\ArmStoppingDeceleration) \le \LatchForceLimit/\LatchPlateStiffness\)	The arm deceleration the door-opening branch must guarantee, bounding admissible approach velocity	equation 12.12
\(\Time \ge 3.0/\ConstantHazardRate\)	The failure-free testing exposure required, at 95% confidence, to demonstrate a failure rate \(\ConstantHazardRate\) per operating hour, showing why empirical exposure alone cannot validate catastrophic risk claims	equation 7.9
\(\Pr(\AssuranceClaim) = \prod_{i} \RequiredPremiseConfidence_i\)	Probability of an exact conjunction in the stipulated independent-premise model; not measured robot hazard or calibrated assurance confidence	equation 2
\(\Pr(\AssuranceClaim) = 1 - \prod_{j} (1 - \ArgumentLegConfidence_j)\)	Probability of an exact union in the stipulated independent-leg model; C5 isolation alone does not establish statistical independence	equation 3

Key Takeaways: Deployment release and safety cases

• The envelope bounds the claim: A release claim covers only the speeds, payloads, surface friction coefficients, clearances, and contact scenarios for which empirical evidence was systematically collected. Every dimension of the operational design domain requires an active runtime monitor or a strictly enforced site procedure.
• Doubt accumulates along required premises: A conjunctive argument (\(\bigwedge_i \RequiredPremiseClaim_i\)) is no stronger than its weakest required premise and is often strictly weaker; confidence cannot be averaged across premises. High empirical accuracy in perception cannot offset an unmonitored braking margin or an uncharacterized tail latency. Independent sufficient legs reduce doubt under the stipulated probability model. Policy validation and an isolated permission path do not automatically constitute such legs; the physical containment claim still requires qualified plant, sensing, timing, and fault premises.
• Standing conditions make release revocable: Every relied-upon premise requires an active detector or operational procedure, an explicit checking cadence, and a validated safety action triggered whenever the premise evaluates to false or unknown. The signed safety case binds these obligations directly to the machine across its operational life.
• Updates return through the release argument: Shadow deployment reveals policy divergence without testing the closed-loop physical consequences of those divergent actions. Rigorous closed-loop qualification and a re-evaluated manifest still govern deployment authorization; every update must preserve machine-specific calibration and execute a validated stop or hold during software cutover.
• An unknown premise refuses, and refusal names the next work: In safety argumentation, unknown envelope membership refuses exactly as a measured violation does, while its cause is logged separately. On this book’s illustrative walkthrough, the mobile manipulator receives an explicit verdict of REFUSE. A structured refusal is productive: it isolates the missing measurements, identifies the claims they would ground, and defines the residual operational envelope that remains once those gaps are closed.
• Useful service needs its own evidence: The stipulated restricted mug-delivery workflow achieves COND only by satisfying concrete task-success, cycle-time, and human-intervention criteria alongside safety claims C1–C6. Safety filtering can preserve high task completion rates even when raw proposer policy autonomy is comparatively modest.
• No verdict moves the proposal boundary: Under both UNCOND and COND, learned policies merely propose actions while the hardware permission path decides physical admission. Within that permission path, only the safety MCU’s lease-expiry and heartbeat watchdog is a rated safety function; the admission checks are not rated. Entering a restricted operational mode requires its own signed release case, never an informal or ad hoc runtime downgrade.

The fourth law, permission must be earned (principle 4), establishes that permission to operate must derive strictly from recorded evidence and expire whenever that evidence lapses. Standing conditions transform this principle into an active software and hardware mechanism. Each condition couples a required premise with a dedicated detector, a monitoring cadence, and an enforced safety response. Consequently, the loaded stopping trials that would support a conditional release for the warehouse mobile manipulator become binding empirical warrants whose invalidation immediately terminates authorization. Under this book’s illustrative records, that grant is never issued, because each of the six primary claims relies on at least one premise that remains ungrounded or unknown. The stipulated delivery branch demonstrates how empirical field trials could substantiate useful restricted service and specifies the runtime conditions necessary to sustain that grant. Just as a manual lease restricts human or teleoperation authority to the validity window of its evidence, and precommitment binds test evaluation to rules established before observations occur, deployment release binds fleet deployment to verifiable physical limits. Release is the widest operational authority granted in this book, and even it never reaches the actuators directly. Every motion it licenses still crosses the causal boundary only through the permission path and the rated functions beneath it.

↩︎ The manual lease that bounds human authority to the validity window of its evidence is established in Arbiter execution and manual-lease heartbeats.

16.12 Historical Perspective and Further Reading

Long before it became an engineering artifact, the modern safety case originated in the philosophy of practical reasoning. Toulmin (1958) decomposed argument structures into concrete elements: an explicit claim, the ground data offered to support it, an inferential warrant that licenses the logical step from data to claim, and the rebuttals that identify conditions under which the warrant fails. That structural anatomy survives almost unchanged in modern deployment release arguments. In the late 1990s, safety engineers translated these philosophical foundations into auditable systems practices. The Claim-Argument-Evidence (CAE) methodology introduced by Bishop and Bloomfield (1998) and the Goal Structuring Notation (GSN) formalized by Kelly (1998) transformed implicit engineering convictions into graph-structured arguments that an independent reviewer can inspect link by link. Later, the autonomous vehicle community adapted this goal-based assurance framework in ANSI/UL 4600 (UL Standards & Engagement 2023), requiring explicit argumentation over positive and negative evidence, concrete safety performance indicators, and rigorous independent assessment.

UL Standards & Engagement. 2023. ANSI/UL 4600 Ed. 3-2023: Standard for Evaluation of Autonomous Products. UL Standards & Engagement.

Butler, Ricky W., and George B. Finelli. 1993. “The Infeasibility of Quantifying the Reliability of Life-Critical Real-Time Software.” IEEE Transactions on Software Engineering 19 (1): 3–12. https://doi.org/10.1109/32.210303.

Kalra, Nidhi, and Susan M. Paddock. 2016. “Driving to Safety: How Many Miles of Driving Would It Take to Demonstrate Autonomous Vehicle Reliability?” Transportation Research Part A: Policy and Practice 94: 182–93. https://doi.org/10.1016/j.tra.2016.09.010.

Bloomfield, Robin, and Bev Littlewood. 2003. “Multi-Legged Arguments: The Impact of Diversity Upon Confidence in Dependability Arguments.” Proceedings of the 2003 International Conference on Dependable Systems and Networks, 25–34. https://doi.org/10.1109/DSN.2003.1209913.

Two foundational results established the statistical limits of empirical testing, fundamentally shaping what a release argument can claim. First, Butler and Finelli (1993) proved that the ultra-low failure rates demanded of life-critical software cannot be validated through testing alone; verifying a rate of \(10^{-9}\) failures per operational hour demands on the order of \(10^9\) failure-free test hours. Decades later, Kalra and Paddock (2016) applied that same arithmetic to embodied autonomy, showing that an autonomous fleet would have to drive billions of operational miles to establish statistical parity with human drivers. A hazard mitigation claim therefore cannot rest solely on driving miles; it requires an architectural warrant, such as formally verified runtime safety envelopes and deterministic interlocks, alongside empirical testing. Second, redundancy cannot simply be assumed to yield statistical independence. The classic empirical study by Knight and Leveson (1986) demonstrated that independently written software implementations suffer correlated failures far more often than independent probability models predict. As a result, a multi-legged safety argument (Bloomfield and Littlewood 2003) must provide empirical and architectural evidence for the independence of its redundant legs rather than treating diversity as an axiom. On the running machine, claim C5 carries that burden.

The final historical lesson concerns the temporal fragility of assurance. The Rogers Commission report on the Space Shuttle Challenger disaster (Presidential Commission on the Space Shuttle Challenger Accident 1986) and Diane Vaughan’s subsequent sociological analysis (Vaughan 1996) revealed that safety cases rarely collapse from an isolated blunder. Instead, arguments degrade through the “normalization of deviance,” a slow organizational erosion in which unexplained anomalies are repeatedly rationalized until a catastrophic threshold is breached. Dynamic safety cases (Denney et al. 2015) counter this failure mode by maintaining the argument as an active runtime process, continually validating underlying assumptions against operational telemetry. Because embodied systems require continuous post-deployment evolution, compromise-resilient update frameworks such as TUF (Samuel et al. 2010) and Uptane (Kuppusamy et al. 2016) established that the software delivery channel is itself a primary attack surface. The release architecture developed here joins these lines of work. The deployment verdict is cryptographically bound to a signed manifest validated by the target controller before motion begins, and every environmental assumption remains a standing operational condition whose violation revokes execution authority within the qualified detection-and-response bound.

Presidential Commission on the Space Shuttle Challenger Accident. 1986. Report of the Presidential Commission on the Space Shuttle Challenger Accident. U.S. Government Printing Office.

Denney, Ewen, Ganesh Pai, and Ibrahim Habli. 2015. “Dynamic Safety Cases for Through-Life Safety Assurance.” 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, 587–90. https://doi.org/10.1109/ICSE.2015.199.

Samuel, Justin, Nick Mathewson, Justin Cappos, and Roger Dingledine. 2010. “Survivable Key Compromise in Software Update Systems.” Proceedings of the 17th ACM Conference on Computer and Communications Security (CCS), 61–72. https://doi.org/10.1145/1866307.1866315.

Kuppusamy, Trishank Karthik, Akan Brown, Sebastien Awwad, Damon McCoy, Russ Bielawski, Cameron Mott, Sam Lauzon, André Weimerskirch, and Justin Cappos. 2016. Uptane: Securing Software Updates for Automobiles. Paper presented at the 14th Embedded Security in Cars Conference (escar Europe).

Six foundational works reward careful study, each anchoring a distinct dimension of the release argument:

• Toulmin (1958) introduces the claim, warrant, backing, and rebuttal framework that underpins modern structured argumentation, establishing why inferential warrants must be scrutinized independently from raw empirical data.
• Bishop and Bloomfield (1998) articulates the Claim-Argument-Evidence (CAE) framework for critical software systems, providing the structural basis for the assurance scorecard in table 2.
• Kelly (1998) introduces Goal Structuring Notation (GSN) and formalizes pattern-based approaches for managing safety cases across system lifecycles, establishing the graphical formalism illustrated in figure 1.
• Knight and Leveson (1986) provides empirical evidence of correlated failures in diverse redundant software, demonstrating why claims of subsystem independence must be actively verified rather than taken as an architectural postulate.
• Vaughan (1996) reconstructs the organizational and technical breakdown of the Challenger launch decision, defining the concept of normalization of deviance that runtime safety performance indicators are designed to detect and arrest.
• Koopman and Wagner (2016) identifies inductive machine learning among the core challenges confronting autonomous vehicle validation, proposing phased operational envelope expansion, hardware-isolated runtime monitors, and systematic fault injection, the triad that this chapter’s release protocol builds on.

Bishop, Peter, and Robin Bloomfield. 1998. “A Methodology for Safety Case Development.” In Industrial Perspectives of Safety-Critical Systems: Proceedings of the Sixth Safety-Critical Systems Symposium, edited by Felix Redmill and Tom Anderson. Springer. https://doi.org/10.1007/978-1-4471-1534-2_14.

Kelly, Timothy Patrick. 1998. “Arguing Safety: A Systematic Approach to Managing Safety Cases.” PhD thesis, Department of Computer Science, University of York.

Koopman, Philip, and Michael Wagner. 2016. “Challenges in Autonomous Vehicle Testing and Validation.” SAE International Journal of Transportation Safety 4 (1): 15–24. https://doi.org/10.4271/2016-01-0128.

What’s Next: From release to responsibility

Who answers for the decisions behind a signed manifest? The manifest names the adjudicator who accepted the configuration and its operating envelope, but the crossing rule, the staffing of the remote assistant, the permit under which the machine runs, and the uses of the records it keeps were each decided by someone else, and none of them appears in a per-tick log. Responsible Physical AI traces those decisions to named owners, tests whether each human role the safety argument relies on is one a person can perform, converts gaps in how well the machine detects different groups of people into gaps in stopping distance, and collects all of it in an approval record that the release gate reads, so that a decision with no owner refuses operation the way an unknown premise does.