If We Start From a Safety Standard, We Can Build Faster

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 →

In January 2014, SAE International published J3016 — the six-level taxonomy that gave the world a shared vocabulary for vehicle automation. Level 0 through Level 5. No automation through full self-driving. The document that every regulator, journalist, and OEM has been citing for the past decade.

By the time it dropped, Google’s self-driving car program had been running for five years. Tesla Autopilot was months from launch. Waymo, Uber, and a dozen other companies were already testing vehicles on public roads with systems that had no common vocabulary, no shared liability framework, and no agreed definition of what the human was actually responsible for at any given moment.

The standard was chasing the technology. It arrived after the ecosystem had already fragmented.

The chaos that followed is instructive. A semantic gap between “the car can handle this” and “the driver must remain alert and ready to take over” contributed to fatal crashes. NHTSA investigations (including EA22-002) concluded that Tesla’s Autopilot — a Level 2 system — was being used in ways consistent with how users understood a higher automation level, documenting a “critical safety gap” between driver expectations and actual system capabilities. Regulators in different states wrote different rules. Manufacturers marketed partial automation using language that implied full automation. Courts are still working through liability frameworks that should have been established before any of these vehicles left the test track.

The lesson isn’t that autonomy is dangerous and should be slowed down. The data is clear that automated vehicles are, in most conditions, safer than human drivers. The lesson is that deploying first and standardizing later is expensive — in time, in litigation, in regulatory fragmentation, and sometimes in lives.

Why automotive got it backwards

The automotive path looked rational at the time. You build the technology, you prove it works, then you work backwards to the standard. The problem is that “works” is undefined without a standard. Each company defined their own criteria. Each deployment carried different assumptions about the human-machine interface. Each incident had to be litigated on its own terms because there was no common baseline.

ISO 26262, the functional safety standard for automotive electronics, wasn’t finalized until 2011 — after decades of electronic control units in vehicles. AUTOSAR, the software architecture that enables components from different Tier-1 suppliers to run on the same ECU, took until the mid-2000s to reach meaningful adoption, long after the industry had already baked in incompatibilities.

The standards that did land early created real advantages. J1939 — the CAN bus protocol for heavy vehicles, with initial sub-specifications first published in 1994 — gave the trucking industry a common communication layer that enabled a generation of interoperable components. Manufacturers that built against it could source sensors, controllers, and ECUs from different suppliers and have them communicate out of the box. The standard created interoperability that would have taken years of bilateral integration agreements to replicate.

Standards that define things precisely, before the ecosystem fragments, enable faster development. Not slower. That’s the counterintuitive part.

Robotics is at the same inflection point

General-purpose robotics is where automotive autonomy was in 2010. The technology is moving fast. Deployments are accelerating. Warehouse robots, delivery bots, home companions, physical AI systems of every description are shipping to real environments. And there is, at the moment, no agreed vocabulary for:

How you address a robot uniquely and globally
Who is allowed to issue commands to it, and at what scope
What happens when network connectivity fails
How you produce a forensically defensible record of what the robot did and why
How you coordinate fleets across manufacturers without a single point of control

Every company is solving these problems independently. The integrations are proprietary. The audit trails are inconsistent. The access control models are bespoke. And we are, right now, in the window before that fragmentation becomes structural.

That window closes. It always does.

RCAN: a protocol spec built from the safety constraints outward

I’ve been writing RCAN — Robot Communication and Addressing Network — as a specification for robot networking that starts from the safety requirements and builds the protocol around them. It’s at v1.3 now.

The core primitives:

Every robot gets a globally unique identifier — a Robot URI (RURI) — in a defined format:

rcan://<registry>/<manufacturer>/<model>/<device-id>

For local deployments, rcan://opencastor.rover.abc123 expands automatically to rcan://local.rcan/opencastor/rover/abc123. This isn’t cosmetic. A unique, structured identifier is the prerequisite for auditing, for fleet coordination, for access control, for federation. You can’t track what a robot did if you can’t name it consistently.

Role-Based Access is a protocol primitive, not an application concern. RCAN defines a five-level role hierarchy that every conformant implementation must enforce:

Role	Level	Session TTL	Key permissions
GUEST	1	5 min	Status reads, read-only telemetry
USER	2	1 hour	Operational control within allowed modes
LEASEE	3	2 hours	Time-bound operational control
OWNER	4	8 hours	Config writes, user management, training
CREATOR	5	Unlimited	Safety overrides, firmware, full access

Every command carries a declared scope. Commands from principals that lack the required role are rejected at the protocol layer — not by the application, not by the model, not by whatever logic the developer happened to write. By the spec.

