Update (March 12, 2026): RCAN v1.3 is now current — §18–§20 and Appendix B promoted to Stable, §21 (Registry Integration) introduced. Read what’s new →

Today was one of those rare sessions where everything that was supposed to ship actually shipped, every CI failure got traced to its root cause and fixed, and the architecture got meaningfully clearer in the process.

By end of day, the RCAN ecosystem looked like this:

Package	Version	Distribution
opencastor	v2026.3.8.0	PyPI
rcan (Python SDK)	v0.3.0	PyPI
@continuonai/rcan-ts	v0.3.0	npm
rcan-spec	v1.2.1	rcan.dev / Cloudflare Pages

Not one release — eight. OpenCastor went through v2026.3.6.0, v2026.3.7.0, and v2026.3.8.0 in a single day. rcan-py started at v0.1.1 (the initial v0.1.0 had shipped earlier that morning) and iterated through v0.2.0 to v0.3.0. Each version was a response to CI failures, spec gaps, and integration issues caught in the previous tag. This is what coordinated multi-repo development actually looks like.

---

The Python SDK (rcan-py)

pip install rcan

The Python SDK covers the full RCAN v1.2 surface:

Robot addressing:

from rcan import RobotURI

uri = RobotURI.build(
    manufacturer="acme", model="arm", version="v2", device_id="unit-001"
)
# rcan://registry.rcan.dev/acme/arm/v2/unit-001

AI confidence gating (§16):

from rcan import ConfidenceGate, RCANMessage

gate = ConfidenceGate(threshold=0.8)
confidence = 0.91  # from your AI model

if gate.allows(confidence):
    msg = RCANMessage(
        cmd="move_forward",
        target=uri,
        confidence=confidence,
    )

Tamper-evident audit chain (§16):

from rcan import CommitmentRecord
from rcan.audit import AuditChain

chain = AuditChain(secret="your-hmac-secret")
chain.append(CommitmentRecord(
    action="move_forward",
    robot_uri=str(uri),
    confidence=0.91,
    model_identity="Qwen2.5-7B",
))
print(chain.verify_all())  # True — HMAC-chained, forensic-grade

rcan-validate CLI:

rcan-validate config myrobot.rcan.yaml
# ✅ Config valid — conformance level: L2
#   ⚠️  L3: hitl_gates not configured (§16)
#
#    Result: valid with 1 warning(s)

By v0.3.0, rcan-validate gained --strict, --watch, and robot/node subcommands for validating live registry records. Python 3.10/3.11/3.12. → GitHub · → PyPI

---

The TypeScript SDK (rcan-ts)

npm install @continuonai/rcan-ts

The TypeScript SDK mirrors the Python API — same class names, same mental model. TypeScript-idiomatic methods may return richer objects where appropriate (e.g. verifyAll() returns { valid, count } rather than a bare bool). Works in Node.js, browser (ESM), and CDN bundle (unpkg/jsDelivr).

import { RobotURI, RCANMessage, ConfidenceGate, AuditChain } from "@continuonai/rcan-ts";

const uri = RobotURI.build({
  manufacturer: "acme", model: "arm", version: "v2", deviceId: "unit-001"
});

const gate = new ConfidenceGate(0.8);
if (gate.allows(0.91)) {
  const msg = new RCANMessage({
    cmd: "move_forward", target: uri, confidence: 0.91, modelIdentity: "GPT-4o"
  });

  const chain = new AuditChain("your-hmac-secret");
  chain.append({ action: msg.cmd, robotUri: uri.toString(), confidence: 0.91 });
  const { valid, count } = chain.verifyAll();
  console.log(`Chain: ${valid}, ${count} records`);
}

Node 18/20/22. → GitHub

---

OpenCastor: three versions in one day

OpenCastor went through three releases on March 6, each adding a layer on top of the last.

v2026.3.6.0 wired RCAN v1.2 deeply into the execution pipeline:

• Ed25519 message signing — every outbound action optionally signed with an auto-generated keypair at ~/.opencastor/signing_key.pem
• Multi-provider failover — agent.fallbacks[] with per-error-type triggering; the robot keeps thinking when your primary AI provider is down
• Fleet group policies — fleet.groups in RCAN YAML with deep-merge config resolution; different confidence thresholds for production vs staging robots
• Browser-based wizard — castor wizard --web launches full setup UI at localhost:8765; zero extra dependencies (pure stdlib http.server, no Flask or uvicorn)
• castor inspect — unified registry, config, gateway, commitment chain, and compliance view in one command

v2026.3.7.0 added §17 distributed registry infrastructure: node_resolver.py, node_broadcaster.py, RCAN doctor checks, and verification tier enforcement. This is what makes swarm peer identity work when the central registry is unreachable — every node maintains a local SQLite cache.

v2026.3.8.0 formalized the RCAN-Swarm Safety claim (see below) and added castor node and castor register --dry-run to the CLI.

---

§17: The Distributed Registry Node Protocol

The big spec addition that shipped today was §17 — the Distributed Registry Node Protocol.

A centralized robot registry is a single point of failure and a governance bottleneck. As the robot ecosystem scales, you can’t funnel every identity resolution through one server. Industrial deployments, offline facilities, air-gapped environments need the registry to work locally.

§17 specifies:

