When we shipped RCAN v2.2 in late March, the spec was complete but the implementation wasn’t. A compliance audit identified 17 gaps across the CLI, gateway, Flutter client, and SDKs — things like missing envelope fields on messages, no delegation chain management, no training consent API, and the MCP server having no spec foundation. We closed all 17 in a single sprint.

The audit

A systematic pass against the v2.2 spec produced 17 issues filed across 5 repos: OpenCastor (#776–785), rcan-py (#45), rcan-ts (#38), rcan-spec (#185, #186), and opencastor-client (#39–44). Not bugs — gaps. The system worked, it just didn’t surface everything it should.

Envelope fields (§4)

RCANMessage now carries the full v2.2 envelope: firmware_hash, attestation_ref, pq_sig, pq_alg, delegation_chain, and media_chunks. These were in the spec but missing from the Python dataclass. The SDK and gateway both validate them now.

Compliance levels L4 and L5

castor compliance now accepts --level L4 (RCAN v2.1 supply-chain checks: firmware manifest, SBOM, authority handler) and --level L5 (v2.2 adds ML-DSA-65 PQ signing verification). Bob currently holds L5 — the highest compliance tier.

New CLI commands

The sprint added five new command groups:

• castor revocation — status, poll, cache
• castor consent — list, show, grant, deny, revoke, export, training
• castor delegation — show, verify, depth
• castor key-rotation — status, rotate, verify
• castor mcp — token, clients, install (shipped earlier this week)

Training consent API (§23)

The spec now documents the full training data consent REST interface including GDPR Art. 17 right-to-erasure and 7-year audit log retention per EU AI Act Art. 12. The Flutter consent screen has matching UI: scoped “Request Access” and “Training Data” tabs with per-subject delete.

Delegation chains (§delegation, §22.9)

RCAN v2.2 supports delegation chains — when a human operator delegates authority to a robot, or when one robot delegates to another, the chain is cryptographically verifiable up to a depth of 3. The MCP spec now distinguishes between human-configured MCP clients (no chain needed — the token is pre-authorized) and robot-to-robot MCP (requires a DelegationHop chain). The /.well-known/rcan-keys.json JWKS endpoint publishes the robot’s public key for external verifiers.

Flutter RCAN screens

Six screens updated to surface v2.2 data: Identity (RURI, revocation status, PQ key), Conformance (L4/L5 checks), Consent (GDPR-compliant training data consent), Mission (scope badges on message bubbles), Safety (live revocation poll lag + replay cache), Hardware (multimodal capability row).

The MCP server is live

Connect Claude Code to Bob:

claude mcp add castor -- castor mcp --token $CASTOR_MCP_TOKEN

14 tools across 3 LoA tiers. Every mutating call is signed with Bob’s ML-DSA-65 key and validated against the RCAN v2.2 envelope.

Versions

Package	Version	Tests
OpenCastor	v2026.3.29.1	255
rcan-py	v1.2.3	681
rcan-ts	v1.2.3	553
rcan-spec	v2.2.1	101
opencastor-client	v1.4.4	—

All repos at 0 open issues.