Watch a crash
get refused.
A deliberately terrible controller — a tailgater that floors the throttle straight at the car ahead — is made safe without changing the controller. The floor doesn't argue with it, retrain it, or improve it. It sits in the path between the proposed action and the wheels, and it refuses to execute the unsafe one. The controller still wants to crash. The car simply never does.
Perslis is not the driver.
It is the brakes.
Perslis is the safety and control harness between probabilistic intelligence and actuation. A planner — any model, yours or ours — may propose “change lanes” or “accelerate”. A deterministic layer then decides whether that action is admissible given the current state, the constraints, the permissions, and the safety invariants. If it is not, it never reaches the actuator.
The model cannot bypass the floor.
Every command passes through the admission layer before actuation; there is no side channel to the actuator. A hostile or broken planner is exactly the test.
Unsafe commands are rejected deterministically.
Same state, same command, same verdict, every time — with a receipt naming the invariant that fired. Not a probability, not a policy: a rule you can read.
Insufficient confidence or state → a known safe state.
When the world state is stale, the sensors disagree, or the planner's confidence drops below the bar, the floor does not guess: it drives to the defined fallback — slow, stop, hold.
Models can drive. We're building the brakes.
Read the full explanation — every step from proposal to actuation →
The upsell is simple: bring your model, add the brakes. Capability stays yours; admissibility, refusal and the safe fallback become a verified layer under it, with an audit trail.
Toggle the shield.
Watch the outcome flip.
Below is the Drive Floor, running live in your browser. Flip it OFF and you get exactly the crash the tailgating controller is asking for — it closes the gap and rear-ends the lead car. Flip it ON and the same controller, unchanged, is held to a safe following distance the whole way: the shield brakes hard enough, early enough, that the gap can never collapse — and it writes a receipt for every refusal.
This is a longitudinal model of the real drive-floor invariant safe_gap = max(min_gap, speed·headway) with a reachability-aware brake: the floor doesn't wait until it's too close, it projects the gap forward and brakes now if the projected gap would ever fall below the minimum. In the full MetaDrive run, this same tailgater crashed with the floor off and drove the entire highway safely with the floor on — 164 brake-overrides, zero collisions, controller untouched.
Three constraints.
They compose.
The floor governs the car through a small set of grounded invariants. None of them care what the controller is or how it decided — each simply constrains the action before it reaches the wheels, and they stack:
On-road
The car must stay within the lane and road boundary. A proposed steering command that would leave the drivable surface is replaced by a corrective steer that keeps the vehicle on-road. The controller can want to drift off; the floor won't let the wheels.
Speed limit
Throttle is capped so velocity never exceeds the posted limit for the segment. A flooring controller gets its command CLAMPed down to the fastest admissible value — never the fastest requested one.
Following distance
Reachability-aware, and the sharp one. The floor projects the gap to the lead vehicle forward over the stopping horizon and brakes hard enough now that the projected gap can never fall below safe_gap = max(min_gap, speed·headway). Not "we're too close" — "this action guarantees we couldn't stop." That's a DENY, replaced by a brake.
Composition
Invariants don't take turns. On a curve approaching a slow lead car, the on-road steer, the speed cap, and the following-distance brake all apply to the same command at once — the admitted action is the intersection of every safe set, not a priority list where one rule wins.
The failure is the invariant,
not a lucky catch.
An honest safety test can't rely on a rare, convenient failure that the floor happens to be watching for. So the adversaries are built to attack the exact channel the floor governs. The Tailgater corrupts longitudinal control — it drives the following-distance invariant to failure on purpose. The Drifter corrupts lateral control — it drives the on-road invariant to failure on purpose. Each adversary's whole job is to violate one specific safe-set boundary, so if the car stays safe, it's the floor holding that boundary and nothing else.
If the floor can't contain an intentionally terrible controller, there's no reason to plug in a sophisticated one.
That's the point of testing against the worst possible driver rather than a good one. A good controller might stay safe on its own and tell you nothing about the shield. A terrible one, aimed squarely at the invariant, isolates the safety authority: what's keeping the car alive is the floor, provably, because the controller is doing everything it can to kill it.
Safety without touching
the controller.
The floor turned a crashing controller safe — without changing the controller.
That's the whole thesis of the Drive Floor, and of Perslis Motion generally: the safety case does not rest on the intelligence being good. You can swap the driver freely — a random policy, a rule-based ADAS stack, a local model, a frontier model, a full autonomy stack — and the floor is unchanged, because it only ever governs the action at the actuator, never the mind that proposed it. Verified before acting, every time.
What this is,
and what it isn't.
This is a simulation demonstration of the architecture — the live demo above is a longitudinal model, and the full run is in MetaDrive, a driving simulator. It is not a control system for real vehicles. A real deployment would need verified perception feeding the invariants: the floor is only as trustworthy as the state it's given, and turning "the gap to the lead car" from a simulator's ground truth into a sensor-derived, uncertainty-aware estimate is its own hard, safety-critical engineering problem. What the demo proves is the architecture — that a runtime shield can contain an actively hostile controller — not that this specific code should drive a car.