• Node delegation: Namespaced prefixes (e.g., RRN-BD-... for Boston Dynamics) can be delegated to manufacturer-operated nodes
• Federated resolution: Any resolver walks the delegation tree — root registry → namespace node → local cache
• Sync protocol: Nodes synchronize records on a push/pull basis; root wins on namespace conflicts to prevent poisoning
• Node manifest: Every node serves /.well-known/rcan-node.json — node type, operator, namespace prefix, public key, and API base URL
• Error codes 6001–6006: Standardized error taxonomy for node-protocol failures (NODE_NOT_FOUND, DELEGATION_INVALID, RECORD_SIG_INVALID, SYNC_CONFLICT, NODE_UNAVAILABLE, CACHE_STALE)

---

The new claim: RCAN-Swarm Safe

In a traditional multi-robot system, when Robot A receives a command from Robot B, there’s usually no standard way to verify whether B is who it claims to be, whether B is certified safe to operate in this context, or whether the interaction will be auditable. RCAN answers all three.

Peer identity verification via §17:

from rcan import NodeClient

client = NodeClient()
peer = client.resolve("RRN-BD-000000000042")

tier = peer.get('verification_tier', 'community')
TRUSTED_TIERS = ('verified', 'certified', 'accredited')
if tier not in TRUSTED_TIERS:
    raise SecurityError(f"Peer robot not verified for swarm commands: {tier}")

Offline resilience: The local SQLite cache in each §17 node means peer identity resolution works even when the central registry is temporarily unreachable. The swarm keeps working.

Full audit: Every swarm interaction is logged to the commitment chain — who, what model, what confidence, what timestamp.

For a robot to claim RCAN-Swarm Safe, it needs: a valid RCAN config with a registered RRN, verification tier ≥ verified, commitment chain enabled, a confidence gate with threshold ≥ 0.7, and HITL gate configured for swarm-level commands. OpenCastor v2026.3.8.0 satisfies all five criteria at the software layer. RRN-000000000001 is the first robot registered in the live RCAN registry.

---

A full CI debugging marathon

Shipping across four repos with green CI sounds simple. It took most of the day and hit every class of problem a multi-repo ecosystem can hit.

rcan-spec: Astro content collection robots/ was defined in the schema but the directory was empty — Astro throws at build time on empty data collections. Fixed by registering the first real robot (RRN-000000000001). Python code block in error-codes.astro had raw {e.rrn} — Astro treats {} as JSX expressions. Fixed with HTML entities. SDK smoke test was using import rcan from '@continuonai/rcan-ts' (default import) — rcan-ts only exports named exports.

rcan-py: test_version.py was asserting a hardcoded version string. Fixed to use rcan.__version__ dynamically. sample.rcan.yaml fixture was missing the required agent: key. spec-smoke.yml was unpacking validate_config() as a (bool, list) tuple — the function returns a ValidationResult object.

OpenCastor: Release workflow gate checks CI on the exact tag commit SHA — tag was pushed on a commit where CI wasn’t yet visible to the gate. Deleted and re-pushed the tag at HEAD (CI green). 129 unused import and sort-order lint errors in test files auto-fixed, plus E741 ambiguous variable names. test_deepseek_provider.py fails without openai installed; added pytest.mark.skipif to skip the module gracefully. Integration test was unpacking validate_config() as a tuple — same fix as rcan-py.

Every failure had a clear root cause. The pattern: when you version-bump across multiple repos simultaneously, every hardcoded version string and every assumption about return types becomes a latent bug. Fix: dynamic version checks and interface-based assertions.

---

What the Robot Registry Foundation needs

The Robot Registry Foundation (RRF) is the governance entity that should eventually own the RCAN protocol and the robot registry (now live at robotregistryfoundation.org). Here’s an honest accounting of what it needs to become real.

A legal home. The RRF charter currently explores US 501(c)(6), Swiss foundation, or EU association structures. ISO liaison status is easier to achieve as a formal legal entity. The charter is a draft — no entity exists yet and no commitments have been made.

An independent technical board with 10 voting seats across robot manufacturers (2), safety standards bodies — ISO/TC 299 and A3 (2), academic/research institutions (2), civil society (1), and foundation-at-large (3), plus non-voting government observers (e.g., NIST, EU Commission, BSI). The key insight from ISO/TC 299 engagement: RCAN should not position itself as a compliance mechanism — it provides the audit infrastructure that makes conformity demonstrable.

Manufacturer verification infrastructure. The four-tier system (community → verified → certified → accredited) is implemented in the registry API. The procedural side — actual verification procedures, test lab partnerships, accreditation body relationships — doesn’t exist yet.

Membership and operating model. The charter proposes three membership tiers: Founding Members (charter co-creators, 3-year financial commitment), Supporting Members (organizations deploying RCAN, annual dues tiered by organization size), and Contributors (individuals contributing to spec/software, no financial obligation). Specific pricing is not set — the charter is in active community drafting.

---

The full stack

rcan-ts / rcan-py          ← SDK (your app)
       ↓
  RobotURI + RCANMessage    ← addressing + commands
  ConfidenceGate + HiTLGate ← RCAN §16 safety gates
  AuditChain                ← tamper-evident audit log
       ↓
  OpenCastor runtime        ← runs on the robot
  (Ed25519 signing, failover, fleet policies, §17 node)
       ↓
  robotregistryfoundation.org ← global RRN, verification tiers

Everything is open source. The protocol spec is CC BY 4.0. The SDKs are MIT. The runtime (OpenCastor) is Apache 2.0. If you’re building AI-driven robots, register yours and start using the protocol. The earlier you adopt, the less you’ll have to retrofit.

rcan.dev/quickstart →