CBCL — architecture overview
The Rust implementation of CBCL: a self-extensible, formally verified agent communication language that occupies the deterministic context-free (DCFL) sweet spot between fixed-vocabulary ACLs (KQML, FIPA-ACL) and unrestricted JSON/NL.
The workspace is a strict purity-zoned Cargo workspace — pure deterministic core crates under #![forbid(unsafe_code)] + no_std + alloc, surrounded by effectful shell crates. Parallel to the Rust workspace lives lean-cbcl/, a Lean 4 formalization that machine-checks safety properties (R1–R5) of the core algorithms with zero sorries.
Companion paper: CBCL @ IEEE S&P 2026.
Four views
- Overall architecture — workspace structure: pure core, effectful shells, Lean proofs.
- Message pipeline — the fixed sequence every message traverses: parse → parse_message → validate → expand → causal-verify → shape-check → success.
- Command surface — the
cbclCLI: parse, verify, agent, simulate. - Extension points — dialect installation and gossip; how agents define new vocabulary at runtime without escaping DCFL.
Load-bearing properties
- Strict purity boundary (ADR-004, PURITY-MAP).
cbcl-coreandcbcl-parserare deterministic,no_std + alloc,#![forbid(unsafe_code)]. Effectful code (I/O, CLI, WASM/FFI/NIF, simulation) lives in shell crates that import the core — never the reverse. - Five runtime safety constraints:
- DCFL closure under fresh-named dialect installation (Lean theorem
dcfl_preservedinlean-cbcl/LeanCbcl/DeterministicUnion.lean). - Fail-closed pipeline (REQ-231) — no path returns success unless every step succeeded.
Source
Architectural data exported from cbcl-rs/.omm/. Each view here has a Lean counterpart that proves its key properties; drift between the Rust implementation and the Lean formalization silently invalidates artefact integrity, so any safety-critical change must update both sides.