ORC · Systems Infrastructure — Agent Mesh Substrate
Orchestration Serialization Engine
An in-process agent-mesh substrate in stable Rust (1.75 or newer): a Cargo workspace of six library crates plus a reference operator crate.
Maturity. Vlaander's internal review (7 October 2026) found two medium-severity defects that are present in the source delivered today: Spawner::spawn can return Ok for a task that never runs if it races Scheduler::shutdown, and a panic inside an operator node's turn leaves that node permanently unscheduled. The source you receive contains both defects.
Overview
Six library crates: orc-core (typed IDs, a hybrid logical clock and a shared error type), orc-arena (a bump arena with an atomic compare-and-swap cursor), orc-codec (versioned archives with a header carrying magic, schema id, version and length, then the body and a CRC-32), orc-state (an epoch-versioned key/value store with copy-on-write snapshots and optimistic transactions), orc-router (bounded mailboxes with four strict-priority tiers and topic fan-out) and orc-sched (a work-stealing thread pool on std::thread, built on crossbeam-deque). A seventh crate, orc-operator, wires them into a reference four-node drain and carries the orc-operator and orc-bench binaries.
Key properties are each covered by a named test. Resetting the arena needs exclusive access, so a reference into it cannot outlive a reset; two compile-fail doctests check this. Clock timestamps keep increasing when the injected wall clock goes backwards. The decoder rejects a wrong schema, wrong version or bad CRC with distinct errors, and rejects truncation, trailing bytes and bad magic. A concurrent test checks that readers never see a partially applied multi-key transaction. Topic fan-out shares one reference-counted allocation instead of copying the bytes.
Not included: network transport, cluster membership or consensus, durable persistence, an async runtime, a multi-tenant security model, and metrics or tracing exporters. ORC is a single-process library; these are left to the application that embeds it.
The problem
An in-process agent mesh needs an allocator, logical clocks, a versioned message format, shared state with consistent reads, prioritised mailboxes and a thread pool before any domain logic can run. ORC provides these as one tested Rust workspace for a single process.
What it does
- Six library crates: identity, clock and errors; bump arena; versioned archive codec; epoch-versioned state store; four-tier priority router; work-stealing scheduler.
- A reference operator crate with a four-node drain binary (orc-operator) and a benchmark binary (orc-bench).
- Arena reset takes exclusive access, so a reference into the arena cannot outlive a reset (checked by compile-fail doctests).
- Hybrid logical clock timestamps that keep increasing when the wall clock goes backwards.
- Archives with a wrong schema, wrong version or bad CRC-32 are refused with distinct errors. CRC-32 detects corruption, not deliberate tampering.
- Snapshot-isolated state reads: a concurrent test checks that no partially applied transaction is observable.
- Topic fan-out shares one reference-counted payload instead of copying bytes.
Performance
Measured 2026-10-05| Metric | Figure | Basis |
|---|---|---|
| Four-node drain | About 640,000–700,000 payloads per second (medians of separate orc-bench invocations, 4 workers) | Measured by Vlaander |
| Codec round-trip, single thread | About 6,800,000 records per second (encode, then fully verified decode; recorded medians 6,829,866 and 6,862,226) | Measured by Vlaander |
| Test suite | 66 tests (58 unit, 2 end-to-end, 6 doctests), 0 failures on Rust 1.75 and 1.83 | Measured by Vlaander |
| Lint | No findings under clippy::pedantic with warnings denied, on Rust 1.75 and 1.83 | Measured by Vlaander |
- Date
- 2026-10-05
- Hardware
- AMD EPYC 7763, GitHub Codespace (shared Azure VM), 4 vCPU (2 cores), 15 GiB
- Toolchain
- rustc 1.83 (and 1.75 for the minimum-version check), official rust:*-bookworm images, --locked --offline
- Source archive SHA-256
- c0ca0059db3c0c66d4d0a3b33b78d6630713da36a61250b46f9f7ef491ec511f
- Method
- Built from the delivered source archive. orc-bench, run several times; each invocation does one warm-up and five timed runs and reports the median. Drain: 200,000 payloads with 64-byte bodies, 64 keys, batch 256, 4 scheduler workers, timed from first injection to idle, including producer-side encoding. Codec: 2,000,000 records with 64-byte bodies on one thread.
- The machine is a shared cloud VM (a GitHub Codespace); expect about ±10% run-to-run noise.
- The drain uses one scheduler worker per available CPU by default, so it is slower on fewer cores. Vlaander's internal re-run on 2 vCPUs of the same CPU type, under load, gave 307,000–382,000 payloads/s on the drain and 5,860,000–6,150,000 records/s on the codec. The drain figure has not been re-run on 4 vCPUs since.
- In the same internal review, the codec ran at roughly the speed of bincode 2 with the same CRC-32 framing, and the four-node drain ran about 4.3 times slower than an equivalent pipeline built on crossbeam-channel and std threads on the same 2 cores. ORC does more per record (clock stamping, priority mailboxes behind a mutex, a store commit per batch); which of these costs most has not been profiled.
- The catalogue's earlier figures (about 70,000 payloads/s and 2,200,000 records/s) were not measured on this code and are withdrawn.
- The state store copies its key map on every commit, so it suits small control state, not large data sets.
- The router uses strict priority: sustained high-priority traffic can starve lower tiers.
Value in your own metrics
- Supply-chain / dependency surface
- 2 direct dependencies (crossbeam-deque, crc32fast) and 5 third-party crates in the resolved tree, all MIT OR Apache-2.0, pinned by a committed Cargo.lock and listed in SBOM.md.
- Memory-safety surface
- Every crate except orc-arena forbids unsafe code. orc-arena has 4 unsafe sites, each with a SAFETY comment; its tests pass under Miri.
- Scope delivered
- Arena, logical clock, codec, state store, router and scheduler in one workspace, with a reference operator that exercises them together end to end.
Assurance and build
- Language
- Rust 1.75+ (stable)
- Build
- clippy::pedantic with -D warnings: no findings on Rust 1.75 and 1.83 (2 mut_from_ref allows in the arena, each justified). Rust 1.99's clippy reports 4 findings from newer lints
- Memory safety
- #![forbid(unsafe_code)] in every crate but orc-arena; its 4 unsafe sites carry SAFETY comments; Miri reports no undefined behaviour in its tests
- Tests
- 66 (58 unit, 2 end-to-end, 6 doctests), all passing; about 0.2 s without doctests, about 1 s with them
- Dependency surface
- 2 direct, 5 in the resolved tree · all MIT OR Apache-2.0 · SBOM.md
- Internal review
- Vlaander quality gate, 7 October 2026: 0 critical, 0 high, 3 medium, 3 low findings. Not fixed in the delivered source: the scheduler shutdown race and the stranded operator node (both medium), a frame-length overflow in the decoder on 32-bit targets such as wasm32, and a panic in Mailbox::recv_timeout with Duration::MAX. Also open: drain throughput (medium), and CRC-32 being described as integrity in a crate manifest
- Source archive SHA-256
- c0ca0059db3c0c66d4d0a3b33b78d6630713da36a61250b46f9f7ef491ec511f
Releases are not yet cryptographically signed, and no release manifests or external audit summaries are published. Check the source tarball you receive against its SHA-256 in Schedule 1 of your Sale and Assignment Agreement, which you see before you sign.
Scope and maturity
What is real today, what is deliberately excluded, and what is pending — published unprompted.
Included today
- All six library crates and the reference operator crate, with README, ARCHITECTURE, BENCHMARKS and SBOM documents.
- 66 tests, including an end-to-end four-node drain that checks exactly-once delivery, rejection of corrupt archives and per-key order; no clippy::pedantic findings on Rust 1.75 and 1.83.
- A resolved dependency tree with no copyleft licence in it.
Explicitly scoped out
- No network transport, cluster membership or distributed consensus.
- No durable persistence, async runtime, multi-tenant security model, or metrics and tracing exporters.
- CRC-32 detects accidental corruption only. Archives carry no keyed MAC or signature, so anyone who can modify an archive can make it pass.
Pending
- The two medium defects in the maturity notice (scheduler shutdown race; operator node stranded after a panic) are not fixed in the delivered source.
- Two low-severity fixes are also unpackaged: decoder frame-length overflow on 32-bit targets (wasm32), and Mailbox::recv_timeout panicking on Duration::MAX.
- Reported but not reproduced by the review: clock wrap at u64::MAX in extreme settings, Store::commit accepting a transaction from another store, a malformed archive with a valid CRC counted as neither delivered nor rejected, and degenerate drain settings that can overflow or exhaust memory.
- No cargo-deny or cargo-audit configuration; RustSec advisory status has not been checked.
- Drain throughput has not been profiled or optimised; it is about 4.3 times slower than a plain crossbeam-channel pipeline in Vlaander's same-machine comparison.
Who it's for
- AI agent-platform companies building an in-process orchestration layer in Rust.
- Infrastructure vendors wanting a permissively licensed, low-dependency Rust core beneath a proprietary product.
- Teams with a strict supply-chain posture, where five third-party crates with no copyleft is a requirement.
Before you buy
- Confirm that transport, persistence, consensus, async runtime, security model and observability are ones you intend to own.
- Plan to fix the open findings yourself; the delivered source does not contain fixes for them.
- Treat the measured figures as valid for the machine above only; drain throughput depends on core count and is behind a plain channel pipeline.
- Review the SAFETY comments on the four unsafe sites in orc-arena as part of code diligence.
- Verify the SBOM and the copyleft-free claim with your own licence-scanning tooling, and run cargo-audit.
What transfers
- The asset's sourceSubject to the Sale and Assignment Agreement, Vlaander assigns to the verified Buyer the transferable right, title and interest that Vlaander owns in the specified Asset. The assignment excludes Third Party Materials, open-source components, Vlaander’s pre-existing tools, generic know-how, development methods, trademarks, confidential information and any rights that cannot lawfully be assigned.
- Its testsThe test suite the published assurance claims rest on, as delivered in the source archive.
- Its audit artefactsSpecifications, model-checking output, reviews and the software bill of materials, where the asset has them.
- Not includedThird-party and open-source materials are not sold or assigned by Vlaander. They remain under their own licences, listed in each asset’s software bill of materials (SBOM.md in the archive), and the Buyer is responsible for complying with those licences.
First described in: VLA-GEN catalogue, 3 August 2026, §3.8. Revised by Vlaander against the delivered source; every figure is labelled with its basis.
From test to source
- 01
Check
Read the engine's page: what Vlaander measured and on which hardware, what it has not measured, and the open review findings. Nothing runs before purchase.
- 02
Buy
Verified businesses only. Place the order, give your company's details, have your authorised signatory sign the Sale and Assignment Agreement, then pay the invoice in naira by bank transfer, or in USDC on Polygon. Once the payment is verified, your account shows Paid.
- 03
Receive
We confirm the funds and release the source tarball to you. Delivering, then Download ready. Check it against the SHA-256 in Schedule 1, then rerun the tests and benchmarks yourself.