00 / THE RESEARCH QUESTION
Can yesterday's authority
move today's machine?
Satyress describes Threehalves as a teleoperation-focused robot with a quick-connect tool interface, replaceable and recalibrated assemblies, and physical air brakes and pin locks. Those published design choices make command authority, attachment identity and recovery behavior useful questions for a software security study. Satyress product description ↗
My proposed contribution is a small adversarial bench: reproduce delayed commands, stale sessions, lost acknowledgements and component changes; capture exactly which transitions the receiver admits; and carry each counterexample through the repair.
INDEPENDENT PROPOSAL · NO COMPANY AFFILIATION
The concrete result below is my own synthetic command-gate model. Its purpose is to make the research questions inspectable before any product integration.
01 / FOLLOW THE AUTHORITY
Four boundaries.
Different evidence at each.
Which action was issued, by whom, and for which session?
Was it delayed, duplicated, reordered or carried across reconnect?
Does freshness, session, sequence and local state permit this transition?
What moved, stopped or remained unconfirmed?
The first study would give a fixture adversary control over packet timing and ordering after authentication. That isolates freshness and lifecycle errors from credential compromise. Later studies would evaluate the actual authentication, update and tool-identity mechanisms once their interfaces are known.
Primary invariant
A stale, replayed or prior-session command cannot create a new accepted motion transition. Stop and link loss remain latched until a separate host rearm; rearm itself produces no motion.
The browser fixture checks the admission boundary. Hardware stop distance, brake timing, cryptographic authentication and real network behavior need separate measurements.
02 / EXECUTABLE LOCAL FIXTURE
Change the sequence.
Inspect every decision.
Select a trace. Each begins from a held state and records both the accepted decision and the resulting state. The clock is injected; the numbers are illustrative test constants.
Stop latches hold. Rearm creates a fresh session without motion. A fresh post-rearm command is required.
- Choose a sequence to inspect the state transitions.
Host stop, arm and reconnect events are trusted harness inputs, separate from received packets. The packet's session number is a binding identifier, not authentication. A command expiry limits its admission time; the local lease limits this model's armed period. The browser does not run a hardware watchdog.
The model uses a 500 ms maximum command lifetime and a 1,000 ms local lease. A real bench must derive both budgets from its controller, network and physical behavior. Rejected replay packets do not renew the lease or undo an earlier valid command.
# Keep both downloaded files in one folder.
node robotics-trust.test.mjs03 / THE PROPOSED BENCH
Useful experiments
before a bigger claim.
| Experiment | Controlled change | Evidence required |
|---|---|---|
| RT-01 Freshness & sessions | Delay through expiry; duplicate and reorder sequence numbers; reconnect with old packets queued. | Zero newly admitted stale or replayed commands. Valid current-session controls remain accepted. Capture receiver time and exact decision reasons. |
| RT-02 Stop & rearm | Stop during a queue; expire the lease; reconnect without rearm; send a pre-stop packet after rearm. | Hold persists through remote advance. Rearm alone produces no motion. Correlate software state with measured stop behavior on a dedicated bench. |
| RT-03 Tool & calibration | Change attachment identity, calibration revision, unit scale or supported tool capability in a mock interface. | Mismatches rejected before actuation. Replacement visible in the record. Matched configurations still operate. Actual interface design is required. |
| RT-04 Operator feedback | Drop acknowledgements; freeze telemetry timestamps; delay a stop response; restore a stale cached display. | Intent, accepted command and observed state remain distinguishable. Stale feedback is visible. Reconnect cannot imply readiness before the handshake completes. |
All four begin in software simulation. Any equipment stage needs a dedicated de-energized or restrained bench and measured stop behavior before motion trials. The physical stop path and the software admission path are separate parts of the experiment.
04 / WHAT I WOULD DELIVER
A witness.
A repair.
A repeatable bench.
The first deliverable is an architecture-linked threat model with one testable invariant per boundary. Each finding then carries a minimal input, a valid control, a deterministic replay, an observed state change and a patch or mitigation retested against the same corpus.
For the company, the reusable product is the regression bench: a compact set of packet, state and UI traces that can run when firmware, controller behavior or tool interfaces change. Unknown transport details, signing design and calibration formats remain named inputs to the study.
05 / SOURCE RECORD
Context and authorship.
- Satyress — product, mission and physical safety description.
Public product context reviewed October 21, 2026. The page's product descriptions motivate research questions; they do not establish software weaknesses.
- Original local command-gate source.
Sergio Rodriguez's synthetic state machine and eight deterministic scenarios. No Satyress code, protocol, hardware or credentials are used.
- Original regression checks.
Known traces, timing boundaries, restart/session lifecycle, malformed input and reordered sequences.
- Adversarial research method.
The existing portfolio studies and the evidence needed to turn a hypothesis into a finding.