Our certification route, the evidence for it, and the next decisions

What IEC 61508-3 already decided

Table A.2 rates architecture and design features by integrity level. R is recommended, HR highly recommended, NR not recommended. Five entries land on decisions already made here. Ratings are at SIL 2, our target.¹⁵

Entry 5 decides the argument. Putting a language model inside the safety function requires a technique the standard marks not recommended at every level above SIL 1. Move the model out and entry 3c is what remains.

Table A.2 selects techniques and awards no level. An assessor reads the lifecycle, competence and configuration-management record long before any architecture table.

The claim ledger

• Align with

  IEC 61800-5-2 function vocabulary · ISO 13849-1 categories and diagnostic coverage · ISO 13855 latency accounting · ISO 10218-2:2025 cybersecurity provisions

• Target, not yet met

  Suitable for use within a defined PL d / SIL 2 safety function, subject to the system architecture, diagnostics, application validation and assessment. §4 has the preliminary arithmetic.

• Current software evidence

  Machine-checked memory isolation and absence of undefined behaviour in the interpreter core. Step-fuel-bounded termination and pre-execution timing-credit accounting; the target-specific cost table remains provisional and operational timing admission is disabled. An enumerable program-facing effect vocabulary. A bounded capability journal with an Ed25519 seal when the program requests one, demonstrated in emulation with a published verifying key. Trusted-side per-verdict recording, durable chaining and periodic sealing are not implemented.

• Not yet claimed

  Endstop is not yet certified and does not currently carry a performance level, SIL or CE mark. Software and RTL tests exercise the configured envelope in disclosed cases; deciding whether that envelope is appropriate for a specific application remains part of the integrator’s application-level risk assessment.

What the design takes from the standards

The envelope checks carry IEC 61800-5-2’s names for safe-motion functions, because certified drives already implement them: safe torque off is the state we degrade to, safe stop 1 the ramped abort, safely-limited speed and position the per-axis, Cartesian and keep-out ceilings, safe direction the per-mode constraint.

The names are wider than what we may assert against them, and the difference is measurement. A rated safely-limited speed or position function watches an encoder, and the reference Category 3 architecture takes two of them into a safety PLC. The pilot takes none wired to the gate. The command monitor's only input is the proposed joint command, so what it enforces is a ceiling on what can be commanded, which is a weaker thing than a supervised limit on what the machine does. Two of the other names narrow for the same reason. Safe operating stop is the drive holding position under full torque, which is the hold-last state we treat as unsafe, so it is ruled out by our own policy. Safe stop 1 is available in its time-based form only, because we command a deceleration and do not verify one. The relay in series with drive power demonstrates what safe torque off is for, and a rated STO would need an architecture, diagnostics and a PL or SIL calculation that we do not claim. So the honest reading of every name in the paragraph above is that we enforce it on the command channel, which is the half of the function that sits between a model and a machine.

Closing that gap needs an independent measurement of the machine's state — an encoder tap, a potentiometer or a current sense, wired to the gate and not through the host. We now have an implemented feedback supervisor, exercised against the open-source arm simulation, that checks direct snapshots for freshness, measured position/rate and following error, separately from the command monitor. Freshness derives from the capture block’s monotonic sample sequence, not a host-provided flag. It does not run a second forward-kinematics pass. The PC-assisted arm rig reads the SO-101's own encoders, but through the trusted PC rather than a direct tap, so it does not close this gap. The physical capture hardware, timing bound and end-to-end verification remain open. Until they exist, what we can say is what a supervisor vendor already says: the untrusted program could not command outside the envelope. Whether the arm then went there is a question this gate does not answer.

Monitoring is multi-point. ISO/TS 15066 states in a normative note that a speed limit watching 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.² ABB supervises tool centre point, elbow and wrist together; Universal Robots extended pose limits to the elbow.

Configuration is checksummed and signed, and the value exposed so a controller can interlock against it. FANUC gates changes behind a code number and a CRC signature; ABB moves a configuration through validated and locked states. A monitor is only as trustworthy as the parameters it enforces.

Enforcement acts on predicted stopping position, following FANUC’s Dual Check Safety and the generational change at Universal Robots from “exceeding a limit causes a stop” to “limits will not be exceeded”. The architecture page has why that distinction matters.³

None of this replaces offline validation. In ISO 10218-1:2011 verification and validation take an entire top-level clause, clause 6.3 is titled “Required verification and validation”, and stopping-time measurement has a normative annex of its own.¹ The monitor enforces a conclusion reached offline; no certified vendor’s monitor reaches it either.

