Vacant docs
To go deeper,
start here.
It runs your acceptance tests once, delivers only on a pass, and leaves a signed receipt for each step that you can re-verify yourself. Here are its architecture, experimental methods, verdict ledger, and how to re-run everything.
What do you want to know?
I want to understand it firstWhat it actually doesSix rooms that tell the whole story: what we wanted to answer, what we built, what we measured, and what it still cannot do.
I want to know if it worksVerdicts of 58 claimsHeld 23, refuted 14, overstated 5… Refuted claims stay on the table, and every one comes with its supporting numbers.
I want to try itInstall and quickstartInstall vacant-network, hook up an AI assistant you already have, run one task and read your first receipt.
I want to recomputeVerify and re-run it yourselfVerify receipt chains offline, recompute the statistics with zero API calls, run the mechanism simulations — no need to trust us.
Everything we have said in public — does it still hold?
#Start
First learn what it is and how to install it, then read on for how we back it up.
- What Vacant is Vacant is an accountability layer wrapped around your AI assistant. It doesn't replace your AI. It runs the acceptance tests you wrote, delivers only on a pass, and leaves a signed receipt for every step that you can recompute yourself.
- Install Vacant is the Python package vacant-network. After installing it, use vacant on to pick, from a menu, an AI assistant already on your computer and launch it under mediation, without touching your persistent settings.
- Quickstart Walk the whole path with one task that has a known correct answer: write the requirement and its acceptance tests, let the AI assistant do the work, see how the gate rules, learn what each field on the receipt contains, and which three things chain verification cannot catch.
#Core concepts
Four terms hold up the whole mechanism. The definition changed five times, so we spell out which version is in use now.
- Accountability layer In this project, "accountable" is not the same as "trust." This is Vacant's core definition. It was changed five times during the research, and each time the claim got smaller — this table is the only version that is valid now.
- Receipts A receipt is a "tamper-evident" signed record, but it comes in five levels, and every receipt must declare for itself which level it reaches. An audit on 2026-09-20 found that "refused delivery" was only a flag — since then we have stopped saying "stopped at the exit" at all.
- Acceptance gate CONFORM A rule frozen word for word: generate candidates in order, run the visible acceptance tests on each, let the first one that passes through; at most five, and if none passes, refuse delivery. Refused delivery counts as a failure and the denominator is all tasks — this is the most important half of the rule. Held
- Attribution For "who did what" to hold, three things must be true at once: key custody, deterministic sampling, and memory that follows the event stream. If any one is missing, attribution stops at "some key signed this entry" instead of "some participant did this."
- Zero-config Vacant Works as soon as it's installed, with no configuration at all. It does only one thing: within the same session, it sends one message back. The price is that it lacks three parts — an executable signal, the power to retry, the power to refuse delivery. Three of the four batches measured no difference. No discernible difference
- Accountable trace The general intake point answers "does this deliverable pass or not," but it cannot say where it fails, which step got it wrong, or who got it wrong. The trace cuts down to the step: every conclusion has two layers, and only the layer obtained by a re-run flip can carry reputation consequences.
#Architecture
Seven layers, from cryptographic identity all the way to hooking into the AI assistant you already use.
- Architecture Vacant has seven layers: L0 identity, L1 signed record, L2 accountability layer, L3–L4 executable acceptance, L5 observation, L6 product integration. Four mechanisms answer four kinds of cheating, and each one has a failure condition we measured.
- Identity and signed record Every resident holds an Ed25519 key pair, and vacant_id is derived from the public key, so no registry needs to be looked up. Each event-chain entry has eight fields, the chain is append-only, and every signature covers the bytes of canonical JSON.
- Registry and reputation Reputation is recorded on a four-tuple (event stream, branch, model substrate, task family), using a five-dimensional Beta distribution plus UCB routing. Newcomers have a probation cap. The side effect of a penalty is permanent exclusion — of 368 seeds, 0 came back.
- Peer review and audit Every delivery is reviewed by three peers, with no whitelist and weights that arise endogenously from reputation. An audit is not asking a model again but a deterministic rerun in a sandbox — because the blind spot is not zero, and adding more reviewers adds no independent information.
- Executable acceptance layer The visible tests V decide release; the hidden tests GT are used only for scoring afterwards. The sandbox makes the test code structurally invisible to the candidate program. The acceptance suite is data, not code — otherwise an attacker can make the gauge score perfectly in both directions while delivering garbage.
- Multi-party execution What is decentralized is execution and testimony, not judgment. The reason: disagreement in opinion carries no information; disagreement in execution does. This path tolerates at most ⌊(k−1)/2⌋ corrupted executors; past a majority, the result flips.
- Product integration layer Three integration shapes, three strengths of enforcement. `vacant run` treats "the process ends" as the delivery point; the sandbox wall gives bwrap separate namespaces; the exit separates release/publish capabilities. An agent can delete its own hooks, so hooks reinforce — they are not a root of trust.
- Native platform and silent no-ops Putting the decision point inside the agent process does not become "a smaller effect" when the platform doesn't cooperate; it becomes a silent no-op — a complete case record, a signature chain that verifies, zero verdicts. Three gaps, and one decision that moves the loop into the parent process.
#Experiments
Four method families, the definition of the verdict values, and the full results of each of the three axes. Refuted claims are listed here too.
- Experimental methods and verdict values Four families of experimental method, the six states a verdict can take, the four rules declared in advance, and the four analysis disciplines that were written only after re-verification. This page is the reading precondition for every number on the site.
- Defense axis How much work an attacker can get. Of this axis's 12 claims in the project index, 3 were refuted by ourselves and 3 were overstated — but the mechanism that holds off bad actors does work, and what works is not "catching them" but "starving them."
- Gain axis This is the axis we spent the most effort on, and the one where we refuted ourselves the most. The headline was "AI reviewers lose to majority vote"; the conclusion is "executable acceptance gate + resampling works; the revision loop's extra gain is Same sign, unresolved."
- Records & multi-party execution 194 receipt chains and all 9,841 records verify; the lying key was named 273/273, and honest participants were falsely accused 0/1,840. But chain verification cannot catch truncation, forks, or omissions, and mutual execution has no defense at all against the acceptance suite itself being corrupted.
#Evidence & reproduction
The verdict on every public claim, and how to re-run it yourself.
- Evidence ledger 58 public claims, each with a verdict, supporting figures and a way to recompute them. The refuted ones, the overstated ones, the ones where no difference was measured — all stay on the table. A system that claims to be accountable has to be accountable to itself first.
- Reproduction The recipes, one by one: mechanism simulation, the real-model suite, zero-API offline replay, and receipt-chain verification. Most statistical conclusions can be rerun with zero-API recomputation scripts, without calling any model.
- Research history From "a responsibility structure that agents adopt voluntarily" to "a delivery without a verifiable receipt is not accepted." In nine months we changed the definition five times, refuted six of our own claims, and gave up three attack names — this table is that path.
#Limits
What it won't do, what we can't measure, and the project's full record of corrections.
- Limits and non-guarantees This page lists what the system does not guarantee, what we cannot measure, and four known gaps we deliberately left open. Saltzer and Schroeder's principle of complete mediation requires every access to be checked — the intake point in its default configuration does not satisfy it.
- FAQ How it compares with other things, whether you can use it on your own project, how it differs from LangSmith / OpenTelemetry / blockchains, and the questions we have been asked many times that we can only answer with "we don't know."
- Corrections log Every claim that was downgraded or refuted, every number that was corrected, and every sentence we were asked to delete, all in chronological order. From "blocked at the exit" to KS-1, this is the part of the whole research most worth reading.
Where these numbers come from
Every public claim has a verdict in the evidence ledger. Refuted ones stay too — the lab notes are the full record of what got refuted.
