Where the Floor Comes From: Earning a Motion Safety Floor's Invariants from the Public Failure Record

1 · The question a safety board asks first

Our earlier papers describe a runtime-assurance floor for motion: a controller proposes an action, a deterministic shield verifies it against a small set of invariants, and only an admitted or clamped action reaches the actuator. Those papers were honest about scope but silent on origin. The invariants — stay on the road, obey the posted limit, keep a speed-dependent gap, stop for what is stationary ahead — were written by engineers, and the numbers in them (a 1.6 s headway, an 8 m minimum gap) were constructor defaults. A regulator's first question is not whether the floor works in a simulator. It is: where did you get these rules, and where did you harvest your failures from?

This paper answers that question the only way it can be answered without hand-waving: by building the floor's rule set from the record. We define an invariant as earned when at least one public record of an automated-driving failure classifies into a failure mode that names it, and we publish, for every invariant, how many records earned it, from which sources, at what severity and speed, and whether our floors enforce it yet. Where a rule has a number in it, the number is derived from a measurement with the formula shown.

2 · The record

Five federal sources, all public, all downloaded as files and checksummed (Table 5). The NHTSA Standing General Order 2021-01 requires every operator of an automated driving system or a Level 2 driver-assistance system to report a crash within days; we use the archive (July 2021 to 15 June 2025) and the current file (16 June 2025 onward) for both classes, keeping the highest report version per Report ID. Part 573 recall filings and ODI investigation records come from NHTSA's flat files, selected by an explicit list of automated-driving campaigns that a keyword sweep must reproduce exactly, so a new filing fails the build rather than going missing. The NTSB reports are the five Board investigations of crashes under automation; their probable-cause paragraphs are quoted verbatim and checked against the PDF text at build time.

Table 1. The record. 5,286 records classify into at least one mode; 1,830 Level 2 filings are unclassifiable because the filer redacted the narrative and left the movement fields Unknown; 1,103 match no rule.

One gap is visible rather than silent: the California DMV's OL-316 collision reports sit behind a CAPTCHA wall and are not exposed by the site's API. The California incidents are nevertheless present, because the same crashes are filed federally under the Standing General Order with State = CA.

3 · Method: a taxonomy that a reviewer can check

A failure mode is a named way automated driving has actually failed. We define 23 (Figure 2). For crash reports the classifier reads structured fields first — the pre-crash movement of each vehicle, what was struck, which surfaces made contact, the roadway flags — and narrative keywords second, with the ego vehicle required to be the subject of any violation phrase (“stopped at a red light” is compliance, not a failure). Recalls, investigations and NTSB reports are assigned their modes explicitly, because a regulator has already adjudicated them. Every match returns the evidence string that produced it and a strength label: field, text, or regulator.

Two modes earn nothing by design and are reported anyway. A stopped vehicle that is struck proposed no motion, so no rule for the ego vehicle follows from it; and a Level 2 driver who did not intervene is a finding about human monitoring, which a floor replaces rather than enforces. Reporting them keeps the share of other-party crashes visible instead of letting it inflate the floor's reach.

4 · Results: what the record earned

52% of Level 3–5 crash reports are the vehicle being struck while stopped. That single fact reframes the record: most filed crashes are not the automated system proposing something dangerous. The rules below are earned by the minority that were.

Table 2. The invariant ledger. "Strong" = earned by structured fields or a regulator/NTSB finding; "text-only" = narrative keywords alone. Severity is the highest injury alleged in the earning crash reports.

The grid is the honest centre of the paper. 6 invariants are earned and enforced by at least one floor. 9 are earned and not enforced: STOP_CONTROL, CROSS_TRAFFIC, WORST_CASE_HEADING, BRAKE_AUTHORITY, HOLD_AFTER_CONTACT, NO_MOTION_PERSON_ADJACENT, ODD_ENTRY, LANE_DISCIPLINE, MRC_FALLBACK. Cross-traffic conflict alone has 1,047 records behind it and no check in either floor. Post-collision motion has two records, but one of them is the Cruise recall that ended a company's driverless operations.

5 · The numbers inside the gap rule

The record fixes what must be prevented and the speeds at which it happens. It does not fix a headway. That number comes from the physics of the vehicle the floor guards. The distance needed to stop from speed \(v\) with response latency \(t_r\) and sustained deceleration \(a\) is

while the floor's rule is linear in \(v\): \(\mathrm{gap}(v)=\max(g_{\min},\, v\,h)\). The linear rule covers the stopping distance exactly when

