One runtime under
every moving machine.
A car, a quadcopter, a robotic arm — the safety question is identical: given a trustworthy read of the world, is this proposed action admissible, and can we enforce that independent of whatever proposed it? The Perslis Motion engine answers it in six stages, the same way every time.
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.
It's not a rule engine.
It's one question.
The core primitive isn't a giant table of if-thens. It's a single question, asked continuously, for every candidate action a controller proposes:
Can this proposed action drive the machine into a forbidden state within horizon H?
If the reachable set over the next short horizon intersects a forbidden region — a pedestrian, a geofence, a human exclusion zone — the action never executes as proposed. That reachability check is what makes the shield actually safe rather than merely reactive: it brakes, clamps, or overrides early enough that the forbidden state was never reachable in the first place.
State → Reachability → Invariants
→ Admission → Actuation → Verification.
1 · State
A typed reading of the world: position, velocity, acceleration, orientation, trajectory, nearby objects, boundaries, actuator state. Grounding is the sim's ground truth today; a real deployment feeds it from verified perception.
2 · Reachability
Project the candidate action forward over horizon H. Which states become reachable? This is the difference between "we're too close now" and "this action guarantees we can't stop in time" — the second is what the floor acts on.
3 · Invariants
The safe set, stated as constraints: max velocity and acceleration, collision envelopes, geofence / road / lane boundaries, minimum separation, prohibited regions, actuator limits. Invariants compose — each further constrains the action.
4 · Admission
ALLOW · CLAMP · DENY · EMERGENCY. The candidate is executed as-is, tightened to the nearest safe value, refused, or replaced by a safe override (brake, hover, halt).
5 · Actuation
Only the admitted action reaches the actuator. The controller never touches the hardware directly — the floor is always in the path between proposal and motion.
6 · Verification & fallback
Every override is logged as a receipt. If state goes unknown, contradictory, stale, or sensors drop, the runtime transitions to a predefined safe behavior — it never asks the model what to do in a degraded world.
Swap the proposer.
The engine doesn't move.
Nothing in the six stages depends on what proposed the action. That's the whole point: the safety case never rests on the intelligence being good. Change the driver freely —
— and the engine is unchanged. Which is why you can build almost all of it before choosing an AI model at all.