Case study
MCX
ActiveReference implementation for one claim in my Meta-Concord draft 0.4 white paper: requiring assent from each authorization domain is not the same rule as a two-thirds vote over the same voters.
Status as of October 4, 2026: active, developed in the open. Python, Apache-2.0.
The problem
When AI agents can take real actions (move data, grant access, spend money), someone has to decide who is allowed to approve what. A simple majority vote looks fair, but a single bloc can capture it. Meta-Concord proposes that high-impact actions need assent from each distinct domain: the humans accountable for the system, the people who run the infrastructure, and the agents themselves.
A white paper can claim that. MCX is the smallest working system that lets someone check it.
What I built
Electorate-denominator authorization
Approvals are counted against a frozen electorate. Abstentions stay in the denominator, so a quiet majority cannot be dropped from the count.
Domain assent instead of a headcount
High-impact decisions need an approval from each named domain (human, infrastructure, agent). Four of six agent ballots clear a flat two-thirds vote but fail domain assent. Renaming the domains changes nothing.
Signed evidence, separate verifier
Decisions are packaged as Ed25519-signed evidence. A verifier written separately from the engine recounts each package, and a tampered signature invalidates it.
Fail-closed enforcement
An enforcer guards resource commits. It denies an out-of-scope recipient, a delegation that is not attenuated, a disallowed payload classification, and a capability revoked before the commit takes effect.
One command (mcx-scenario section-15.4) reruns the
paper's comparison from a JSON scenario file. Copy the file and edit it to test your own electorates and rules.
How the evidence is kept honest
- README.md opens with "What this does not show", before the result
- CLAIMS.md maps each paper claim to a test, red-team id, or scenario, or marks it Not shown; a test fails if a reference goes stale
- REDTEAM.md a catalogue of attacks with required outcomes; an attack that succeeds counts as a break
- SPEC.md written so a third party can reimplement the rules without reading the Python
Backed by a pytest suite, including a check of every approval subset of a small electorate against an independent count.
What this does not show
- That the authorization domains are independently operated. Every key is generated in one process.
- That the enforcer sits outside the agent or mediates every path to a resource. It runs in-process and guards an in-memory ledger.
- Witnessed logs, Merkle inclusion proofs, signed checkpoints, or key custody.
- Anything about model behaviour, deception, or alignment.
Quoted from the repository README, which lists them before any result.
Why it matters for enterprise AI
The same questions come up whenever an organisation gives agents tool access. Who can approve a high-impact action? Does the system fail closed when an approval is missing? Can an auditor recount a decision without trusting the code that made it? MCX is a small, inspectable answer to all three, and it is explicit about where it stops.
Lineage
Concord of Coexistence (principles) → Meta-Concord draft 0.4 (white paper) → MCX (code you can run).