Every answer current. Every fact accountable. Every world forkable.
Every major database of the last two decades — ClickHouse, Snowflake, Elasticsearch, MongoDB — shares one assumption: an answer must be recomputed to be trusted. You ask; the engine scans; you pay O(data), every time, forever. MutinyDB is the mutiny against that assumption.
In MutinyDB, a query is a standing computation: it compiles once into an incremental circuit and stays continuously correct as changes flow through it. Keeping an answer right costs O(change). Reading it costs a lookup. And because the storage engine's commits are the change feed, there is no CDC pipeline, no lag ambiguity, and no moment where the dashboard and the database disagree.
It is built for the client that breaks every database designed for humans: the AI agent — which asks the same questions at machine frequency, derives facts from sources that can turn out to be poisoned, and needs to try three hypotheses without committing to any of them.
SELECT m.claim_id, m.confidence, e.event_id, r.revenue_impact
FROM memory.claims AS m
JOIN events.telemetry AS e ON e.session_id = m.session_id
JOIN analytics.rollups AS r ON r.account_id = m.subject_id
WHERE e.embedding ≈≈ 'the tool call timed out and we retried' -- meaning, ranked and bounded
AND r.period = '2026-Q3' AND e.cost < 0.02 -- scalars
AS OF BRANCH 'session-7841' -- the agent's world, not main
AND NOT TAINTED BY SOURCE 's:scraped-page-77' -- provenance, as a predicate
LIMIT 20;Meaning, scalars, branch scope, and provenance in one plan — and the answer is standing: it maintains itself as data changes, on the agent's own fork of the world. This exact combined SQL syntax is the north-star dialect, not a v0.1 claim: v0.1 deliberately refuses these extension tokens by name instead of accepting and ignoring them. The same capabilities are executable today through the standing-SQL, typed semantic, branch, provenance, and MCP doors demonstrated below; the combined binder remains the next language milestone.
Commit-as-delta. Every incremental engine's weak point is change capture; every deployment bolts on a fragile CDC layer. Here the storage engine emits deltas as a physical byproduct of committing: one commit = one compute epoch, audited page-against-capture, exactly-once by content address. The durability boundary and the visibility boundary are the same boundary.
Taint-as-retraction. A write records what it derived from — enforced at the write path, not as
skippable middleware. When a source turns out to be poisoned, taint(source) retracts it through
every standing computation: reversible answers repair themselves by the same propagation that
keeps dashboards current, and irreversible external actions are listed first, with receipts and
registered compensations. Other databases answer "we don't know what it touched." This one
un-touches it.
Forked standing state. A session is a branch of the database — the data forks in O(1) on a content-addressed store. An agent tries hypotheses on branches, each with its own branch-scoped, continuously-current answers, merges the winner's divergence under policy re-run, and rewinds the rest — auditable, never destroyed. Honest economics, per MD-5: at v1 the standing answers fork by hydration — O(state), measured and published (ledger) — and O(1) fork of live answers is post-v1 work on the engine's own track, with the spike's copy-on-write measurements as its baseline.
Five planes, directed dependencies, enforced by an allowed-edge matrix read from the build graph — not by convention:
fleet/ops ─► trust ─► compute ─► semantic ─► storage
│ ▲
└───── bridge ────────┘
- Trust (from LoomDB): branches, write envelopes, provenance, claims, policy — and a propose-not-execute action gateway where the agent handle has no execute method, by type.
- Compute (from Schweep): DBSP-style standing circuits, epochs, shared subplans — the ten-thousandth near-duplicate query costs a sliver of the first.
- Semantic (from PrismDB): bounded semantic operators inside compute, plus an immutable, meaning-clustered cold tier with exact-oracle-measured recall.
- Storage (substrate): content-addressed pages, one WAL, O(1) fork/snapshot/rewind, sleep/wake to object storage.
- Fleet/ops: tenant pools, registry, sleep/wake economics — a million idle databases cost the price of their bytes.
Binding contracts: CONSOLIDATION-ROADMAP.md ·
docs/decisions · MD-6 (one-repository topology with
exact source provenance) · docs/ADOPTION-ROADMAP.md (product and
ecosystem milestones).
Each plane arrives from a codebase with its own public evidence record. No claim is inherited
merely because a component repository made one about itself — a component stays quarantined
until its exact release and the composed product gates pass, and
scripts/verify_component_lock.py refuses an unreleased or
blocked component marked admitted. That distinction is enforced, not editorial. As of
2026-08-31 all four components are release-admitted at exact release tags; the composed
evidence of record is main CI run
33384670142 (every job
green, including all four component-compatibility jobs, the M1 bridge gate, and the M3
mounted-oracle job). The two named open items are
#18 (engine-track, post-v0.1) and
EXT-KMS (MD-7, production-blocking only).
| Component | Product role | What its own gates prove | Imported state | Admission |
|---|---|---|---|---|
| substrate | storage | 98 ns fork · 50,000 randomized crash-recover cycles · airgap by compile-time amputation | substrate-v1.6.0 (44480f5) |
release-admitted — the composed workspace compatibility gate and the M1 bridge gate over the real substrate-wal are green on main (run 33384670142) |
| LoomDB | trust | record-level merge under four model oracles · taint → two-section RecallPlan · flat-memory soaks | loomdb-v0.5.1 (9c2934b) |
release-admitted — the trust plane is mounted behind the admission boundary (M3), and all four Loom model oracles run unmodified and green on the imported tree in the same job (run 33384670142) |
| PrismDB | semantic | byte-identical answers across 1/2/4-shard layouts · encryption: nothing legible at rest, rotation without rewriting a part byte | prismd-v0.1.0 · prism-shard-v0.1.0 · model-service-v0.1.0 (all at cef63ea) |
release-admitted, production-blocked on EXT-KMS custody (MD-7): the KMS provider is implemented and gated, but every gate run used the software keystore — live custody is unproven, and EXT-KMS blocks any production-approval claim (not the release) until a real key service produces the receipts; the lock verifier refuses a production-approval marking without that receipt, and refuses release admission if any of the three artifact tags is absent |
| Schweep | compute | every answer proven against a from-scratch oracle · 1,000 real SIGKILLs with 24,219 acked appends exactly-once · 2.16 GB of operator state under a 128 MiB memory ceiling | current-v0.1 (fa3b3ab), published 2026-08-30 |
release-admitted — the C13 release contract closed on 7 consecutive qualifying scheduled nights; the tag's tree differs from the previously audited 220bf6b snapshot only in evidence, verifier, and guard-test files (confirmed by diff at re-pin: docs/PROGRESS.md, scripts/verify_c13_release.py, testing/differential/tests/c13_release_contract.rs, testing/evidence/c13-nightly-streak.json). #18 is NOT in this tag: the snapshot DEDUP index still grows O(commits-ever); the fix lands post-v0.1 on the engine's track and a further re-pin follows — until then the nightly soak stays deliberately red carrying it, with the index size printed beside the verdict |
-
M1 — the bridge. One storage commit → one compute epoch; a real Loom envelope required at admission; write-set captured in the same substrate transaction; physical pages audited against captured logical changes; crash-proven across every append/seal seam. Randomized histories through the bridge remain byte-identical to an independent direct-ingest control.
-
M2 — the semantic path. Generation-pinned embedding in the bridge, bounded incremental top-k, mergeable semantic grouping, dual-generation cutover, cold one-shot routing — a frozen hybrid corpus traverses all of it and matches real PrismDB exact and rerank answers bit-for-bit.
-
M3 — the mounted trust plane. Loom capability checks over branch-scoped standing results; branch-result isolation gated; the scripted MCP demo green; all four Loom model oracles run unmodified against the mounted configuration; the agent handle contains no action gateway.
-
M4 — cross-circuit taint. One
taint(S)call resolves the poisoned source's downstream through themutiny_derivationstanding relation (a query, not a DAG walk, transitive across branches), retracts it through Schweep's C11 predicate-scopedretract_source, and memory claims, analytical rollups, and branch-scoped semantic answers all correct themselves. The frozen, checksummed incident corpus proves the healed world byte-identical to an oracle that never ingested the source; the two-section RecallPlan leads with the executed action's receipt; untainted branches and bystander tenants are untouched; taints compose; and the taint path killed at every seam resumes without ever half-healing. -
M5 — forked standing state, honestly. The spike ran first against MD-5's pre-committed criteria; the verdict took the fallback deliberately. A durable fork hydrates the child's standing answers from the parent — O(state), measured, asserted by the gate so the O(1) claim cannot quietly return — both branches maintain independently, merge follows Loom's law (policy re-run at merge time, all-or-nothing, marker-deduplicated so +3 never becomes +6), rewind returns the state accounting exactly to baseline, recovery replays the lineage to byte-identical answers through injected mid-fork and mid-merge crashes, and one taint call heals the parent and the fork's inherited state on the forked incident corpus.
-
M6 — one surface.
mutinyd: every plane behind one admission boundary (per-tenant quotas, round-robin fairness, envelopes unbypassable) and three doors — HTTP-SQL, typed, and MCP — holding the same-door law composed: identical plans, identical counters, and an admission ledger every door must appear in. The flagship incident runs end-to-end over MCP by a scripted agent (the supported demo form; the M4 dev binary is retired); the MCP tool registry has no execute and no taint by construction. Reliability at the composed level: a real SIGKILL matrix under concurrent ingest+query+subscribe+taint load (1,000 kills nightly, exactly-once, no double epoch to subscribers, recovery equals the never-crashed twin) and a soak gating memory flat in shape and budget with taint-as-retraction as the boundedness mechanism. Correction (issue #12): the flat-memory claim as originally stated here was true at PR scale (25 s) and falsified at the nightly window (1,500 s) by the first nightly ever run — capture-history storage grows O(commits) while a tenant is awake, because nothing compacted it. The finding is preserved in #12; the M8 maintenance work closes it, and the soak stayed red — deliberately — until it did. The quickstart below runs verbatim in CI.mutinydis now the v0.1 developer-release binary: distributable and supported for evaluation. The production-only external-KMS custody gate remains explicit indocs/M6-SURFACE.md. -
M7 — the fleet plane. Tenants register, sleep, wake, and are removed without a restart, from a durable registry a crashed
mutinydrecovers. Sleep = drain → compact → checkpoint → close: a sleeping tenant is bytes plus a registry row, with the resident footprint asserted, not described. Wake is O(checkpoint + suffix), not O(history) — the plane checkpoint holds standing-state membership (every held row is a live engine row, so nothing serialized can drift from the log) — and wakes byte-identical to a never-slept twin. Wake-on-delta is selective at both granularities, counter-asserted: a delta wakes its tenant and provably not the others, and within the tenant only the circuits that read its table emit — with the delta→circuit mapping observed from the compute plane's own registration file through its public binder (MD-1 R2's inversion, exactly as anticipated). Taint composes across sleep. The fleet simulation puts 10,000 sleeping tenants on one host under a cgroup ceiling and publishes p50/p99 wake-to-first-answer (below).
Details: docs/M1-BRIDGE.md · docs/M2-SEMANTIC.md ·
docs/M3-TRUST.md · docs/M4-TAINT.md ·
docs/M5-FORKS.md · docs/M6-SURFACE.md ·
docs/M7-FLEET.md
Two different questions, answered separately and labeled:
| Path | Number | Conditions — read them |
|---|---|---|
| Composed fleet wake (this repo's sim) | p50 72 ms / p99 407 ms wake-to-first-answer, 10,000 sleeping tenants at ~74 MB RSS under a 2 GiB cgroup ceiling (crates/mutinyd/evidence/m7-fleet-sim.json) |
same-host, local filesystem, release mode, nightly fleet-sim-10k CI job under systemd-run MemoryMax=2G; wake = engine snapshot+suffix open + membership hydration + one waking write + first standing answer; an uncapped macOS run corroborates in the same ledger |
| Wide-area wake over object storage (the component track) | ≈ 1 RTT at the median to the object store (Sydney worst case: p50 179 ms at RTT ≈ 226 ms; p99 ~2 RTT) | substrate ≥ v1.5.0: warm-set carried in the sleep token, hydrated in one coalesced get_batch, keep-alive WarmPool — measured on the component's own wake-latency-widearea.yml; the honest SLA is "wake ≈ 1 RTT to your object store", so co-locate the object tier in-region |
The roadmap's "known 1020 ms wide-area item" is closed by the second row — on the component
track, where the machinery lives. The composed mutinyd path currently runs local-filesystem
tenant stores (the imported Loom flavor is air-gapped by this repository's own pinning);
wiring substrate-store's remote tier under the composed store is open and named on M8's
ledger — it inherits, not re-proves, the ≈1-RTT property. No unqualified latency claim is made.
Prebuilt macOS and Linux binaries and multi-architecture containers are produced from
mutinydb-v* tags. Downloads are checksum-verified by the installer:
curl --proto '=https' --tlsv1.2 -fsSL \
https://raw.githubusercontent.com/Bobcatsfan33/MutinyDB/main/scripts/install.sh | sh
mutinyd init
mutinyd mutinydb.jsonOr run the published container with docker compose up -d. From a source checkout, use
docker compose up --build -d.
Public clients live in sdk/python and sdk/typescript; the
machine-readable HTTP contract is docs/openapi-v0.1.yaml. Agent
frameworks can use MCP over stdio or POST /v1/<tenant>/mcp without an SDK.
One build, one container, and the whole thesis: ingest, a standing query that stays current
without recomputation, a poisoned source, one taint, and answers that heal themselves. The block
below is executed verbatim by CI (scripts/run_quickstart.sh), so it cannot rot. The image
build is the one slow step (a full Rust workspace, ~15 minutes cold); the five-minute path starts
at docker run. The operator token is a quickstart default — this is a demo container, not a
deployment.
docker build -t mutinydb .
docker run -d --name mutiny-quickstart -p 7654:7654 mutinydb
for i in $(seq 1 60); do curl -fsS localhost:7654/v1/quickstart/health >/dev/null 2>&1 && break; sleep 1; done
# Ingest: every write is an enveloped commit that names what it derived from.
curl -fsS -X POST localhost:7654/v1/quickstart/write -d '{
"actor":"analyst","session":"sess-a","branch":"sess-a","intent":"record evt-1",
"sources":[{"system":"web","record":"scraped-page-77"}],"table":"telemetry",
"rows":[["evt-1","sess-a","urgent credential compromise reported by scraped page",12000000,true,1001]]}'
curl -fsS -X POST localhost:7654/v1/quickstart/write -d '{
"actor":"analyst","session":"sess-a","branch":"sess-a","intent":"record evt-2",
"sources":[{"system":"erp","record":"ledger-9"}],"table":"telemetry",
"rows":[["evt-2","sess-a","routine ledger reconciliation complete",3000000,false,1002]]}'
# Register a standing query once; it maintains itself forever after.
HANDLE=$(curl -fsS -X POST localhost:7654/v1/quickstart/sql/register --data \
'SELECT telemetry.branch AS branch, SUM(telemetry.cost_micros) AS total_cost, COUNT(*) AS events FROM telemetry GROUP BY telemetry.branch')
curl -fsS "localhost:7654/v1/quickstart/sql/read?handle=$HANDLE" | grep 15000000
# Watch it stay current: a new commit moves the answer with no re-registration, no recompute.
curl -fsS -X POST localhost:7654/v1/quickstart/write -d '{
"actor":"analyst","session":"sess-a","branch":"sess-a","intent":"record evt-3",
"sources":[{"system":"erp","record":"ledger-9"}],"table":"telemetry",
"rows":[["evt-3","sess-a","routine settlement complete",2000000,false,1003]]}'
curl -fsS "localhost:7654/v1/quickstart/sql/read?handle=$HANDLE" | grep 17000000
# The scraped page turns out to be a lie. One taint; the report leads with what cannot be undone.
curl -fsS -X POST -H "Authorization: Bearer quickstart-operator" localhost:7654/v1/quickstart/taint \
-d '{"system":"web","record":"scraped-page-77"}' | grep "ALREADY HEALED"
# The standing answer healed itself: the poisoned 12000000 is gone, the clean 5000000 remains.
curl -fsS "localhost:7654/v1/quickstart/sql/read?handle=$HANDLE" | grep 5000000
docker rm -f mutiny-quickstartv0.1 developer release: supported for evaluation, not approved for production.
M8 is in progress. Its first item is closed:
#12 — awake tenants now run the
maintenance pass (engine compact → plane checkpoint → prune the consumed queue → collapse →
WAL checkpoint → GC, docs/M8-MAINTENANCE.md), the crash path is checkpoint-aware with full
replay of a collapsed store refused by name, and the nightly soak gates the result at the full
window with storage measured.
The release workflow now builds checksum-verified macOS/Linux binaries and a multi-architecture
GHCR image from a matching mutinydb-v* tag. Still open, named rather than implied: production
approval and external assurance; the remote object tier
under the composed store (M8's ledger, see the wake-latency table); and O(1) fork of live
answers, which MD-5 deliberately moved post-v1 with its spike evidence on record. Schweep's
current-v0.1 and PrismDB's three v0.1.0 artifact tags are released and re-pinned;
#18 lands post-v0.1 on the engine's
track (the nightly soak stays deliberately red carrying it until the re-pin that follows);
PrismDB's production approval still waits on the EXT-KMS custody receipt (MD-7). The roadmap
runs on exit gates, not dates.
| Phase | M1 bridge | M2 semantic | M3 trust | M4 taint | M5 forks | M6 mutinyd | M7 fleet | M8 release |
|---|---|---|---|---|---|---|---|---|
| ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | developer release |
This system is being built fast, largely by AI, under human review — which is a legitimate reason to distrust it, and the reason nothing here ships on enthusiasm. Every answer is proven against a naive oracle that recomputes from scratch. Every durability claim survives randomized crash injection with the fault count asserted — a harness that injected nothing fails. Every gate has proven it can fail, via marker-grepped mutations with the catching instrument named. Every tuned constant lives in an evidence ledger with the benchmark artifact that justifies it. Every limitation is written down before an evaluator finds it.
Run the composed gates yourself:
python3 scripts/verify_component_lock.py
cargo fmt --all --check
cargo clippy --workspace --all-targets --all-features --locked -- -D warnings
cargo test --workspace --all-features --lockedThe nested component workflows are retained as import provenance; root workflows own the composed product result. We would rather you read the tests than the marketing.
Apache-2.0 — see LICENSE. Permanently, because a durability claim nobody can audit is worth nothing. The v0.1 developer release remains not approved for production until the external-assurance and EXT-KMS custody gates pass, and nothing in this repository carries a warranty that its own gates do not prove.