PlatAtlas · teaching page · no login

Anatomy of a checkable action — RCAN

This page shows the shape of an action a third party can check. Each example is a real rcan-action-trace/1 envelope carrying real Ed25519 signatures — drawn from the RCAN conformance test suite. You can verify the signatures yourself, in your browser. The tampered example genuinely fails. A refusal is shown too, because a signed refusal is itself a checkable fact.

read this first — the honesty firewall These are real Ed25519 signatures over RCAN conformance test vectors with bundled keys. Verifying them proves the envelope is cryptographically valid and tamper-evident — it does NOT assert that any real robot action occurred. A live action resolves the signing key against the Robot Registry (RRF); these fixtures stand in for that. Everything below describes this example, not a production event.

Loading example…

The real machinery these examples stand in for

A live PlatAtlas action is recorded by mcp-tape and re-played by mcp-replay. Each action is an RCAN envelope: the operator signs the invoke, the gateway signs the outcome, and a third party resolves each signing key (kid) against the Robot Registry (RRF) — proving which robot and operator the keys belong to. The ROBOT.md gateway is what can turn an approval into the signed refusal you see in the first example. This page carries only the envelopes and their bundled keys; it deliberately does not perform RRF resolution, so it can never claim a real action took place.

RCAN: the signed action-trace envelope format (invoke + outcome, each Ed25519-signed over a canonical preimage)
RRF: Robot Registry — resolves a key id to a registered robot/operator (the step these fixtures omit)
mcp-tape: records the action trace as it happens
mcp-replay: re-plays a recorded trace for inspection
gateway: the ROBOT.md policy gate that permits or refuses an action and signs the outcome

To connect a real robot and ingest live, signed traces, see the setup guide.

← PlatAtlas home