Physical Rules
Program machines the way you describe work: when this happens, if these conditions are true, do this. A deterministic operating layer between intelligence and physical machines — demonstrated on a simulated warehouse floor.
AI can understand the world. Rules decide what happens. Robots execute it.
The problem
Programming physical automation today means either brittle low-level scripts a supervisor cannot read, or handing an LLM the controls and hoping. Neither survives contact with a real floor: the scripts cannot express "if this happens and these things are true, do this," and the prompt cannot be audited, replayed, or trusted with a safety stop. What is missing is the layer in between — where a person describes policy, a deterministic engine owns every decision, and AI is confined to interpretation.
AI outside the control loop
AI appears at exactly two boundaries — compiling instructions into inspectable rules, and interpreting ambiguous sensor information into labeled observations. Everything between an event and an actuator is deterministic, evaluated by the same rule engine that runs this site's Workflow Engine.
Natural language ──AI──► Rule proposal ──validation──► Rules Sensor ambiguity ──AI──► Observation ────────────────► World State
The control loop
Sensors / Events
│
▼
Append-only Log ◄───────────────┐
│ │
┌──┴────────┐ │
▼ ▼ │
World Execution │
Projection Projection │
└──┬────────┘ │
▼ │
Rule Evaluator │
(shared engine predicates) │
▼ │
Action Intent │
▼ │
Scheduler │
┌──┴─────────────┐ │
▼ ▼ │
Sim Capability Future Adapter │
│ (ROS / PLC) │
└──► New observations ───────┘What the demo proves
A package falls; a rule you can read fires with every input it considered recorded; persistent intents schedule against the one robot; each action starts and completes on a virtual clock. The whole decision is appended facts — no model involved.
You describe behavior in ordinary language. The model proposes rules in the closed vocabulary — closed triggers, closed predicates, closed policy-level capabilities — and nothing executes. You inspect the compiled policy, activate it deliberately, and then watch a machine follow it. A proposal that leaves the vocabulary is rejected whole, never repaired.
A worker steps into the safety zone mid-pick. The SAFETY-tier rule's decision suspends the in-flight action before anything lower-priority may start — recorded with the causing event and the rule. Safety is the top tier of one generic priority mechanism, not a special-case branch.
Drag the scrubber and any moment of the run reconstructs — world state, cause, and rule — replayed in your browser from the served log with the same fold the server runs. Replayable physical automation is a property of the system, not a demo trick.
Capabilities
- —Behavior as rules: WHEN an event occurs, IF deterministic conditions over the world hold, THEN request policy-level actions — evaluated by the same closed predicate engine that runs the Workflow Engine, with every evaluation (fired or declined) recorded with the inputs it read
- —An append-only event log as the only truth, folded into two distinct projections — physical world state and execution state — so a command/telemetry discrepancy is representable, and any moment replays from facts
- —Actions as persistent intents, not function calls: deterministic identity per decision, scheduling against capability availability, and visible WAITING with a named blocker when the robot is busy, held, or charging
- —Preemption as a generic priority mechanism — SAFETY over CONTROL over NORMAL over BACKGROUND — where a safety stop is the top tier suspending in-flight work mid-motion, never a special-case branch
- —Natural language compiled into policy: a model proposes rules in the closed vocabulary, the proposal is validated and inspected, and nothing executes until a person activates it — AI outside the control loop
- —AI as a sensor: ambiguous detections trigger inspection, the model interprets a textual sensor report into a labeled observation, and the deterministic rules take it from there — with labeled fixtures when the model or budget is unavailable
- —A strict capability contract (plan/execute) beneath the rules, so today's simulated warehouse executor and a future device adapter are interchangeable backends the rule layer never sees
Claims, graded
Implemented & demonstrated
Everything the demo executes is the real runtime: the Workflow Engine's deterministic predicate evaluator pointed at physical state, a closed first-class event taxonomy in an append-only log, world and execution projections provably rebuilt by replay, persistent action intents with deterministic identity and visible blocking, generic priority preemption with open-ended safety holds and requeue-on-resume, the strict plan/execute capability contract, live model compilation and sensor interpretation under the site's shared daily AI budget with labeled fixtures and visible rejections, and a browser that replays the served log itself.
True, but scoped to a demo
The warehouse is a simulation: capabilities mutate simulated state on a virtual clock, one robot exists by design, runs are per-visitor and expire after 24 hours, and visitor rules are capped at five per run at NORMAL priority or below.
Deferred, and labeled in the product
Real device adapters (ROS 2, PLCs, simulators) behind the capability contract, camera-frame vision instead of textual sensor reports, multi-robot coordination with its own class of concerns (allocation, leases, collision, reassignment), and telemetry-vs-command discrepancy detection — the two-projection model exists so that last one has somewhere to live.
Not claimed
This is not a certified safety system, and no physical hardware is controlled. Real robot safety runs on hardware interlocks and certified controllers; application-layer rules like these sit above that layer, never instead of it. Also not claimed: physics simulation, learned policies, or production deployment on a real floor.
Limitations, stated
- ·The warehouse is simulated. Robot motion in the demo is presentation tweening between server-decided waypoints; the decisions are real, the physics is not.
- ·Time is virtual: action durations are planned constants, not measured dynamics.
- ·One robot, deliberately — resource contention renders as a WAITING intent naming its blocker rather than a second robot appearing.
- ·"Vision" v1 is model interpretation of a fabricated textual sensor report, disclosed as such in the demo; camera frames are an extension, not a current capability.
- ·The safety beat demonstrates priority preemption in an application-layer runtime. It is not a certified safety system.
- ·When the model is unavailable or the site's daily AI budget is exhausted, compilation and interpretation fall back to labeled fixtures — visibly, never silently.