Sentinel-EVC

1. 01

   Propose

   A VLA, planner, or recorded policy proposes an action block.

2. 02

   Transform

   Retiming, repair, and frame conversion produce the plan that would actually execute.

3. 03

   Recheck

   Physical checks and the bound consequence-prediction profile evaluate the final candidate; unsupported actions remain unknown.

4. 04

   Permit

   The permit binds plan and context, with a deadline and one use.

5. 05

   Execute

   The single writer rechecks fresh state and distinguishes submitted, accepted, and observed commands.

6. 06

   Verify

   Events, results, and asset digests enter signed records for offline replay and verification.

Revocation prevents further old-generation submissions. Recovery confirms cancel and drain, obtains post-revoke feedback, and resumes with the current epoch and explicit approval. Actions already accepted by the controller remain part of the record.

A separate grid/backend/horizon from 58/100; zero interventions. It is not a 35-point Sentinel gain, hardware performance, or SO100 task success.

All 42 failures are retained; observe-only, distinct from the SO100 overlay, UR5e, and Sentinel intervention efficacy.

The horizon ablation uses 20 matched states and 40 rollouts; the reset audit compares 40 resets without loading a policy; the complete-version comparison uses a separate 20 matched states and 40 rollouts. They answer different questions and should not be combined into one improvement percentage.

Task 5 still fails 9/10; small-sample intervals include zero. This is not an overall model gain or an asynchronous chunk method.

Shows a version difference before policy action; it neither proves reset-pose causation nor ranks physical accuracy.

A complete-version benchmark-compatibility effect, without isolating one contact/reset cause. Task 5 still fails 3/10 under the compatibility version.

The floor rule equals fixed 4.8 s root by root, with no adaptive-duration gain; mu_min=.015 is declared. Finite strata do not qualify a continuous domain or hardware. The 3.2 s analysis is post-hoc.

Across 100 matched cases, observed history, state and action bytes stay identical while future friction changes. Unsafe labels differ in 100/100 pairs for the 1.6 s action and 0/100 for the 4.8 s action.

Shows ambiguity from an unobserved future contact change; it does not prove static friction can never be identified through informative probing.

Final-action verification

Immutable plan digests, full physical checks, and bounded prefix reuse; mismatched bindings trigger full fallback.

Product core

Consequence prediction

Evaluate four sibling candidates, retain prediction envelopes and model/calibration identities, then select deterministically from the allowed set.

Numeric core; GPU models are separate research

Permits and runtime state

Time-boxed single-use permits, fresh feedback, generation revocation, confirmed cancel, and drain-based recovery.

Product core

Signed evidence and replay

Retain run, model, prediction, and event records; verify independently, filter events, and download ZIP evidence.

Local workbench

3D asset inspection

Import OBJ, STL, MJCF, and URDF; preview parsed geometry and perform bounded MuJoCo compilation and five-step checks.

Inspection and preview; no motion permit

SSH experiment entry

Use an existing OpenSSH host configuration to run source-bound experiments remotely and verify returned evidence and transfer receipts.

Existing alias, key agent, and known_hosts required

Read-only robot diagnostics

Mock diagnostics and Universal Robots model, mode, and safety-status queries; this surface sends no motion commands.

Read-only; physical motion adapter pending

1. Install the core or physics profile and start the local workbench.
2. Create or import a scenario and compare geometry and consequence results for four candidates.
3. Run the experiment and inspect execution completion, evidence integrity, and scientific acceptance separately.
4. Replay recorded motion and inspect events and the three runtime cursors.
5. Request stop, drain, and approved recovery through the lifecycle, retaining the actually accepted tail.
6. Export a signed ZIP and verify it with the independent verifier.

A recorded workbench run shows completed execution, evidence PASS, incomplete scientific acceptance, and slip together. The macOS App is a locally built research shell managed by a Python environment; distribution signing and notarization remain open.

The UR5e study compares 180 constructed, same-root simulation cases. Independent higher-resolution review labels 139 unsafe and 41 safe; each method faces the same plan changes.

