What you get, and what you have to bring
Endstop has not been built yet. There is a design, an off-the-shelf FPGA board it runs on, and something like three months of work planned against it. What does not exist is an assembled board or a measured end-to-end timing figure, and probably will not until there is a partner to build it for. Everything below is what that would involve, on both sides.
The object
Small, dull hardware. That is a design goal rather than an apology.
A Lattice ECP5 FPGA carrying a soft 32-bit RISC-V core, clocked at 25 MHz, running out of on-chip block RAM. In-order. No speculation, no cache by default, no operating system, no allocator, no DMA, no network stack. The trusted software is roughly five hundred lines. Every one of those choices was made for the same reason: a reviewer has to be able to read the whole thing, and an attacker has to find nothing familiar.
| Interface | What it is |
|---|---|
| In, from your host | one serial line, framed messages, unidirectional in the pilot |
| Out, to your drives | PWM or step/direction, regenerated rather than passed through |
| Safety chain | a relay contact wired in series with your existing emergency-stop circuit |
| Keys | SPI secure element; the signing key never leaves it |
| Evidence out | the signed record streams back over serial for you to store |
| Enforcement | every control cycle, under 200 µs added latency |
That last figure is a projection from an instruction-level budget, not a measurement. Producing a measured one is roughly what phase 3 exists for. The pilot runs on a development board anyone can order today; custom hardware is a later problem and we are not going to pretend otherwise.
What integration looks like
A wiring change on the command path. Your stack stays as it is.
Today, whatever is doing the deciding (a VLA, a planner, something you wrote) emits setpoints that reach the drives. Endstop goes in the middle of that link. Your policy does not change and your control rates do not change. The fast loops stay inside the drive where they belong; current and velocity never traverse the gate at all.
What changes is that a setpoint now has to survive a check before it becomes motion, and that anything refused becomes a recorded event instead of a silent clamp. You should expect to spend real time on one thing: deciding what the envelope is. That is a conversation about your machine, your cell and your risk assessment, and it is generally the part nobody else can do for you.
The emergency-stop chain does not route through the gate and never will. The gate can permit motion and cannot command it. If it fails, dies, or is unplugged, the machine stops.
How an engagement runs
Four phases. The first is free and sometimes ends with us telling you that you do not need this.
- 1 · Scoping
What are you running, what does the model decide, and what is the command interface between them? Usually a couple of conversations. The outcome is a written statement of the envelope you want enforced, or a clear answer that your existing safety-rated equipment already does this, in which case we say so and stop.
- 2 · Bench
The gate on a bench with your command stream, recorded or live, against a servo rig. You get a logic-analyzer capture: an out-of-range command going in and a clamped command coming out, a step command that becomes a slew-limited ramp, a deadman timeout that reaches a safe stop. Each one carries its matching signed refusal in the record. This is the demonstration that requires you to believe no proof.
- 3 · In the loop
The gate on your platform, in the command path, not in production. Latency measured on your hardware, instead of projected from ours. This is usually where the envelope gets argued with, and where most of the learning on both sides happens.
- 4 · Evidence
The signed record, replayed off-board against the recorded state, verdict by verdict. The artifact you would hand an insurer, an assessor, or your own incident review.
Phases tend to run in weeks, not quarters. We are not going to put dates on a web page; ask, and you will get a schedule for your platform.
What you bring
Needed
A platform where a model is genuinely in the control loop. Someone who can route the command path through a new piece of hardware. And a willingness to say out loud what the machine must never do. That last one is harder than it sounds, and it is arguably most of the value of phase 1.
Not needed
Typically no change to your model, your training, your planner or your control rates. No belief in formal methods. No commitment beyond the phase you are in.
Bring realistic expectations too. Endstop is pre-certification and pre-product, and a design partner is taking on research risk. What you get for it is early access to the evidence artifact, and rather more influence over what the thing becomes than you would have later.
What we will not tell you
That we are certified. We are not, and there is no performance level or SIL behind anything on this site.
That a correctly-configured envelope is the right envelope for your cell. That remains a risk assessment and it remains yours. What we can probably do is make it cheaper to justify and harder to lose track of, since the configuration is signed and the record shows which configuration was running.
That this protects you from a model doing something harmful inside the authority you granted. The gate bounds authority. It does not judge the task.