Evidence
See what works. Define what comes next.
Endstop has an inspectable engineering record: bounded program execution, specific hardware enforcement checks and a controlled recovery benefit in simulation. Use that record to decide whether a focused evaluation fits your machine.
Endstop is an uncertified engineering prototype, not yet for sale. The records below are company-authored.
Implementation checklist and roadmap
The goal: contain untrusted AI by bounding execution and external actions.
Checklist reviewed 27 September 2026. “Implemented” means the named component exists; the evidence column states where it has been exercised. Next milestones are listed separately.
| State | Capability | Evidence and scope |
|---|---|---|
| ✓ Implemented | Control-token admission | endstop-token translates a bounded, fixed control vocabulary and submits it to the independent VM loader. Seven host tests pass. |
| ✓ Implemented | Bounded program execution | Loader, memory bounds, instruction fuel and three fixed capabilities. Source and seven interpreter proof harnesses; execution evidence. The deployed board image was also attacked directly: seventeen canary-guarded jail-break probes (memory edges, placement, capability hammer, fuel) held on every observed boot. Dated board record. |
| ✓ Implemented | Command-envelope monitor | Setpoint, rate and predicted stopping-position checks with eight monitor proof harnesses, two of them exhaustive. Monitor scope and access. |
| ✓ Implemented | Feedback supervision | Freshness and following-error checks exercised in simulation. Physical encoder, goal and health feedback recorded on an SO-101 arm in a PC-assisted rig. Physical arm record. |
| ✓ Demonstrated within scope | Physical stop on a lost gate reply | In one elbow trial, a moving SO-101 arm passed its predeclared stopping-response checks: 50.12 ms from an invalid UART request to the hold, with 9 encoder counts of further travel. PC-assisted rig: the gate withheld its reply and the trusted PC issued the hold. Dated result. |
| ✓ Implemented | Observability: event journal and signing | Bounded event journal and on-request signing demonstrated in the emulator. Audit design. |
| ✓ Demonstrated within scope | FPGA execution and hardware gates | Loader/VM execution, seventeen of seventeen jail-break probes held, memory-protection denials, and fabric refusal, disarm and lockout on the ECP5 prototype. A program in the board’s interpreter moved a physical SO-101 elbow, and a program one count past the envelope was refused before any actuator write, in a PC-assisted rig. Board evidence, interpreter-to-arm record and hardware results. |
| State | Work item | Completion criterion |
|---|---|---|
| □ Integration / validation | Inference-only deployment | Connect the model’s token output to Endstop’s admission path. Verify that the inference system has no control authority and cannot execute tools or use separate machine or communication routes to bypass Endstop. |
| □ Validation | Production monitor isolation | Exercise the deployed memory layout, configuration authority, reset/fault behavior and debug access together against hostile code. |
| □ Integration / validation | Independent machine enforcement | Stop and sense through the gate's own actuator and feedback paths, without a host in the loop. Cover repeatability, fault phases, calibrated geometry and stopping margins, recovery and bypass tests. |
| □ Validation | Complete response timing | Measure capture, computation, output, drive response and settling under representative load and fault phases against the machine’s agreed deadline. |
| □ Roadmap | Durable evidence recording | Implement persistent verdict records, a hash chain, periodic signing and a secure monotonic counter; verify recovery and retention. |
| □ Validation | Useful work on a partner machine | Compare completed work, incorrect refusals and recovery against existing controls on a representative task. Simulation baseline. |
| □ Roadmap | Independent product assessment | Agree the assessment scope and obtain independent review against applicable requirements. No safety certification, performance level or SIL is claimed. |
The sections below give the supporting results and the acceptance test proposed for each.
Bounded program execution
Demonstrated. The published interpreter has seven proof harnesses, physical FPGA execution and dated workload-counter captures. Step fuel bounds execution; capabilities restrict the effects a program can request.
Scope. Each harness has a defined scope, listed with the source.
Proposed acceptance test. Reproduce the published checks and review coverage of reachable execution states and the capabilities required by the application.
Current result. Supported within the stated harness scopes. The separate envelope monitor carries the intended safety function. Its source is available to design partners and investors under an evaluation agreement.
Hardware enforcement checks
Demonstrated. In the loader/VM-to-policy test, physical disarm blocked the CFS request. A separate envelope check rejected an over-limit payload. A two-input confirmation test kept the gate disarmed without its second confirmation, even after a valid direct request. The jail-break suite attacked the deployed interpreter's memory, capability and fuel bounds; all seventeen probes held on every observed boot, and the completed series then held the PMP wall, the fabric authority and the wire protocol on the same board.
Scope. Fixed test envelopes on the ECP5 prototype.
Proposed acceptance test. On an approved physical test setup, measure the complete response to agreed faults, verify the permitted path and test whether the enforcement boundary can be bypassed. Machine-specific stopping criteria must be agreed first.
Current result. The refusal, disarm and lockout paths held in the dated records linked above. Machine-level validation is the next milestone.
Controlled recovery
Demonstrated. In SmolVLA Protocol V2, recovery enabled 10/10 successful placements under synthetic state bias, compared with 4/10 under shadow monitoring. Both modes completed 10/10 nominal placements without intervention.
Scope. Simulation, with a scripted grasp and simulated recovery, in the placement phase.
Proposed acceptance test. Compare completed work, incorrect refusals and recovery behavior against the partner's existing controls on one useful task, with representative faults and acceptance criteria agreed before testing.
Current result. A recovery benefit in ten matched simulated placement cases. The physical comparison belongs to a partner evaluation.
Further requirements for a product evaluation
Timing admission
The 38-row RTL characterization supports a provisional cost model with pre-execution charging, so an instruction that cannot afford its charge never starts. The next test characterizes the partner's real capabilities on the target setup.
Retained decision records
A bounded emulated journal supports an on-request Ed25519 seal. Continuous trusted-side recording with durable chaining and periodic sealing is the next milestone, with acceptance tests for interruption, restart and verification of retained records.
Independent assessment
No certification is claimed. The next step is to agree the required evidence and assessment scope with a qualified specialist. See the assessment plan and team background.
Engineering records
The dated records linked on this site summarize results. The complete engineering record, with every run manifest, raw capture and reproducibility input, is retained under its run ID and is available to evaluators and investors under NDA. Ask for it in a fit assessment or through the investor request form.
The 27–28 September board records are externally timestamped: the concatenated run manifests and checksums are published as a bundle with an OpenTimestamps receipt. Its SHA-256 is anchored in Bitcoin block 968,951, mined at 05:44 UTC on 28 September 2026, so the record's integrity does not rest on this site alone.
Agree what would justify proceeding.
A design-partner evaluation starts with one machine, one useful task and a decision the evidence should resolve.
Inspect the public record and review the envelope monitor under an evaluation agreement. Together, define the connection map, fault cases and acceptance criteria. The tests proposed above are starting points for a machine-specific plan.
The proposed comparison keeps existing controls in place and measures useful work, response time, failure handling and integration effort. Its result should support a decision to proceed, revise the design or stop the evaluation.
The commercial plan shows how evaluations lead to repeat deployments.
Frequently asked questions
Where should I start reviewing the evidence?
Start with the published source and proof scopes, the hardware record and the board jail-break record. Each record states its setup and scope. The records are company-authored.
What did the simulation experiments show?
In SmolVLA Protocol V2, bounded recovery completed 10 of 10 placements under an injected state bias, against 4 of 10 under shadow monitoring. In the Gemini positive control, the monitor intervened on both damaging traces while permitting all 45 hold and slow-ramp commands. Both are simulation results; the physical comparison belongs to a partner evaluation. Read the experiments.
What comes next?
Stopping and sensing through the gate's own actuator and feedback paths without a host in the loop, production monitor isolation, durable decision recording, and complete response timing on a partner machine. The full engineering record is available under NDA. See the milestones.
How should we judge a proposed evaluation?
Choose one machine, one useful task and a decision the evidence should resolve. Agree the connection map, fault cases and acceptance criteria before testing, with existing controls retained. Compare useful work, response time, failure handling and integration effort. Scope an evaluation.