The integrity target: PL d / SIL 2, on one channel

PL d and SIL 2 are one target. ISO 13849-1:2023 Table 4 pairs them exactly and puts PL e with SIL 3.¹⁶ PL d is also what ISO 10218-1:2025 gives as the default for a protective stop.⁹

PL d does not require a second channel. Figure 12 of ISO 13849-1:2023 puts it within reach of Category 2 at medium diagnostic coverage with a high MTTF_D, and of Category 3; Category 4 is what PL e requires.¹⁶ IEC 61508-2 Table 3 draws the same boundary: a Type B element at zero hardware fault tolerance reaches SIL 2 once its safe failure fraction passes 90%, and reads Not Allowed below 60%.¹⁰

So one enforcement core is admissible on both scales. What it costs is diagnostics: DC_avg at medium and a safe failure fraction above 90%, demonstrated on the built hardware. That is work we would rather do than carry a second board.

Both ISO 10218-1:2025 figures here are second-hand: the protective-stop default, and a reported route with no architectural category requirement below 4.43 × 10^-7 per hour. We do not hold that standard.

Three regimes, and the category we fall in

A device of this description falls under three separate bodies of European law, each with its own assessor and commencement date. Confusing them is how budgets get set wrong.

The AI Act used to be a fourth. During 2026 the Digital Omnibus moved the Machinery Regulation from Annex I Section A to Section B of that Act, removing the direct application of its Chapter III obligations to machinery and folding AI-specific health and safety requirements into the Machinery Regulation by delegated act, due 2 August 2028.⁶

We expect Annex I Part B, as a logic unit to ensure safety functions, which is a named Part B category.⁴ Part A carries mandatory third-party assessment with no self-declaration route at all, and two of its items could reach us: safety components, and machinery with embedded systems, having self-evolving behaviour using machine learning approaches ensuring safety functions.

The frozen-model defence is available, and we decline it. At least one notified body reads “self-evolving” by capability rather than by timing.⁷ Our position is that no machine learning sits inside the safety function at all. The monitor is fixed, hand-written and machine-checked; the model is upstream of it and generates the programs it constrains. Both Part A items qualify the component by the phrase ensuring safety functions, and where the learned component does not ensure it, the item does not attach.

Declining that defence is the point. An exclusion argument that survives only under a favourable reading of “self-evolving” has to be re-argued every time the reading moves. Ours assumes the worst available one: that the model is self-evolving, that it will be retrained, and that an attacker controls its inputs and therefore its outputs. It is unaffected, because it never turns on what the model does. It turns on what the model can reach, which is three capabilities with the index fixed before execution starts and a 512-byte region with every access bounds-checked.

The whole argument is written out as a standalone document rather than left as prose here. It quotes the Annex I items, names the safety function in one sentence, states four separately checkable claims about what the learned component cannot do, and ends with the four findings that would change our view. It is drafted and not yet signed: the verbatim Annex I text and a counsel reading stand between it and issue. We will publish it when it is issued, because a classification argument nobody can read is worth about as much as an uncorrected claim.

The Cyber Resilience Act is the one regime where that answer could still go the other way, and we have not settled it. There, self-assessment is the default. Class I under Annex III may use harmonised standards or a third party, and industrial automation and control systems not otherwise listed are named in it, with PLCs, DCS, CNC and SCADA as the examples. Class II requires a notified body, and it names tamper-resistant microcontrollers and microprocessors.⁵ We hold a signing key, produce a signed audit trail and describe the device in terms of tamper-evidence, which invites the Class II reading. Where we land is a legal question we have not yet put to counsel, and it decides whether that regime needs a notified body at all. It is on this page because it is open, not because it is answered.

Three assessment stages, in this order

The first stage comes before selecting a certificate label. PL and SIL apply to defined safety functions and their supporting systems, not to 539 lines of software in isolation. The review must settle the safety function, channel architecture, diagnostics, hardware platform, toolchain argument and application assumptions before an assessor can agree the appropriate certification scope.

The path to certificate 1

The bring-up board is a Lattice ECP5 with an open synthesis and place-and-route flow and an open RISC-V soft core, chosen so every layer can be inspected. IEC 61508-3 requires every tool contributing to executable output to be justified, so the certified product moves to a platform with a functional-safety package. Microchip’s Libero suite was certified by TÜV Rheinland in September 2024 for the PolarFire families with data packages supporting SIL 3,¹² and lockstep safety microcontrollers carry the equivalent. Choosing belongs before the board spend.