Out of the loop, by construction

The first question any safety engineer asks about on-robot software is simple: can this thing move the robot? If the answer is anything other than a firm, demonstrable no, the software doesn't get deployed on anything operating near a person. The Robot Data Recorder is designed so the answer is no, and so that "no" is verifiable rather than promised.

A passive subscriber

The RDR subscribes to telemetry the robot already publishes. It has no publisher on any command, actuation, or safety topic. In ROS 2 terms, it holds subscriptions and nothing else on the control surface: there is no topic it can write to that the robot listens to for motion, no service it can call to change behavior, no action it can trigger. The absence of a publisher isn't a policy setting you trust; it's a property of the node graph you can inspect.

You don't audit intentions. You audit the graph, and the graph has no edge from the recorder to the robot.

Read-only, capped, and signed

The recorder ships as a single container, run read-only, with hard resource caps:

docker run -d --read-only --cpus 0.5 --memory 384m nvcr.io/boop/rdr

The --read-only root filesystem means the running container can't rewrite its own code. The CPU and memory caps mean it can't starve the control stack even under load, in practice it draws under 3.6% of CPU off the control cores, roughly 0.3% of memory, and 0% of the GPU or AI engine. It runs CPU-only, on Linux compute the robot already carries, and it's distributed and attested through NVIDIA's container catalog so the image you run is the image that was built.

The audit package

Trust here is not a data-sheet claim; it's an artifact your engineers hold. Every deployment ships with an audit package containing:

• The signed read-only policy, the exact set of topics the recorder subscribes to, and the empty set it publishes.
• The resource caps as enforced, not as suggested.
• The attested build, a cryptographic chain from source to the container image running on the robot.

Integration is a standard ROS 2 pattern mapped onto your existing topics, typically a half-day session, with no new instrumentation and no second on-robot integration to maintain.

What it captures, and what it refuses to

Being out of the loop is only half the safety story; the other half is restraint about what leaves the robot. The RDR persists a bounded event window around a covered incident and forwards only that, signed locally first. It captures robot position and task state, a sensor snapshot, command and operator history, proximity, and fault codes. It does not capture continuous video, model weights, proprietary intelligence, customer trade secrets, or unrelated robot behavior.

Autonomy and teleop, one node

Because control mode is just a field on every record, the same node covers autonomous and teleop-assisted operation without a second integration. Handoffs between the two are logged as control-mode transitions, alongside the latency profile, supervision ratio, and operator tier, operator identity pseudonymized at the source. It turns out jitter, not raw latency, is the metric that best predicts trouble.

None of this requires the recorder to ever touch the loop. That's the point: the safest instrument is the one that, by construction, could not have caused the thing it's recording.