Skip to content

Mercury Composable for Rust

Mercury Composable lets you build backend applications as composable, event-driven systems — and, increasingly, as Active Knowledge Graphs you evolve by editing a model rather than rewriting code. Functions are fully decoupled — they know each other only by route name, wired through event envelopes — so orchestration is configuration, not code. This is the official Rust implementation: the event-driven core descends from the Scala/Akka actor model, realized here on tokio async/await, with the canonical Java engine as the behavior specification — same three layers, same flow YAML, behavior-synced release by release.

Get started Read the white paper View the deck The Mercury Family

The white paper — Intent-Driven Development and the Architecture of Human-AI Collaboration — presents the collaboration model the AI era needs and the Mercury story that proved it: shared memory, AI grammar, and governed execution; the deck tells the same story in slides. This repository is the methodology's founding proof point: AI-enabled before its first line of code.

A layered ascent

Mercury grew in three layers. Each builds on the one beneath it, and you can mix them in a single application — drop down a layer exactly where you need more control, and no further.

Layer You express behavior as… What you write
Event-driven — Platform Core decoupled functions reacting to events Rust functions, addressed by route name
Composable — Event Script YAML flows that choreograph functions ~50% config, 50% code
Semantic — Active Knowledge Graph a graph whose nodes execute during traversal a model — little or no code

Knowledge Graph as application

The newest layer is a paradigm shift: model business intent, enterprise knowledge, and system behavior as one executable Active Knowledge Graph. Behavior runs as the graph is traversed, so changing what a system does means refining the model, certifying it, and deploying the updated model — not rewriting and redeploying code. Humans and AI companions co-author the same model in a live Playground.

Why a Rust port

The same destination as the Java engine, re-reached in Rust: AI-assisted Semantic Application Development, on a lightweight, fast foundation (the ported event bus benchmarks at ~155K RPC ops/s at 6 µs round-trip). The port is faithful by design — the Java project remains the canonical behavior specification (map, don't mirror) — with deliberate, documented divergences where the platform differs (tokio instead of virtual threads, compile-time registration instead of classpath scanning, no Kafka service mesh, no Spring).

Building with an AI agent

Mercury's DSLs ship agent-ready specifications — a rule-based grammar plus a machine-readable catalog — so an AI agent can generate correct artifacts deterministically, without inferring from examples or reading engine source:

A machine-readable map of the whole site lives at llms.txt — engine-verified; a fresh agent can build graphs from it with zero out-of-band context.

Explore the docs

Project

Rust port

Throughout this site, boxes like this mark the places where the Rust port deliberately differs from the Java original — no silent divergence.