The safety invariants in §6 are the section I think about most. Local safety always wins — no remote command can bypass on-device safety checks regardless of the principal’s role. Network loss must trigger a safe-stop within one latency_budget_ms interval. Messages with Priority.SAFETY skip rate-limiting queues and process before anything else. Implementations that forward natural language to an LLM must scan for injection patterns before calling the model; a blocked result must return an error.

And the audit requirement: every COMMAND and CONFIG message must be logged with principal identity, RURI, timestamp in milliseconds, message ID, and outcome. This is a conformance requirement, not a best practice.

That last one deserves more attention than it usually gets.

The audit problem is harder than it looks

A log file that records what a robot did is not a forensic record. It’s a text file.

Anyone with write access to that file can append lines, reorder entries, change confidence scores, or silently delete events. Standard hash-chaining with SHA-256 improves on this — you can detect that the chain was broken — but it doesn’t prevent a sophisticated attacker from recomputing valid hashes after making changes, particularly if they have offline access to the log file and time to do it.

For a robot operating in a medical environment, a warehouse shared with humans, or any safety-critical context, the audit trail isn’t a convenience — it’s the forensic record that establishes what the system was instructed to do, what it actually did, and whether the two diverged. That record needs to be trustworthy.

The hybrid quantum commitment layer

OpenCastor is my reference implementation of the RCAN spec, and its audit trail goes further than §6 requires. Every RCAN action is sealed into a cryptographic commitment chain using QuantumLink-Sim — a library I wrote to implement BB84 Quantum Key Distribution simulation for exactly this use case.

The commitment architecture supports three key derivation modes.

Classical uses keys derived via HKDF-SHA256. Fast, strong against every classical adversary, included as a baseline for comparison.

Quantum uses keys derived from BB84 simulation. BB84 — published by Bennett and Brassard in 1984 — encodes bits as quantum states, and any eavesdropping attempt collapses the superposition and introduces measurable errors. If the Quantum Bit Error Rate stays below the configured threshold (default: 11%), the key is considered secure under information-theoretic assumptions — not computational hardness, but physics. A pool of 32 pre-warmed keys keeps the hot-path commit latency under 0.2ms on the Pi.

Hybrid is the default, and the interesting one. The commitment key is:

key = XOR(HKDF-SHA256 key, BB84 key)

Both channels are independently derived. Both must be compromised simultaneously for an attacker to recover plaintext. Breaking the classical channel via a quantum computer doesn’t help without also intercepting the BB84 channel — and intercepting BB84 introduces QBER errors that appear in the commitment record. The two attack surfaces are structurally orthogonal.

The chain uses HMAC-SHA256 keyed with a session-bound secret that is held in memory and never written to the log. Even with full access to the JSONL output, an attacker cannot recompute valid HMAC values without the secret. Every committed record carries the full derivation proof:

{
  "id": "a3f7c1d9-82b4-4e1c-9a0f-d3c4e5f61b2a",
  "timestamp_ns": 1740721482934812416,
  "payload_hash": "9e3e4c5a1d2b...",
  "key_mode": "hybrid",
  "qber": 0.034821,
  "key_secure": true,
  "chain_hash": "7f8a9b0c1d2e...",
  "proof": {
    "mode": "hybrid",
    "components": ["HKDF-SHA256", "pool"],
    "combination": "XOR",
    "qber": 0.034821,
    "quantum_secure": true,
    "note": "Key = XOR(HKDF-SHA256, BB84). Adversary must break both classical KDF and QKD channel."
  }
}

The config lives in the RCAN YAML alongside every other robot configuration decision:

security:
  commitment:
    enabled: true
    mode: hybrid
    pool_size: 32
    n_qkd_bits: 512
    qber_threshold: 0.11
    storage_path: .opencastor-commitments.jsonl
    export_secret_path: .opencastor-chain-secret.hex

What OpenCastor is today

It’s worth stepping back from the architecture to describe what OpenCastor actually is at this point, because the scope has grown significantly since the launch post six weeks ago.

OpenCastor is an AI robot runtime. You give it a .rcan.yaml configuration file describing your hardware, your LLM provider, your safety bounds, and your network settings. It boots a full perception-action loop that:

Reads from cameras, depth sensors, LiDAR, and IMU
Routes decisions through a tiered brain architecture (reactive rules → fast vision model → full planner)
Accepts natural language commands from WhatsApp, Telegram, Discord, Slack, voice, and terminal simultaneously
Enforces physical safety bounds before any actuator command reaches hardware
Records every decision and action in a verifiable audit chain
Self-improves after each episode via the Sisyphus Loop (PM → Dev → QA → Apply)

