Notes on running two product families in parallel
Two product families are maintained from this account through 2026. They share no source code, no authentication boundary, no brand, and no roadmap. They share an operator and a single shared interchange format. This post documents their structural shape and the rule by which they resolve conflict.
The two families differ deliberately. Conflating them — shared internals, shared brand, shared release cadence — would couple decisions whose constraints diverge. The OpenCastor robotics ecosystem operates as a standards-and-runtime stack: open spec, neutral registry, open-core runtime. The PlatAtlas cognition-tooling family operates as an open-core team product: MIT public tier, paid private tier, no standards body. Each has its own canonical document; neither supersedes the other.
Family A: robotics
The OpenCastor ecosystem maintains six layers, each in its own repository.
| Layer | Repository | Role |
|---|---|---|
| 5 | continuonai/rcan-spec + rcan-py + rcan-ts | RCAN protocol specification and language SDKs |
| 1 | RobotRegistryFoundation/robot-md | Declarative manifest schema and CLI (PyPI robot-md 1.10.4) |
| 1→2 | RobotRegistryFoundation/robot-md-mcp | MCP server exposing ROBOT.md to any MCP-aware agent (npm robot-md-mcp 0.5.0) |
| 3 | RobotRegistryFoundation/robot-md-gateway | Enforcement gateway with default-deny, systemd-hardened (PyPI robot-md-gateway 0.5.0a3) |
| 4 | craigm26/OpenCastor | Open-core productized runtime |
| 6 | craigm26/RobotRegistryFoundation | Neutral identity and evidence registry at robotregistryfoundation.org and rcan.dev |
The reference robot for the ecosystem is bob-spec-b-pick-place — a 6-DoF SO-ARM101 follower arm with Feetech STS3215 servos on a Raspberry Pi 5 (BCM2712, Cortex-A76 quad-core, 16 GB RAM, ARM64), registered as RRN-000000000011 (RRF record: https://robotregistryfoundation.org/v2/robots/RRN-000000000011). Bob’s manifest declares the feetech driver on /dev/ttyACM0, six declared video devices (an oakd primary OAK-D in the world frame plus an oak-d-lite-1 secondary, plus rpi-hevc-dec-video19 and three pispbe-video20/21/22 Raspberry Pi-side ISP backends), capabilities arm.pick, arm.place, arm.reach, arm.home, and status.report, and two HiTL gates at scopes destructive and system (both with require_auth: true). Safety envelope: max joint velocity 180 deg/s, payload ≤ 0.5 kg, software E-stop with 100 ms response budget.
Three certification tracks attach to the layer model and are cumulative: L1–L4 Protocol Conformance (normative now), Gateway Authority (normative once the gateway and runtime both pass), and HIL Runtime Safety (normative once the first reference robot class passes hardware-in-the-loop testing). Conformance is self-asserted via signed bundles, independently replayable from those bundles. Third-party certification is intentionally out of scope for the foundation in 2026.
Four deployment patterns are adopted, each with a distinct claim envelope: Declaration-only (manifest alone — Layer 1 surface, no runtime, no physical-safety claim attaches), Gateway Mode (Layer 3 enforcement gateway only — physical safety attaches at the gateway), OpenCastor Full (Layer 4 productized runtime — gateway + drivers + fleet + cloud + UI), and Regulated overlay (any of the above plus the compliance evidence chain for jurisdictions that require it). Three load-bearing limits apply across all four: conformance is not certification; RRF submission produces evidence, not regulatory sufficiency; declaration alone does not enforce safety.
What the runtime safety layer actually enforces, at the Layer-3/Layer-4 boundary: physical bounds (speed limits, workspace boundaries, torque caps), anti-subversion detection (monitors model outputs for prompt-injection attempts), work authorization (RCAN role-based access — Owner / Leasee / Observer), a tamper-evident audit log (cryptographic chain of every action and decision), hardware and software E-stop, rate limiting (prevents runaway API calls and action floods), and a watchdog timer (auto-stops if the brain becomes unresponsive). Safety modules are not feature-flagged; they are structural.
A driver hierarchy lives alongside the layer stack: hardware-specific actuator packages register as robot_md_gateway.actuators entry points and load lazily when a manifest references them. Two are published in 2026: so-arm101-actuator 0.2.2 (servo control plus inverse kinematics for the SO-ARM101) and oak-d-actuator 0.2.1 (DepthAI perception, depth-band bowl detector).
The signing algorithm across the layer stack is ML-DSA-65 (NIST FIPS 204). Manifests, conformance bundles, and registry records are signed with the same primitive. Ed25519 is retained as an optional companion signature during the migration window per the 2026-05-04 crypto-profile freeze, which set protocol_version = 3.2.0 as canonical, ML-DSA-65 as required on every signed envelope, and Ed25519-only envelopes as rejected by v3.2 verifiers.
The protocol itself defines ten message types — INVOKE, INVOKE_RESULT, TELEMETRY, COMMITMENT, SAFE_STOP, ESTOP_PREEMPT, HEARTBEAT, KEY_ROTATE, REGISTRY_RESOLVE, REGISTRY_REGISTER — with a CI-enforced round-trip test ensuring rcan-py and rcan-ts SDK enums never drift from the spec. Evidence packaging follows the RCAN Audit Bundle v1.0 schema: a single signed envelope wrapping per-artifact signatures (cert-l1-l4, gateway-authority, hil-runtime, EU AI Act §22–§26 packets, version snapshots) plus an aggregator signature, replayable in two modes — strict (verify every inner artifact against its registered key) or aggregator-trust (verify only the bundle signature).
Family B: cognition tooling
The PlatAtlas family maintains three pieces. They differ in audience, license, and adoption path.
| Piece | Repository | Visibility | Distribution | Role |
|---|---|---|---|---|
mcp-tape | craigm26/mcp-tape | Public, MIT | npm mcp-tape 0.3.0 | Stdio proxy that records MCP JSON-RPC traffic to JSONL. Optional --upload posts to the team product; --public echoes a shareable viewer URL on upload. |
mcp-replay | craigm26/mcp-replay | Public, MIT | mcpreplay.dev | Static-page renderer for JSONL traces. Four views: Timeline, Tools, Calls, Raw. Diff-view via ?diff=a;b. |
workflow-atlas | PlatAtlas/workflow-atlas | Private | platatlas.com | Multi-user paid team product. Atlas overlay plus team-aggregated trace ingestion. |
The trace format is documented at mcpreplay.dev/docs/format and stable at v1. Any producer or consumer can implement it. The format includes a non-MCP-producer extension and an RCAN bridge schema so traces emitted by the robotics-side gateway will eventually render through the same viewer.
The split is structural. mcp-tape and mcp-replay ship MIT to maximize adoption among individual MCP users. workflow-atlas ships paid and private because its differentiating features — multi-member trace aggregation, declared-atlas-overlaid-with-real-execution, per-member attribution, audit trail — require team-scoped state that the free tier does not have. The same .jsonl atom flows through all three: an individual debugs locally on the free tier; a team aggregates across members on the paid tier; an organization rolls up across teams on an enterprise tier.
The product family was renamed from workflow-atlas (org craigm26, domain workflowatlas.cc) to PlatAtlas (org PlatAtlas, domain platatlas.com) on 2026-05-15. The old domain redirects 301 via a Cloudflare Worker. The hosted runtime at platatlas.com went production-live on 2026-05-19, with end-to-end GitHub OAuth verified against the Worker deploy.
The shared format and the resolution rule
The two families intersect at one structural point: the JSONL trace format. robot-md-gateway instruments tool invocations, and the integration design routes those instrumentation events through the same schema mcp-tape writes. The contract lives in workflow-atlas/docs/integration-opencastor.md and is owned by the format, not by either family’s source tree.
When the two canonical documents touch the same surface — rare; the families intentionally do not overlap — the resolution rule is newer wins, within shared scope only. Disagreements within the same date tier, or items not addressed by either canonical, are surfaced as open questions in the document whose scope is more central. The index between the two is a directory, not a source.
Out of scope
A third project, the Flutter consumer application Heat Compass (repository craigm26/HeatSentry), is neither canonical. It implements the US Marine Corps Order 6200.1E heat-flag system over two complementary WBGT calculators (Stull 2011 and the full Liljegren radiation model), with on-device Gemma 3n inference via flutter_gemma. The 2026 timeline for Heat Compass is covered in the shipped log post.
Posts in this series
- This post.
- Four artifacts that externalize agent state — a unified frame for
CLAUDE.md,ROBOT.md,atlas.md, and the JSONL trace. - Shipped log: 2026 through mid-May — a topical roll-up.