It keeps learning. It never learns its way past your rules.
One brain. Multiple platforms. A tank brain trained in BZFlag and dropped into Atari BattleZone beat the rules written for that game by 17% over 80 seeds. So far that transfer is proven only between those two tank games, and it is not automatic: a second export only broke even. It needs no network, no cloud and no data center, and it learns from its own failures on the spot.
Whatever is driving — a model, a script or a person — proposes a move. The floor decides whether that move is allowed before anything happens, and writes down why. You and your chain of command set the rules; nothing it learns can loosen them.
The same chain, every job
screen / sensors → facts → ALLOWED MOVES → mission goal → pick → memory → act
▲ │
└────────── every refusal, with its reason ──────┘
Only the first step changes from one job to the next: how it reads the world. Between Atari games that is literally true, and a code dependency shows it, not a diagram: freeway-floor imports invaders_floor.failure_memory unchanged. The wider domains — CARLA vehicle state, Doom frames, case law, genomic variants — each build the same chain separately. They share the rules of the road, not one program.
That is also why the same brain can move to a new vehicle. A tank brain trained in BZFlag was moved into Atari BattleZone and scored 33,575 against the native rules’ 28,600 over 80 seeds. A second export only broke even on fresh seeds. Moving a brain does not always pay, and we say so.
It never sees the moves it isn’t allowed to make
Before anything is picked, the floor works out the list of moves the machine is allowed to make right now. We call that list the admissible set. Most safety layers sit after the decision and veto it. This one sits before: whatever is driving never sees the moves that are off the table.
Veto after the fact
The driver commits to a move, a checker says no, the driver tries again. No limit on how long that takes, the driver can get boxed into a corner, and the “no” carries no reason it can use.
Off the table first
The bad option is gone before anything is picked. One pass, a known time limit, and when the floor removes a move it names the danger it is guarding against and cites the events that earned the rule.
Autonomy that accumulates operational experience: it stops repeating what got it hurt. A learned rule reads like this: died 13 of 19 times here, 3.6× the base rate. One unlucky death is not a lesson; the evidence has to beat the base rate before a situation becomes a rule. Learning can take moves off the list or reorder them. It can never add one back — that is proved (Theorem 1 in Fail-First Models), not promised.
A rule that cannot name a danger is refused when it is built. “Nothing bad happened here” can line up with deaths by pure chance and still be superstition. Refusing that at the start is cheaper than explaining it after an incident.
No network needed. Comms down, same answer.
Built for contested, degraded, and rapidly changing environments — that is the design goal; so far it has only been exercised in games and simulation. There is no neural network in the loop. The runtime holds no weights and makes no call to a model. It runs on the machine itself, offline — no cloud, no data center, no link to anything. If comms are jammed or cut, it keeps deciding exactly the way it did before. There is no vendor who can throttle it, reprice it or switch it off next quarter, and nothing has to go back to a depot or a contractor to be retrained: its memory is a table you can open and read, and it learns from its own failures where it is.
Same situation in, same decision out, every time. That is what makes the log in chapter 5 worth anything for an after-action review: replay any decision and you get the same answer and the same written reason. A safety layer you cannot replay is a safety layer you cannot check.
The executor is 303 lines of standard-library Python. Download it and read it →
Who stays in command
If a machine on your team hurts a friendly, the first two questions are: what was it allowed to do, and why did it do what it did? The floor answers the first. The written trace answers the second. That is the reason this layer exists.
You and your chain of command set the rules. The floor is the part that holds the machine to the version of those rules it was given — and nothing it learns can loosen them. Put exactly: people set the authority, the orders and the ROE; the floor is the fixed, deterministic mechanism that enforces machine-readable limits derived from authorized policy, mission rules, safety limits and applicable ROE. So far it has only ever been given game and simulation rules. No real ROE has been loaded or tested.
US policy, DoD Directive 3000.09, Autonomy in Weapon Systems, requires autonomous and semi-autonomous weapon systems to be designed so commanders and operators can exercise “appropriate levels of human judgment over the use of force.” It also calls for realistic test and evaluation, system status operators can understand, clear procedures to turn the system on and off, safety mechanisms, and use consistent with applicable law and ROE. Perslis is being built toward that framework. It does not claim to meet it.
Adaptive autonomy. Fixed authority. Long-term validation includes combat-capable humanoid platforms under human command. Perslis is being developed so that learning may change strategy and operational knowledge without silently expanding the system’s authority.
The road, step by step: simulation → hardware-in-the-loop → low-cost robots → a humanoid robot-boxing testbed (sanctioned robot against robot; the testing and fundraising stage) → combat-capable humanoids under human command. Only the first step exists. Everything past simulation is not built yet.
Next
Chapter 2 — what we actually measured, including where it failed →