Why You Should Adopt RCAN Before You Need To
Update (March 12, 2026): RCAN v1.3 is now current — §18–§20 and Appendix B promoted to Stable, §21 (Registry Integration) introduced. Registry moved to robotregistryfoundation.org. Read what’s new →
There’s a moment in every serious robot incident — a warehouse arm that injures a worker, a delivery robot that makes a wrong decision, an autonomous system that does something unexpected in a context no one planned for — where the investigation hits a wall.
Not because the robot failed. But because no one can prove what it did.
Which command arrived? Who sent it? Was it authorized under the access policy in effect at that moment? What did the robot’s sensors show? What was the confidence level on the AI inference that produced the action? Was there a human in the loop? What did the audit log say?
In most deployments today, the answers to those questions are either unavailable or forensically indefensible. Logs are inconsistent formats on local storage. Access control is bespoke per manufacturer. The chain of custody from “operator issued command” to “robot executed action” is informal and unreproducible.
That’s the problem RCAN was built to solve.
The automotive parallel — and why we’re repeating it
The automotive industry went through this exact inflection point in the early 2010s. Self-driving systems were shipping. The technology was real. The deployments were accelerating. And there was no common vocabulary for what the human was responsible for at any given moment, no shared framework for incident investigation, no agreed-upon audit standard for what the vehicle’s systems needed to record.
SAE J3016 — the Level 0–5 taxonomy — didn’t arrive until 2014. Functional safety frameworks were still catching up. The result was years of regulatory fragmentation, landmark incidents that couldn’t be properly analyzed because the data didn’t exist, and liability litigation that’s still unresolved a decade later.
The lesson wasn’t that autonomous vehicles were a mistake. The data consistently shows they’re safer than human drivers. The lesson was that deploying first and standardizing later is expensive — in litigation, in regulatory chaos, and sometimes in lives.
Robotics is at the same inflection point. Right now. The window where standardization can get ahead of fragmentation is open — and it won’t stay open forever.
What RCAN actually does
RCAN — Robot Communication and Addressing Network — is an open protocol specification for robot networking built from the safety requirements outward. It’s at v1.3, and it covers four things that most robot deployments currently handle inconsistently or not at all.
1. Addressing
Every robot gets a globally unique identifier — a Robot URI — in a defined, resolvable format:
rcan://<registry>/<manufacturer>/<model>/<device-id>This sounds simple. It isn’t trivial. Without it, you can’t definitively say which robot executed a command in a fleet of identical units. You can’t cross-reference incident logs against a specific device. You can’t federate access policies across an enterprise with mixed hardware. Global, stable, resolvable addressing is the foundation everything else builds on.
2. Authentication and access control
RCAN defines a layered permission model: operator-level, fleet-level, and device-level, with explicit scopes. Commands carry cryptographic authentication. The authorization chain is logged. You can reconstruct, after the fact, exactly who was authorized to issue what commands, under which policy, at what time.
This isn’t just good security hygiene. It’s the difference between “the robot was hacked” and “the robot received an authenticated command from principal X under policy Y, which was valid at the time, and here is the proof.”
3. Forensic audit trails
RCAN messages carry structured metadata: timestamp, sender identity, authorization scope, action taken, sensor snapshot, and — in v1.2 — AI model identity, confidence score, and human-in-the-loop gate status.
The AI accountability layer (§16) was added specifically because AI-driven decisions introduce a new category of forensic question. When a human programs a robot to weld at a specific coordinate, the action is deterministic. When an AI model infers “the object in position X is safe to interact with,” the action depends on a confidence distribution, a model version, a training dataset, and an inference context. All of that needs to be in the record if you want to reconstruct the decision after the fact.
A QuantumLink-Sim commitment record — a cryptographic hash of a structured action log — gives you tamper-evident proof that the system produced this output at this moment, with this model, under this authorization. That’s the audit trail the automotive industry didn’t have in 2014.
4. Safety gates
RCAN defines explicit safety state transitions and a structured HiTL (human-in-the-loop) gate mechanism. High-stakes actions above configurable confidence thresholds require explicit human authorization before execution. The gate state is logged. The authorization is cryptographic.
When a regulator asks “was there human oversight of this action?” — you have a yes/no answer with a signed timestamp, not a verbal assurance.
Why now
Three things are converging that make this the right moment to adopt RCAN rather than waiting:
EU AI Act, August 2026 and 2027. High-risk AI provisions apply from August 2026 for Annex III systems; robots deployed as safety components of machinery fall under Annex I via the Machinery Regulation (EU) 2023/1230 and face a 20 January 2027 deadline. Either way, robots in safety-critical environments — manufacturing, logistics, healthcare-adjacent contexts — will be subject to requirements around transparency, human oversight, and audit documentation. The Act doesn’t specify a protocol. It specifies outcomes: you must be able to demonstrate that oversight existed. RCAN is the infrastructure that makes that demonstration concrete rather than aspirational.
JTC 21 is writing the standards now. The EU’s joint technical committee is finalizing prEN 18229-1 (logging and transparency requirements for AI systems) and prEN ISO/IEC 24970 (AI system logging). These will become the harmonized standards under the EU AI Act. The window to influence what “adequate audit logging” means in a robot context is right now, not after the spec is finalized.
The fragmentation window is still open. Every month that passes without a common addressing and audit protocol is another month of proprietary implementations that will have to be migrated later, or that will become the de facto standard by inertia even though they weren’t designed for safety-first use cases.
What adoption looks like
RCAN is a protocol specification, not a library. You implement it in your stack. The spec is open, the reference implementation is open, and the robot registry at robotregistryfoundation.org is free for early adopters.
If you build robot hardware: Register your models in the RCAN registry. Assign URIs at manufacturing. Ship with RCAN addressing support so integrators can address your robots in multi-vendor fleets without building bespoke connectors.
If you build robot software: Implement RCAN message types for command-response, status reporting, and safety events. Add confidence gating and HiTL gates to your inference pipeline. Produce QuantumLink-Sim commitment records for safety-critical actions.
If you operate robot fleets: Adopt RCAN addressing for your device inventory. Require RCAN-compliant audit logs from vendors as a procurement condition. Build your access control policy model against RCAN scopes.
If you’re a systems integrator: Use RCAN as the common substrate for multi-manufacturer fleet integration. Stop building bespoke translation layers between proprietary addressing schemes. Make RCAN compliance a vendor evaluation criterion.
The ask
I’m looking for early adopters who want to implement RCAN, contribute to the specification, or engage with the standards process together. This is most useful for:
- Hardware manufacturers who want their robots RCAN-registered and referenced in conformance profiles
- Software teams building robot operating systems or middleware who want to implement RCAN natively
- Organizations navigating EU AI Act compliance who need an audit infrastructure that will withstand regulatory scrutiny
- Research teams working on robot safety, accountability, or multi-robot coordination who want a protocol to build against
The spec is at rcan.dev/spec. The robot registry is open at robotregistryfoundation.org/registry. The GitHub repo is at github.com/continuonai/rcan-spec.
If you’re building something in this space and want to talk — whether you want to adopt RCAN, push back on the spec, or figure out together how to get this in front of the right standards bodies — reach out. The protocol doesn’t matter if no one implements it.
The automotive industry standardized after the chaos. We have a shot at doing it the other way.
Craig Merry is the author of RCAN and OpenCastor. He builds AI-driven robot systems and protocol infrastructure at craigmerry.com.