so a headway is exact at one speed and conservative below it. We measured \(t_r\) and \(a\) on the MetaDrive vehicle by driving it to 30, 45, 55, 70 km/h under full throttle and then commanding full brake, logging speed every 0.1 s: latency 0.1 s (one control step) and sustained deceleration 11.28 m/s². At the 55 km/h scenario limit the required headway is 0.78 s; the 1.6 s default covers it with margin (Figure 5, Table 3).

Table 3. Measured MetaDrive braking; every row is the same formula.

Table 4. Sensitivity to ASSUMED dry-road decelerations — not measured; the simulator brakes harder than a real car.

The caveat is in the dashed lines. A simulated vehicle that decelerates at 11.28 m/s² brakes harder than a real car on a dry road. Re-running the same formula with an assumed 6 m/s² gives a required headway of 1.37 s; at 5 m/s² it is 1.63 s and the 1.6 s default is no longer sufficient. The CARLA floor's 2.4 s covers every assumed row. The honest statement is therefore: the MetaDrive default is derived and sufficient for the vehicle it guards; for a real vehicle the headway must be re-derived from that vehicle's measured braking, and 2.4 s is the defensible starting point.

6 · What this does and does not establish

• It establishes provenance, not completeness. Every rule in the floor now cites the failures that earned it. The floor still refuses only what it models; a hazard absent from the record and from the state is absent from the floor.
• Classification is rule-based and spot-audited, not inter-rater tested. The rules are published and every match carries its evidence; we tightened four of them after audit (compliance phrases, third-party violations, justified hard braking, incidental static words). A formal precision study against human coders has not been done.
• The record is self-reported. Standing General Order narratives are written by the operators; Level 2 filers redact most of them. Counts are lower bounds on what happened, not estimates of rates.
• No hazard analysis, no real perception, no adversary. This is not an ISO 26262 or SOTIF work product; state comes from simulator ground truth; nothing here distinguishes an attacker-induced failure from an honest one.
• Simulation only. The measured braking is the simulator's. The paper says exactly where a real vehicle changes the numbers.

7 · Reproducibility

Everything in this paper, including its figures and every number in its prose, is generated from the public files by one build:

python -m failure_corpus build        # fetch → manifest → classify → derive → ledger
python -m failure_corpus.kinematics   # measure MetaDrive braking → kinematics.json
python -m failure_corpus.figures      # the five SVGs
python -m failure_corpus.paper        # this page, EN + 中文
python -m pytest tests/               # per-source, per-mode, per-invariant, per-floor-check pins

Table 5. Source manifest at build time (2026-09-27T07:00:26Z).

References

1. NHTSA. Standing General Order 2021-01 on Crash Reporting, third amended order (2025); incident report files ADS and ADAS, archive 2021–2025 and current. static.nhtsa.gov/odi/ffdd/sgo-2021-01/.
2. NHTSA Office of Defects Investigation. Recalls flat file FLAT_RCL_POST_2010.zip and investigations flat file FLAT_INV.zip; Part 573 reports 22E-016, 22E-072, 22V-037, 22V-317, 23E-029, 23E-086, 23V-085, 23V-838, 24E-013, 24E-049, 24E-067, 25E-019, 25E-029, 25E-034, 25E-037, 25E-084, 25E-090, 26E-026, 26E-035, 26E-044, 26E-059.
3. NTSB. HAR-17/02 (Williston, HWY16FH018); HAB-19/07 (Culver City, HWY18FH004); HAR-19/03 (Tempe, HWY18MH010); HAB-20/01 (Delray Beach, HWY19FH008); HAR-20/01 (Mountain View, HWY18FH011).
4. Sha, L. Using Simplicity to Control Complexity. IEEE Software 18(4), 2001 — the Simplex runtime-assurance architecture.
5. Shalev-Shwartz, S., Shammah, S., Shashua, A. On a Formal Model of Safe and Scalable Self-driving Cars. arXiv:1708.06374, 2017 — Responsibility-Sensitive Safety; the safe longitudinal distance has the same kinematic form as Section 5.
6. Alshiekh, M. et al. Safe Reinforcement Learning via Shielding. AAAI 2018.
7. ASTM F3269-21. Standard Practice for Methods to Safely Bound Behavior of Aircraft Systems Containing Complex Functions Using Run-Time Assurance.
8. Perslis Research. Runtime Admission Control on a Photoreal Driving Simulator (2026); Admissible Motion (2026). research.perslis.com.