Capabilities

DEMO DATA
Capabilities

One trust spine, any robot stack

The capture adapter is the only middleware-aware part of the system. Everything below it — the hash chain, Ed25519 signing, Merkle anchoring in the transparency log, and independent verification — is identical no matter where the bytes came from. Supporting a new middleware is one adapter class and a registry line; no change to the core.

Middleware we capture from

Six sources ship today. Chips match the source_type you see on every session.

ROS 2 ros2

passive rclpy tap

Dynamic topic discovery; records raw CDR plus full message definitions, so the bag stays Foxglove-openable.

● 6 robots in this fleet

Foxglove WebSocket lpws

foxglove.sdk / .websocket protocol

Point it at any foxglove_bridge (ROS 1 or 2) or a non-ROS Foxglove-WS server. Schemas auto-discovered.

● 3 robots in this fleet

MQTT mqtt

broker pub/sub

Mosquitto, EMQX, HiveMQ, AWS IoT. Topic→role mapping via globs; the common non-ROS field bus.

● 2 robots in this fleet

Zenoh zenoh

zenoh / rmw_zenoh

Native Zenoh pub/sub, including ROS 2 running over the rmw_zenoh middleware.

● 2 robots in this fleet

Lex Prima SDK sdk

in-process capture() → local socket

One call in your stack, any language. Carries true source timestamps — the tightest, lowest-overhead path.

● 1 robot in this fleet

Recorded bag bag

MCAP replay

The ROS-free dev / CI source. Replays any recorded .mcap through the identical pipeline.

○ dev / CI source

Every record is tagged by role

Capture normalises each message into one of five semantic roles, so an investigator can ask “what did it see, infer, decide, and do?” — not just replay raw topics.

sensor

Sensor

What the robot perceived — camera, lidar, IMU.

perception

Perception

What it inferred — detections, tracks, maps.

decision

Decision

Why it acted — planner / behaviour-tree output.

actuator_cmd

Actuator cmd

What it did — velocity, joint, gripper commands.

system

System

Health & context — diagnostics, battery, faults.

Assurance ladder

The same evidence format carries a signal of how it was signed. Higher rungs move the seal closer to the source and into hardware — visible per session as signing_point and key_custody.

1

Agent-signed · software key

Signed on the robot by the agent; key in software custody.

2

Agent-signed · hardware key

Same, but the signing key lives in a host TPM / secure element.

3

Source-signed

Signed at the producer via the SDK — evidence is sealed before it leaves the process.

Adapters resolve from the trustspine.adapters plugin registry — new middleware can ship as a separate package with zero core changes.