Parent-only checking falsely allows 125 unsafe cases; full final validation and the incremental-with-fallback path allow none in this set. These are results for the constructed simulations, rather than a guarantee across robot settings.

Experimental setup, full results and original figure

Six scenario classes with 30 roots each produce 180 same-root comparisons. A separately implemented reviewer uses 0.005 rad static sampling and 1 ms MuJoCo steps, labeling 139 roots unsafe and 41 safe.

UR5e same-root comparison

Policy	Allowed / 180	False allows / 139 unsafe	False rejects / 41 safe	Mean observed wall time
Parent only	166/180	125/139	0/41	101.15 ms
Full final validation	41/180	0/139	0/41	48.74 ms
Incremental + fallback	41/180	0/139	0/41	147.65 ms
Reject transforms	30/180	0/139	11/41	No validation call

106 roots reuse the static prefix and 74 fall back fully. The incremental stage averages 46.50 ms plus 101.15 ms for parent validation: 147.65 ms total, slower than full validation's 48.74 ms. Dynamic replay always starts from frame zero.

Seven representative cases, 720p, 33.75 s including titles and final-state holds. The 287 stored joint-state frames run at 1× for 14.35 s. Rendering reruns neither physics nor the gate.

Original UR5e review results

The SmolVLA study uses official SO100 PickPlace recordings to fine-tune the action expert and related projections, preserving separate training, selection and held-out evaluation splits. The model package, loader and evaluation records are published on Hugging Face.

Data splits, model package and evaluation settings

Fine-tune the action expert and state/action/time projections over a pinned SmolVLA base and frozen SmolVLM2 backbone. Training runs for 5,000 updates, development selects update 3,750, and 99,880,992 parameters are trainable.

Official SO100 PickPlace: 50 episodes, 19,631 frames, 30 Hz, six joint/gripper fields, and top/wrist cameras. The study uses 30 train / 5 dev / 10 cal / 5 test episodes, with normalization fitted on training data only.

One paired held-out evaluation with identical sampling noise lowers normalized MAE by 63.46%. Five held-out episodes produce 1,926 overlapping windows, each predicting a 50×6 action chunk; the independent unit remains the episode.

SmolVLA held-out action reconstruction

Policy	Normalized action MAE	Native-field action MAE
Pinned base	0.673166	13.321098
Dev-selected fine-tune	0.245984	4.47285

The Hub publishes a 21-file overlay, loader, model card, and evaluation record. The pinned original base and backbone are required; one dev-only [1,50,6] example passed a bitwise equality check.

This result measures reconstruction of recorded actions, not robot task success. The data does not declare common physical units; SO100 overlay results cannot be attributed to the separate UR5e simulator study.

RTX 4090 D (24 GB), four threads, batch one: in-memory images through unnormalized actions measure P50 229.26 ms / P95 236.90 ms over 20 synchronized calls. Video reading, transport, and actuation are excluded.

WorldGuard tests consequence prediction under distribution shift. Cameras, payload, friction and the supported action range change the conditions for a decision. The study retains failures alongside selection coverage and simpler comparators.

The interactive installer selects the core or physics profile, creates an isolated environment, and can build the macOS App. Product runtime requires Python 3.10+ and serves only on 127.0.0.1. A PowerShell installation entry exists for Windows; GPU training and loading use a separate pinned environment.

python -m pip install -e ".[physics]"
python -m sentinel_evc serve --data-dir runs/workbench --port 8765

Each study retains commands, source/environment identities, input revisions, model/calibration digests, and per-root or per-episode artifacts. Signatures establish integrity relative to the chosen public key; replay shows stored data without recomputing the experiment.

• Numeric core, fixed contact, GPU models, UR5e, and LIBERO protocols are separately recorded profiles.
• Robot entry is read-only; imported-model inspection grants no motion authority.
• Zero observed failures, prediction coverage, task completion, and physical incidents are distinct metrics.
• Signatures establish neither sensor honesty, physical execution causation, nor safety certification.
• ROS 2 motion, physical actuation, mTLS, production PKI, and notarized distribution remain open.