We claim nothing. We align with a great deal.

Verify once offline, enforce continuously: the industrial norm

Our architecture is sometimes read as a shortcut: validate the envelope once, then let an unreviewed program run inside it. It is the opposite of a shortcut. It is what functional safety has required for decades.

ISO 10218-1:2011 devotes an entire top-level clause to verification and validation, and its clause 6.3 is titled, in the standard's own words, "Required verification and validation."¹ Stopping performance is not asserted but measured, under a normative annex. There is demonstrably no path through that standard to production without documented pre-use validation.

What the runtime monitor does is enforce a conclusion reached offline. It does not replace the reaching of it, and arguably no vendor's monitor does, including the certified ones.

The vocabulary we adopt

We did not invent a policy language. Certified servo drives already implement a set of safe-motion functions, and we use their names because our envelope checks are the same ideas applied to an agent-generated command stream.

These names are drawn from IEC 61800-5-2, which defines safe-motion functions for adjustable-speed drives. We reference the function vocabulary, not specific clause numbers, because we have not obtained that standard's text and would rather say so than cite a clause we have not read.

Two design requirements we took directly from the standards

A scalar limit is not conformant on its own

ISO/TS 15066 states in a normative note that a speed limit monitoring only the tool centre point "does not monitor other parts of the robot that might pose hazards to the operator," and that joint speed monitoring may also be needed. The standard says so explicitly, in its own normative text.² A second note observes that force limiting may only be effective below a speed limit, so functions must combine.

Our monitors are therefore multi-point by construction. The vendors generally did the same: ABB supervises tool centre point, elbow and wrist together, and Universal Robots extended pose limits to include the elbow.

Check the predicted stop, not the present position

A drone not currently in collision is still unsafe if it is approaching an obstacle too fast to stop.³ The constraint set is not the safe set, and a monitor that clamps at the last instant can be both too late and destabilising.

FANUC's Dual Check Safety solves this by checking a predicted stopping position derived from measured stopping data. Universal Robots made the same move between generations, from "exceeding a limit causes a stop" to "limits will not be exceeded." We follow that precedent rather than inventing an alternative.

Configuration integrity is itself a safety requirement

A monitor is only as trustworthy as the parameters it enforces, which is why the certified systems protect their configuration with checksums and signed acceptance records. FANUC gates changes behind a code number and a CRC signature that a safety controller can latch and interlock against. ABB moves a configuration through validated and locked states, with the checksum printed in a signed report.

Endstop carries the same discipline: the capability table and envelope thresholds are checksummed and signed, the value is readable externally for interlock, and a configuration change is a signed event in the audit record. This is not novelty. It is meeting an existing expectation.

What we align with, claim, and refuse to say

• Align with

  IEC 61800-5-2 function vocabulary · ISO 13849-1 category 3 / PL d architectural patterns, dual channel and cross-monitored · ISO 13855 latency accounting · ISO 10218-2:2025 cybersecurity provisions

• Claim

  Machine-checked memory isolation and absence of undefined behaviour in the interpreter core. Fuel-bounded termination. A complete, enumerable effect vocabulary. A signed, replayable audit record.

• Do not claim

  No certification of any kind. Not a safety component under the Machinery Directive. No performance level, no SIL. No proof that a validated envelope is the correct envelope for your application — that is a risk assessment, and it is yours.

Certification, honestly

The path we intend, in order, with no pretence that any step is complete:

1. Pilot deployments on uncertified research platforms, claiming nothing, gathering evidence.
2. Assessment of the enforcement core alone — deliberately excluding the admission logic, since a failure there denies rather than permits — against IEC 61508 and ISO 13849.
3. For aerial applications, flight-termination compliance is a nearer and cheaper wedge than industrial certification, because independent override hardware is already an accepted category there.