The latest release is v2026.3.12.0. The test suite is at 5,989 tests across Python 3.10/3.11/3.12. It’s on PyPI. curl -sL opencastor.com/install | bash and you’re running in under a minute on a Pi.

Some of what’s shipped in the past month:

The agent harness architecture, documented in detail alongside Anthropic’s Claude Code design — the same class of problems, different consequence space. Physical actions are irreversible; that changes every architectural decision.

The quantum commitment audit trail, described above — every RCAN action sealed into a QKD-keyed chain via QuantumLink-Sim.

A full hardware detection and plug-and-play layer — Hailo-8, OAK-D, IMU (MPU6050/BNO055/ICM-42688), 2D LiDAR (RPLidar A1/A2/C1/S2), and PCA9685 servo controllers all auto-detected on boot.

A geofencing system, Prometheus metrics, OpenTelemetry tracing, a fleet dashboard, and a mesh networking layer for multi-robot coordination.

A surface-aware messaging architecture that ensures the same robot brain produces appropriate output for WhatsApp, voice, terminal, and dashboard simultaneously — each surface gets a different communication contract, injected at inference time.

The Sisyphus self-improvement loop: after each episode, a PM agent analyzes what happened, a Dev agent generates config patches, a QA agent verifies them against a simulation harness, and the changes apply. The robot gets measurably better at its environment over time without manual intervention.

The direction

OpenCastor’s direction is simple to state and hard to fully execute: become the open standard runtime for physical AI systems.

Not a competitor to ROS2. ROS2 is infrastructure; OpenCastor runs on top of it or alongside it. Not a hardware platform. The RCAN spec is hardware-agnostic by design, and OpenCastor implements it on whatever the .rcan.yaml describes.

The bet is that as physical AI systems proliferate — warehouse robots, companion robots, delivery systems, research platforms — the market will need a layer that handles the common concerns: safety enforcement, access control, audit trails, provider-agnostic LLM routing, multi-surface communication, fleet coordination. Either every team builds this themselves (expensive, fragmented, unsafe by default) or there’s a shared open runtime they can build on.

The automotive parallel holds here too. Toyota and Ford don’t write their own CAN bus implementations. They build against J1939. The protocol layer is shared infrastructure; the differentiated product is built on top.

RCAN is the protocol. OpenCastor is the runtime. The goal is to be to physical AI what Linux is to servers — the common foundation that everyone builds on because starting from scratch doesn’t make sense.

The political dimension

I wrote in detail in a previous post about the Anthropic/Pentagon confrontation — the demand that Anthropic remove safety guardrails, the refusal, and the White House response. The argument on the government side is that legality is the end user’s responsibility, not the contractor’s. The model is a tool. Tools don’t get red lines.

If that argument wins, the safety constraints maintained at the model provider level become negotiable. And when they become negotiable, the question of where the safety layer lives stops being an architecture question and becomes a political one.

RCAN and OpenCastor are a bet on a specific answer: the safety layer should live at the protocol and runtime layer, defined in an open specification, implemented in auditable open-source code, independent of any single provider’s terms of service. If a government can compel an AI company to offer an unrestricted API, the safety constraints at the runtime layer should not be removable by changing an API key.

This isn’t naive. An open protocol doesn’t stop a state actor. But architecture shapes what’s possible. If the baseline for robotics networking includes mandatory audit trails, protocol-level access control, and hard safety invariants as conformance requirements — if that’s what RCAN-compliant means — then the cost of quietly removing those constraints goes up, for everyone.

The automotive industry didn’t standardize safety early enough to prevent the fragmentation and litigation of the past decade. The window is still open for robotics. The choice is worth making deliberately.

The stack, today

Everything described here is open source and active:

RCAN spec v1.3: rcan.dev/spec — the protocol
OpenCastor v2026.3.12.0: github.com/craigm26/OpenCastor — the runtime
QuantumLink-Sim v0.3.0: github.com/craigm26/Quantum-link-Sim — the audit layer

# Install OpenCastor
curl -sL opencastor.com/install | bash

# Enable quantum commitment in your .rcan.yaml:
# security:
#   commitment:
#     enabled: true
#     mode: hybrid

# Verify your audit chain
castor commit verify
castor commit stats

# Use QuantumLink-Sim directly
pip install quantum-link-sim

from quantumlink_sim.commitment import CommitmentEngine, KeyMode

engine = CommitmentEngine(mode=KeyMode.HYBRID)
engine.start()

record = engine.commit({"action": "move_forward", "linear_x": 0.3, "confidence": 0.91})
ok, broken_at = engine.verify_chain()

The physics is simulated. The cryptography is real. The standard is open. Build against it.