Proposal: Reproducible actuator-boundary safety (SSC + conformance harness)

Hi all — I’m looking for feedback on a design question around actuator-boundary safety in ROS-based systems.

Once a planner (or LLM-backed stack) can issue actuator commands, failures become motion. Most safety work in ROS focuses on higher layers (planning, perception, behavior trees), but there’s less shared infrastructure around deterministic enforcement at the actuator interface itself.

I’m prototyping a small hardware interposer plus a draft “Safety Contract” spec (SSC v1.1) with three components:

  1. A machine-readable contract defining caps (velocity / acceleration / effort), modes (development vs field), and stop semantics

  2. A conformance harness (including malformed traffic handling + fuzzing / anti-wedge tests)

  3. “Evidence packs” (machine-readable logs with wedge counts, latency distributions, and verifier tooling)

The goal is narrow:

Not “this makes robots safe.”

But: if someone claims actuator-boundary enforcement works, there should be a reproducible way to test and audit that claim.

Some concrete design questions I’m unsure about:

• Does ROS 2 currently have a standard place where actuator-boundary invariants should live?

• Should this layer sit at the driver level, as a node wrapper, or outside ROS entirely?

• What would make a conformance harness credible to you?

• Are there prior art efforts I should be aware of?

I’m happy to share more technical detail if useful. Mostly interested in whether this layer is actually leverageful or if I’m solving the wrong problem.

Quick update: I’ve now published (1) SSC v1.1 draft, and (2) an initial Evidence Pack schema + sample pack for critique.

If you had to pick one place in the ROS 2 stack where actuator-boundary invariants should live, which is least-bad?

A) ros2_control / driver layer

B) lifecycle node wrapper around controllers

C) outside ROS entirely (bus-level interposer)

Evidence schema (for context): sentinel-proxy/evidence/schema.json at main · repozilla2/sentinel-proxy · GitHub

I’ve opened two concrete review issues (schema + known gaps).

If anyone thinks this approach is structurally flawed, I’d genuinely prefer to know early.

If actuator invariants should not live outside ROS, I’d appreciate someone explaining why that layer is the wrong place to anchor them.