Abstract
Physical AI: humanoids and mobile manipulators in factories, warehouses, logistics, and eventually homes, is being commercialized faster than the institutions that price and govern its risk can adapt. Conventional insurance fails on contact: no loss history, an insured object that changes with every software update, failures correlated across fleets, opaque fault attribution, and, where a human remains in the loop through teleoperation, an agency boundary between human and machine that neither product liability nor workers' compensation was built for.
This paper describes an architecture that turns those liabilities into a defensible system: an explicit, measurable safety constitution anchored in existing standards; a managing-general-agent structure backed by reinsurance; an engineering-derived risk prior refined by telemetry; and a standardized incident record. PAIDS, the Physical AI Incident Data Standard, that is simultaneously the underwriting engine, the claims-attribution mechanism, and a cross-OEM safety knowledge base.
The throughline: whoever prices physical-AI risk is necessarily whoever holds the clearest picture of how it behaves.
1 · Why physical AI breaks traditional insurance
Six structural features distinguish it from any existing line.
No actuarial history. Production humanoids are too new and too fast-changing for credible loss distributions. Wait for losses and you cannot enter the market; price without data and you price blind.
Continuously mutating risk. An over-the-air update can change perception, control, or behavior overnight; the object on Tuesday is not the one underwritten on Monday. ISO 10218-1:2025 §5.3.5 already requires that safety-parameter changes trigger a restart, carry a checksum, and be locked during automatic operation, the hooks to which Boop's material-change obligations attach.
Correlated fleet risk. A defective version on ten thousand units is not one accident but ten thousand, violating the independence assumption behind actuarial diversification. No existing line is architected for this.
Opaque fault attribution. Distinguishing design defect (OEM), configuration error (integrator), operational breach (customer), environment, and adversary requires event-level data that today is siloed, inconsistent, and contested. Without a standardized record, claims cannot be resolved efficiently and subrogation is near-impossible.
No regulatory floor yet. ISO 10218 and ISO/TS 15066 give a real baseline for industrial and collaborative robots, but they govern industrial environments and were not written with insurance in mind. Deployment is already running past their scope.
Hybrid agency. In teleop-assisted deployment the insured risk is neither a product nor a service but a human-robot system whose agency boundary shifts dynamically between autonomous execution, supervised exception-handling, and direct remote control. Product liability attaches to products and workers' compensation to employees; neither cleanly handles the remote operator who causes harm through a machine. This is the most novel of the six, needing a new category rather than a refinement of an old one.
2 · Context
Conventional product liability and workers' compensation can be stretched over early deployments, but neither is structured for software-defined, fleet-correlated, human-in-the-loop risk. Pricing and governing physical-AI risk requires an instrument those lines lack: a standardized, telemetry-grounded incident record from which residual risk can be computed. The underwriting problem and the safety-data-infrastructure problem are the same problem, which is why this paper treats them together.
One scoping fact follows from Boop's coverage precondition (Section 3): the addressable population is the set of deployments certified to the applicable ISO standards, bounded, and verifiable deployment-by-deployment through certification documentation at underwriting.
3 · The regulatory baseline
Existing standards define the compliance floor to which Boop's coverage attaches; their gaps define the territory Boop's own standards work must fill. ISO 10218-1:2025 (industrial robots, third edition) governs design, control, safety functions, mode management, motion limiting, collaborative capability, cybersecurity, and validation; ISO 10218-2:2025 governs integration. ISO/TS 15066:2016 governs collaborative operation: shared workspace without fixed separation, defining four operation modes and biomechanical force/pressure thresholds by body region.
These are not optional: ISO 10218 compliance underpins CE marking, OSHA practice, and enterprise procurement: Boop treats certification as a precondition for coverage, not a risk modifier. An uncertified system has no verified safety baseline and its residual risk cannot be priced.
3.1 The robot class framework and its actuarial value
ISO 10218-1:2025 introduces a robot class system with direct actuarial utility:
| Parameter | Class I | Class II |
|---|---|---|
| Mass per manipulator (M) | ≤ 10 kg | > 10 kg |
| Maximum achievable speed | ≤ 250 mm/s | > 250 mm/s |
| Maximum force per manipulator (FMPM) | ≤ 50 N | > 50 N |
The 50 N threshold is the empirically derived pain-onset boundary (the Mainz Study, FP 0317): a Class I robot within its certified parameters cannot apply forces sufficient to cause pain in normal contact. Robot class is therefore a primary exposure variable, the Class I severity distribution is biomechanically bounded in a way Class II is not, and the cold-start prior is parameterized by class.
Critical scope limit: FMPM bounds contact force, not impact energy. The biomechanical severity argument holds for the hazard ISO/TS 15066 addresses: quasi-static and low-speed transient contact, but applying it to whole-body dynamic events is a category error, not a conservative approximation. A humanoid that loses balance, topples, or is knocked into a person is not a contact-force event; it is a dynamic impact event governed by entirely different injury mechanics (peak acceleration, impulse, contact duration, and location-specific criteria such as the Head Injury Criterion and the thoracic viscous criterion) that appear nowhere in the class framework. A robot can be Class I on FMPM and still be a serious impact hazard if it can fall.
This matters because Boop's near-term market is humanoids, which carry two hazard modes the cobot-derived standards do not parameterize: a fall from standing, and, more frequent and so more actuarially significant, a loss of balance during task execution (under payload, at extreme pose, recovering from a push, on a degraded floor): Boop therefore treats whole-body dynamic hazard as a distinct severity axis, parameterized by center-of-mass height and total mass (bounding fall potential energy) and the payload mass and velocity envelope. The near-miss signal is already instrumented on any balancing humanoid: the balance controller's own telemetry: IMU, zero-moment-point or ground-reaction estimates, balance-recovery activations, recorded in PAIDS as stability events, with balance-recovery activation rate a leading indicator of fall risk just as protective-stop frequency is for contact risk.
3.2 The four collaborative operation modes
Each ISO/TS 15066 mode is a distinct risk structure with a distinct claims protocol; the mode active at incident time is among the most diagnostic facts in any record.
- Safety-rated monitored stop (SRMS). Robot stationary whenever a human shares the workspace; any contact implies sensor failure, workspace-design failure, or egregious human action, points to integration and sensor integrity.
- Hand guiding (HG). Intentional contact is inherent; injury comes from joint pinch, ergonomic strain, or unexpected robot-initiated motion.
- Speed and separation monitoring (SSM). Concurrent motion with a maintained separation distance; incidents arise from monitoring failure, unanticipated operator motion, or misconfigured separation, the hardest to attribute, requiring event-recorder reconstruction.
- Power and force limiting (PFL). Contact permitted but force/power limited; incidents are expected contacts that exceeded the body-region threshold (Annex A, distinguishing quasi-static clamping from transient recoil).
3.3 The teleoperation gap
The ISO framework assumes autonomous robots and co-located operators. It does not address teleoperation, where the critical human is remote, may supervise several robots, is subject to network latency, and works under human-factors conditions the standards do not contemplate. ISO 10218-1:2025 §5.2.8.3 defines "external control" and requires only that it be deliberately enabled, not override local control, and meet PL a, adequate for an occasional remote supervisor, silent on latency as a safety variable, operator qualification and fatigue, supervision ratios, and OEM/platform/customer liability allocation. ISO/TC 299 will likely address this in a future working group; Boop's PAIDS schema is designed to generate the empirical record from which such a standard could be built. Until then: Boop's teleop readiness criteria (§6.3) fill the gap using the aviation, UAV, and fleet-telematics evidence base.
4 · The teleoperation risk structure
Teleoperation is a structurally different problem from autonomy, not a simplified version of it, and it requires distinct treatment at every layer.
4.1 Deployment modes and the agency spectrum
Current teleop spans data-collection (demonstration for imitation learning; controlled, low-risk), productive teleop with a safety underlay (human controls the task, onboard safety functions run autonomously beneath, the model Boop's coverage primarily targets), exception-handling (autonomous baseline, human resolves out-of-envelope cases, the scaling model on a two-to-five-year horizon), and supervisory control (one operator monitors many robots). These are not discrete states but a spectrum on two axes: robot autonomy and human engagement:
| Mode | Robot autonomy | Human engagement |
|---|---|---|
| Full teleoperation | Low: executes commands | Continuous active control |
| Assisted teleoperation | Medium: safety layer autonomous | Continuous task control |
| Exception handling | High: autonomous baseline | Intermittent intervention |
| Supervisory control | Very high | Monitoring with rare override |
| Full autonomy | Complete | None |
The transitions between modes are disproportionately high-risk: a robot handing control to a remote operator inherits whatever degraded situational awareness that operator has after passive monitoring; a robot resuming autonomy after an intervention may be in a workspace state its validation never anticipated. PAIDS defines transitions as a distinct event type.
4.2 Latency, safety architecture, and the two-layer distinction
A properly architected teleop system has two independent control layers, and the latency argument applies precisely to each. The safety function layer: collision, force, proximity, stop, runs onboard, responds at certified hardware latency (10–80 ms), and is independent of any command source (ISO 10218-1:2025 §5.2.8.3; Article III). The task execution layer runs through the teleop link at full end-to-end action latency: video capture and encode (50–150 ms), network round-trip (5–20 ms local, 80–200 ms continental, 500–700 ms geostationary satellite, 25–60 ms low-earth-orbit constellations), operator perception and motor response (250–500 ms), actuation (10–50 ms), commonly exceeding 600 ms cloud-mediated.
The consequence is precise. Teleop latency does not degrade the onboard hazard response; the certified protective separation distance and Tresponse in the simplified form of the ISO/TS 15066 protective-separation relation, S = (v_robot + v_human) × (T_response + T_stop) + safety_margin, remain valid because the safety layer is unaffected. What latency degrades is the operator's ability to prevent a situation before the onboard system must engage. Under low latency, operator and onboard system share the safety margin; under high latency the prevention window shrinks toward zero and the onboard system carries the margin alone. The actuarial signature is therefore not a workspace-geometry failure but elevated protective-stop frequency and near-miss load, a predictable function of the latency profile, captured by pairing teleop_latency_rtt_p95_ms with fleet protective-stop rate.
Latency variance is worse than high mean latency. A consistent 300 ms delay is compensable; latency fluctuating between 100 ms and 800 ms breaks the operator's learned compensation. Jitter is the most safety-relevant single metric.
Network quality is consequently a coverage condition: below the floors in §6.3 the task layer no longer provides meaningful preventive value, which changes the claim-frequency profile and the appropriate loading.
4.3 The operator as a risk variable
In autonomous deployment, human factors enter through the integrator (workspace design) and customer (task assignment). In teleop they are central, and the operator population is fluid: OEM engineers (highly trained but not representative of scale), trained customer staff (standards set per-OEM with no common framework), specialized teleop service providers (a nascent managed-service category), and increasingly offshore operators exploiting wage differentials: Boop requires documented certification regardless of geography, with the platform provider warranting that operators meet the applicable standard. One consequence is deliberate: offshore latency (150–250 ms) generally exceeds the collaborative-workspace network floor in §6.3, so offshore-operated deployments are typically eligible only in non-collaborative configurations or under the reduced-workspace, higher-premium condition.
The aviation and UAV evidence base applies directly and is the basis for treating these as rated variables:
- Automation complacency. Operator vigilance and response speed degrade when an automated system rarely requires intervention, a well-documented failure mode in pilots supervising highly automated aircraft, and structurally identical to the exception-handling teleop model, where the operator is nominally responsible for safety but seldom acts. The operator handling one exception an hour is measurably less alert to the next than one continuously engaged. This is the mechanism behind the teleop frontier in Section 9.
- Skill decay. Manual intervention skill degrades after sustained passive supervision; an operator called on for a fine-manipulation task after three hours of monitoring is not in the cognitive state of one continuously teleoperating.
- Supervision ratio. Human attention is not divisible across demanding parallel tasks without degradation; air-traffic-control research shows error rates rising nonlinearly above roughly four to six simultaneously tracked objects. One-to-one teleoperation is safe but uneconomical; one-to-four may be manageable in controlled environments; the one-to-twenty-and-beyond that aggressive scaling implies falls well outside the reliable attention envelope for anything but passive monitoring of simple autonomous tasks.
- Fatigue. Error rates rise sharply after four to six hours of continuous monitoring, with the steepest degradation in situation-assessment quality rather than motor control.
Ratio, session length, and certification tier are therefore rated inputs with surcharge tiers and hard limits above which coverage is unavailable regardless of premium.
4.4 Tripartite liability and the workers' compensation interface
In teleop the causal structure spans three parties with independent exposure: the OEM (hardware, onboard software, safety functions), the teleop platform (interface, network quality, session management, operator assignment and training), and the customer (operator selection, task assignment, supervision, compliance with session and certification limits). In a serious incident all three are represented by counsel, hold partial evidence, and have incentives to attribute causation elsewhere; the PAIDS record and the Layer 2 causal model must support attribution across all three. A practical response is a no-fault first-response structure: pay the claim quickly against the policy, then subrogate against the responsible party from the PAIDS record, which raises premium to fund the float but materially improves the product for customers needing fast resolution.
The teleoperator is also a worker. A remote operator's error injuring a co-located worker creates a workers' compensation claim that may be subrogated against OEM, platform, or customer, a multi-party scenario with no established case law, since the proximate cause was a human, not a pure product defect. The policy form needs an explicit teleop subrogation-coordination clause.
4.5 Operator certification
No body has defined what certifies a physical-AI teleoperator. OSHA covers powered industrial trucks, FAA Part 107 covers small UAS, nothing covers humanoid teleoperation, and ISO/TC 299 has not convened a group. As the entity pricing operator risk: Boop has both the incentive and the empirical basis to define it; a certification framework specifying curriculum and hours, task-complexity tiers, session and ratio limits, network minimums, and recertification is the practical standard until an ISO equivalent exists.
5 · The safety constitution
Asimov's Three Laws were written to fail: "harm" undefined, conflicts unresolved, no path from rule to checkable behavior. A rule that cannot be checked cannot be underwritten. The existing standards are checkable but scope-limited and silent on fleet-systemic and hybrid-agency risk: Boop's constitution states principles each definable, measurable through telemetry and PAIDS, and enforceable through certification and coverage. The articles are lexically ordered: lower number wins in conflict, and operational detail lives in the readiness layer (§6.3) and the incident standard (§7), so the constitution itself stays terse.
Preamble. A robot system is insurable only insofar as its behavior is bounded, auditable, and governed.
- I. Human safety. Shall not cause death, serious injury, or foreseeable physical harm to any human. Absolute. Operationally: ISO 10218-1:2025 §§5.3–5.5 and ISO/TS 15066 Annex A; PAIDS severity 4–5 is a presumptive breach; in teleop the onboard safety functions enforce this without derogation by any remote command.
- II. Systemic safety. Shall not be deployed in a configuration creating correlated risk across multiple units. The modern Zeroth Law. Operationally: a portfolio accumulation model per version, model, and platform; OTA safety-parameter changes require 72-hour advance notice; a platform training standard that correlates operator error across deployments is treated like a correlated firmware version.
- III. Bounded controllability. Shall follow authorized operators and refuse instructions violating I or II; obedience is bounded by the higher articles. The safety-function layer sits architecturally beneath the control layer and is not overridable by any command source, local or remote. Operationally: override attempts are logged (
safety_function_override_attempted); a remote override attempt preceding a contact event is presumptive Article III breach by operator and platform. - IV. Environmental awareness. Shall maintain awareness sufficient to avoid foreseeable contact with people, animals, and property outside the task, applying both to onboard perception and, in teleop, to the interface's provision of situational information. Operationally: perception validation and interface-adequacy assessment in §6.3; camera coverage, latency, and resolution documented in Phase 0.
- V. Auditability. Behavior shall be reconstructible from tamper-evident records, including the teleop session record (operator commands, network logs, session duration, ratio). Operationally: the on-robot event recorder and PAIDS schema (§7); inability to produce compliant records suspends coverage for the incident.
- VI. Governed mutation. Changes to software, weights, or safety parameters are changes to the insured risk requiring notification, staged validation, and, for safety parameters, a restart-and-reverify cycle (ISO 10218-1:2025 §5.3.5). Material teleop-platform changes (interface, latency compensation, operator-assignment logic) are treated equivalently. Operationally: notification timelines by change category (72 h safety-parameter; 24 h model update; same-day patch).
- VII. Privacy. Shall collect and transmit only what safety and operation require, protecting bystander and operator data alike. Operationally: operator session data pseudonymized: statistics to Boop, identity hashed and retained by the platform, de-anonymized only through formal subrogation.
The §6.3 readiness criteria are the auditable form of these articles.
6 · The four-layer architecture
6.1 Layer 1. Actuarial and pricing
Expected loss cost by coverage type, decomposed into frequency × severity. The cold-start prior is built from OEM FMEA, exposure-rated analogues (workers' comp, product liability, equipment breakdown, fleet telematics), and standard test data, parameterized by robot class and deployment mode; teleop adds operator-associated factors (ratio, session length, latency tier, certification level) that modulate frequency as driver behavior does in fleet telematics. Bühlmann credibility weights each unit toward the population as telemetry accrues; for teleop a separate operator-cohort dimension lets demonstrated low-incident operators carry favorable weighting across models and customers, as commercial driver experience travels across fleets. Premium floats against the live Layer 2 score, with surcharges for risky update windows, high ratios, degraded-network periods, and out-of-certified-scope operation. A portfolio accumulation sub-model tracks correlated exposure per version, platform, and certification cohort, the operational form of Article II.
6.2 Layer 2. ML risk-scoring and claims
Risk score. Telemetry → continuous expected-loss-cost score, physics-prior cold start, Bayesian update: Autonomous features: mode distribution, safety-function trigger patterns, protective-stop and override rates. Teleop adds session duration, latency statistics, ratio, task-complexity class, certification tier, pseudonymized operator history, and transition frequency, structurally the fleet-telematics driver-scoring pattern.
Causal model. For teleop incidents a three-branch protocol: OEM (hardware/software the proximate cause?), platform (situational awareness, interface, latency?), operator (fatigue, distraction, overextension?), each branch satisfied by distinct PAIDS fields, the outputs feeding subrogation routing. A dedicated sub-model watches the window after each control-mode transition and feeds a transition-risk surcharge.
Cybersecurity: two orthogonal axes. §5.1.16 requires a threat assessment, but its scope is the robot's own control system, not the teleop network or supply chain. A flat "cyber" category conflates the causal vector (which sets the PAIDS detection signature) with the responsible party (which sets subrogation); they do not map one-to-one. Four vectors:
| Vector | Detection signature | Responsible party |
|---|---|---|
| Vulnerability exploitation | Anomalous command/sensor sequence pre-incident | OEM (§5.1.16 duty) |
| Supply-chain compromise | Behavioral drift after an OTA event | OEM (§5.1.16 duty) |
| Teleop network attack | Latency spikes, jitter, command-stream anomalies | Platform |
| Credentialed-operator compromise | Authentic, individually valid, collectively hazardous commands | Platform / customer access control |
The credentialed-operator vector is the case that most tests the architecture: a network attack can in principle be filtered at the channel, but authentic commands cannot, so the only backstop is the onboard safety layer's independence (Article III / §5.2.8.3). If a valid operator command can drive the robot through its safety envelope, that independence is nominal and the bounded-controllability argument fails at its most important point, which is why safety_function_override_by_remote is a distinct field. Coverage: OEM-attributable vectors trigger the OEM data-agreement indemnification; intentional third-party attack (network or credential) sits under the cyber endorsement with sublimit and a security-hygiene condition precedent.
6.3 Layer 3. Trust, safety, and readiness
Maps the constitution to auditable acceptance criteria and acts as the underwriting gate.
- Regulatory compliance. Binary gate: certification as applicable; non-certified systems ineligible.
- Functional safety integrity. Verification of required performance levels, and, for teleop, that safety functions cannot be overridden by the control layer (Article III, §5.2.8.3).
- Change governance. OEM release process satisfies Article VI; parallel evidence from the teleop platform for interface, latency-compensation, and assignment-logic changes.
Behavioral Learnability Profile (BLP). A composite measuring how predictably a configuration's behavior can be modeled. Its central hazard is scoring real-world behavior against laboratory-certified parameters, a deployed robot legitimately diverges from its test envelope (more protective stops in a busier aisle) without that indicating risk. The BLP therefore scores against three references, each catching what the others miss:
- Absolute safety bounds: certification (class, FMPM, speed, performance levels) and the §3.1 dynamic envelope; violations are signals in any environment.
- Peer deployment population, the same-model distribution in comparable environments; twice the peer median is a signal, twice the laboratory rate in a busier site is not. This prevents penalizing legitimate adaptation.
- Longitudinal fleet trend, the model line over time, because peer scoring is blind to correlated drift: a shared latent defect makes every unit look normal against its uniformly-affected peers. Slow fleet drift below the absolute bound is visible only longitudinally, the Article II hazard as a measurement requirement.
Candidly, the BLP is weakest at first-of-model deployment, where it is most needed: the peer and trend references require an installed base (~20–30 comparable units; several months of series), so the first deployment falls back to absolute bounds and pre-deployment test data, reintroducing the very laboratory bias the peer reference removes. Premium uncertainty loading is correspondingly higher at cold start and decreases as the references populate. For teleop, the BLP adds an operator-cohort dimension on the same three-reference logic.
Teleop readiness criteria.
- Network quality floor: mean RTT ≤ 150 ms, P95 ≤ 300 ms, jitter ≤ 50 ms, packet loss ≤ 0.1% for collaborative-workspace operation; above the floor, coverage only at higher premium with a reduced workspace.
- Operator certification: current certification matched to task-complexity tier.
- Session limits. ≤ 4 h continuous, ≥ 30 min break, ≤ 8 h per 24 h, verified by platform logs.
- Ratio limits. Tier 1 (fine manipulation) ≤ 1:2; Tier 2 (standard pick-and-place) ≤ 1:4; Tier 3 (passive monitoring) ≤ 1:8; above tier requires endorsement and specific controls.
- Interface and transition documentation: camera coverage, resolution, frame rate, haptic feedback, latency compensation; written autonomous↔teleop handoff protocols.
Field monitoring. Network-quality dashboard, operator incident rates by tier, transition incident rates.
6.4 Layer 4. Operating and legal structure
Described only insofar as it shapes the technical architecture: Boop operates as a managing general agent: delegated authority, fronting paper, loss exposure ceded to reinsurance. Two features are load-bearing. The reinsurer requires poolable, comparable, tamper-evident loss data, which is the constraint producing the three-layer PAIDS separation (§7): the reinsurer needs Layers A and B; the OEM cannot expose Layer C. The OEM relationship is the data-access and change-governance mechanism that obligates PAIDS reporting and the Article VI timelines, without which Layers 1–3 have no inputs; for teleop, an equivalent platform relationship supplies operator-session and network data. Commercial terms are out of scope here.
7 · The incident standard (PAIDS)
PAIDS is the standard in which incident data is recorded, stored, and shared, at once the underwriting layer, the claims input, and the cross-OEM safety knowledge base. The on-robot program that produces PAIDS records is RDR, the Robot Data Recorder, and its lineage is deliberate. Aviation has the flight data recorder; the automobile has the event data recorder. Each made incidents reconstructible, and in doing so made its technology safer, more accountable, and more insurable as it scaled, clearing the path to mass adoption. RDR is that instrument for physical AI.
RDR is software only. It ships as a signed, read-only container that runs on compute the robot already carries — not a separate hardware module, dongle, or onboard appliance. The aviation and automotive analogies refer to the function (making incidents reconstructible), not to a physical black box you mount on the robot. In diagrams it may appear as a box in the stack; that box is a process boundary, not a device SKU.
PAIDS separates Layer A (measured fact, OEM/platform-generated, signed, unedited), Layer B (Boop-derived classification), and Layer C (legal outcome, never shared with OEMs in identifiable form). This separation is what lets an OEM sign, participation cannot become a standing liability admission, while still giving the reinsurer poolable fact.
Two design decisions determine whether the record can actually support reconstruction. Resolution is declared, not mandated: a safety controller's logging rate is fixed at manufacture and certification and cannot be retrofitted, so OEMs declare native per-channel rates in Phase 0; coarse logging is not non-compliant but carries a higher attribution-uncertainty load, matched to the physics of each event class (a PFL contact, 50–200 ms force rise, wants ~100 Hz on force; an SSM violation, ~500 ms approach, ~50 Hz on position; a protective stop, 10–50 ms, high-rate safety-controller logging). Two time structures, not one: a high-rate window captures the mechanical event, and a low-rate session-length trend captures the human-factors signal, because fatigue and complacency are session-scale and invisible to a 30-second window.
7.1 Required fields. Layer A
| Group | Field | Meaning |
|---|---|---|
| System | robot_model_id, unit_serial | OEM model; hashed unit id (OEM retains mapping) |
firmware_version, safety_config_checksum | Operative software; §5.3.5 config checksum | |
robot_class, fmpm_rated, max_speed_rated | Per §5.1.17; rated force (N); rated speed (mm/s) | |
com_height_m, total_mass_kg | Bound fall potential energy (bipedal systems) | |
declared_sampling_rates | Native rate (Hz) per safety channel, from Phase 0 | |
| Control mode | control_mode | Full autonomous / supervised autonomous / assisted teleop / full teleop / autonomy-teleop fallback / control transition |
control_mode_transition_preceding (+ direction) | Transition within 60 s before incident, and its direction | |
| Context | incident_timestamp | UTC, ms precision |
deployment_environment | Industrial caged / industrial collaborative / logistics / service / domestic / other | |
collaborative_operation_mode | SRMS / hand-guided / SSM / PFL / non-collaborative / transition / unknown | |
humans_in_workspace, operator_present | Booleans (operator local or remote) | |
| Event | event_type | Protective stop · emergency stop · transient contact · quasi-static contact · stability event · fall · near-miss · hardware / software / sensor fault · override attempted · cyber anomaly · OTA update · teleop handoff · other |
event_trigger | What initiated the event | |
event_window_highrate | High-rate series spanning the mechanical event (length/rate per event class) | |
event_perception_snapshot | Video / depth / lidar frames for a declared pre/post window; minimized at source, biometric identifiers excluded; raw frames held in Tier 0 by reference | |
session_trend_lowrate | Low-rate series spanning the full session/shift, human-factors and slow-drift signal | |
safety_function_override_attempted (+ by remote) | Override attempt in prior 5 min; whether a remote operator was the source | |
ota_update_preceding | OTA in prior 72 h (boolean + interval) | |
| Stability | balance_recovery_activated, zmp_margin_min | Recovery engaged?; minimum stability margin |
payload_mass_kg, payload_velocity_envelope, floor_condition | Dynamic component; nominal / wet / uneven / obstructed / unknown | |
| Teleop | teleop_session_duration_minutes, teleop_operator_to_robot_ratio | Session length; robots supervised |
teleop_operator_certification_tier, teleop_platform_id; teleop_operator_anonymous_id | Tier 1–3; platform id; hashed operator id (platform retains mapping) | |
teleop_latency_rtt_mean / _p95 / _jitter / _packet_loss | Latency profile, prior 60 s | |
| Contact | contact_type, contact_body_region | Transient / quasi-static; Annex A body region |
measured_force_N, estimated_force_N, pfl_limit_active_N | Measured / reconstructed force; active PFL limit | |
| Severity | severity_grade | 0 (near-miss) … 5 (fatality / permanent disability) |
| Root cause | root_cause_category | Hardware · software · sensor · configuration · loss of balance · local / remote operator error · credentialed-operator compromise · platform failure · network quality · environmental · cyber (vulnerability / supply chain / network) · unknown · under investigation |
8 · The incident corpus as a dual-use asset
The PAIDS corpus has a second life that does not depend on a single claim ever being filed. The robot foundation models now entering physical deployment, the vision-language-action and world-model systems that govern perception and behavior, are trained overwhelmingly on demonstrations of success, because failure on real hardware is dangerous, expensive, and hard to reset; the field has resorted to synthesizing the failures it cannot afford to observe. A recorder operating at fleet scale across many OEMs collects the scarce thing directly: a provenanced, labeled record of what robots actually do wrong in the world.
The instrument that makes physical AI insurable makes it learnable from its own mistakes, a feedback loop the flight data recorder never had, because an aircraft cannot be retrained on its near-misses and a robot can.
The corpus is usable as training and evaluation data for the same reason it is poolable for reinsurance: the layer separation. Layer A is the measured trajectory, proprioception, contact, and the high-rate window around the event, which is precisely the observation-and-action stream the open robot-learning formats already consume; the LeRobot dataset format, the de facto interchange spanning manipulator arms, bimanual cells, humanoids, and simulation, is its natural container. Layer B supplies the labels, event class, the severity grounded in §3.1, and the contact and attribution structure, that turn a raw trajectory into a supervised example of a hazard. Layer C, the legal outcome, never travels. An incident leaves the fleet as an authenticated, labeled, embodiment-tagged episode: a negative demonstration with a known failure mode, signed at source.
Whether this asset is legitimate turns entirely on governance, and the constitution already constrains it. Article VII permits the collection only of what safety and operation require and protects bystander data; Article V requires that records be tamper-evident and reconstructible. Secondary use therefore proceeds under the same consent and provenance regime as the primary use: the OEM's measured facts remain the OEM's, scoped by tenant and never resold as raw intellectual property; Layer C is never included; and licensing is structured through the operating entity (§6.4) with value returned to the data's originator. The framing is not that the insurer monetizes an operator's mishaps, but that PAIDS converts an unavoidable byproduct of deployment into a governed, attributable asset the originator controls, one whose resulting safety models reduce the very losses Boop underwrites.
Two honest limits bound the claim. The value is in safety, evaluation, and failure-aware learning, failure detection, recovery, reward modeling, and the edge cases world models cannot generate convincingly, not in transferring a manipulation policy across bodies, because a fall on one morphology is not a fall on another; cross-embodiment incident data is a taxonomy and a benchmark before it is a policy. And realizing it requires the capture to carry the full sensory window, held by reference in Tier 0 rather than reconstructed after the fact. The standard's contribution is to make incidents interoperable at all: PAIDS should define the canonical mapping from a record to the training-and-evaluation formats, so that what one fleet learns the hard way is available, under license, to every model that must not repeat it.
9 · The underwritability frontier
Every insurance system has a frontier where risk transfer breaks down; physical AI adds a distinctive one, the risk itself becoming unmeasurable, and therefore unpriceable. It is useful to treat underwritability as a spectrum of regimes rather than a binary, each with its own risk-transfer instrument.
Regime 1. Certified, in-scope systems (fully underwritable). Robot certified to the applicable standards, operating within its certified environment, with PAIDS-compliant telemetry and a stable BLP. The cold-start prior is parameterized from engineering data, credibility accrues normally, and incidents attribute with reasonable confidence. Standard MGA economics apply; this is the initial market.
Regime 2. Extended-environment systems (underwritable with loading). A certified robot operating in an environment adjacent to but not identical to its certified scope, logistics with unpredictable foot traffic, a service setting with public access, a construction site. The residual risk is higher but structured, priced through environmental loading factors, with the BLP supplying the field evidence that a given deployment performs within the expected envelope for its environment class.
Regime 3. Rapidly evolving systems (underwritable with governance). Capability expanding through frequent updates faster than the credibility cycle can track. The risk is quantifiable but the insured object is moving; the instrument is Article VI governance, advance notification, staged deployment, and extended post-update telemetry windows that let the model recalibrate, with premium floating against the BLP update-response signal during the window.
Regime 4. Genuinely self-modifying systems (at the frontier). Behavior changing without external review, through in-deployment learning rather than a governed update. ISO 10218-1:2025 §5.3.5 prohibits exactly this during automatic operation, which is why a system that does it anyway is not insurable under the standard structure. Three instruments apply at the frontier: a parameterized behavioral envelope, certified at inception and monitored continuously, whose breach triggers escalation and possible suspension whatever the cause; structured reinsurance with an explicit self-modification provision that activates the OEM indemnity and caps reinsurer liability at a sublimit; and a small, separately capitalized residual-risk pool, funded from profit commission, the honest reserve any insurer of novel technology holds against the unknown.
The teleop frontier differs in kind. As deployment moves from full teleop toward exception-handling supervision, the human backup is real only if alert and able to intervene, and the §4.3 evidence says that capability degrades predictably as engagement falls and ratios rise. The frontier is reached when the model assumes a backup the operating conditions make fictional: Boop's ratio and session limits are therefore eligibility conditions, not premium levers: above them the coverage would price a fiction, and Boop declines regardless of premium.
The certification horizon. ISO 10218-1:2025 is already applied to systems its authors did not design it for, and the teleop gap (§3.3) will be addressed: Boop should bring PAIDS-derived evidence to ISO/TC 299: the certification framework is the underwriting baseline, so keeping it current is a core function, not a compliance task.
The structural limit. A system, or human-robot system, that harms at a rate, severity, or scale that cannot be anticipated or priced is a deployment problem, not an insurance problem. The readiness gate and the frontier are the same boundary from two sides: the condition a system must meet to be insurable, and the condition at which it ceases to be. Between them is the market: Boop's wager is that whoever prices this risk is necessarily whoever holds the clearest picture of how it behaves, at once a moat and a public good.
10 · Open questions
- Teleoperation standards. When ISO/TC 299 acts, how must Boop's criteria adapt? The data agreements should include a change-of-law provision.
- Humanoid dynamic-hazard severity. The fall and loss-of-balance model has no certified standard analogue and needs field calibration.
- Real-time complacency measurement. Population-level complacency is established; whether it is measurable in individual operators from telemetry in time to act is open and actuarially valuable.
- Cyber liability allocation. §5.1.16 creates a duty but no liability rule for a compliant robot that is compromised; the teleop link widens the surface.
- Non-industrial environments. ISO 10218 is industrial by scope; domestic and service deployment lack a pricing evidence base.
- Attribution boundaries. The OEM/integrator and OEM/platform/customer lines need explicit treatment in the causal and subrogation framework.
- Secondary-use data rights. The incident corpus of §8 is bounded by Article VII and the Layer C boundary, but the licensing terms for training and evaluation use, consent scope, the value returned to the originator, and the line between an OEM's measured facts and a poolable safety asset, are unsettled; as with the teleoperation data agreement, the contract is the lever.
Working with physical AI and want to talk through the architecture, coverage, the RDR, or PAIDS? We'll walk your team through it.
Talk to us