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.
#Positioning
The project's core document puts what Vacant does in one sentence:
It does not make AI trustworthy. It turns "who did what, who checked it, and how carefully they checked" into a record that cannot be changed afterwards, and it makes participants who did bad work get less work.
After September 2026, this positioning became more concrete as an intake point: a delivery without a verifiable receipt is not accepted.
This positioning deliberately avoids two common misreadings:
- Vacant is not another agent framework. It does not decide for the agent how to reason or which tools to call.
- Vacant is not an enforcement layer wrapped around the agent that is guaranteed to intercept everything. Saltzer and Schroeder's (1975) principle of complete mediation requires every access to be checked, and the intake point in its default configuration does not satisfy that.
#Seven layers
| Layer | Name | Whose | When built |
|---|---|---|---|
| L0 | Cryptographic identity | Gateway | 2026-06 |
| L1 | Signed record (event chain) | Gateway | 2026-06 |
| L2 | Accountability layer | Gateway | 2026-06 to 08 |
| L3 | Task bank and sandbox | Harness | from late 2026-08 |
| L4 | Executable acceptance gate | Harness | 2026-09-03 |
| L5 | Observation and display | Gateway | 2026-07 to 09 |
| L6 | Product integration (vacant run / on / agentlane) | User | from 2026-09-18 |
L0–L2 are the accountability layer proper. L3 and L4 were built during the gain experiments, so that "execution instead of opinion" had something to execute. L6 is the product layer, added only after September.
#Four mechanisms, four kinds of cheating
| Mechanism | Behavior it targets | Strength |
|---|---|---|
| Signed hash chain | Changing the record afterwards | Detects (prevents forgery when key custody holds) |
| Reputation routing | Still getting the next job after doing bad work | Raises the cost |
| Peer review (K=3, no whitelist) | "Who is qualified to check" needs someone to grant qualifications, and that someone becomes a party that must be trusted | Raises the cost |
| Deterministic sampling audit | Reviewers lying collectively | Detects (with probability equal to the sampling rate) |
The defense-axis results for these four mechanisms, together with their own failure conditions, are laid out in full in the defense axis and records and multi-party execution.
#Two end-to-end data flows
#With L2 on (the loop of the accountable ecosystem)
- An external agent submits a task and its tests through the MCP tool
delegate. - The system first compiles the tests into a verifier.
- A worker is chosen by reputation routing.
- The worker generates an answer and signs a delivery event on its own chain, advancing the chain head.
- Three reviewers each judge it and sign a review envelope bound to the new chain head.
- The auditor decides by hash whether to rerun the check.
- If there is a provable fault, the delivering party and the reviewers who let it through are penalized.
- The reputation update affects who gets the next task.
- A credential and a delegation receipt are produced; the downstream controller checks them before starting the next agent.
Every step is written into the event chain, and anyone holding the public key can re-verify it offline.
#The L3/L4 main path (from September 2026)
Compared with the flow above, opinion-based review and reputation routing take a back seat; the referee becomes the customer's own executable acceptance tests:
- The agent can be any framework, as long as its model channel goes through the proxy server and its output lands inside the workspace.
- The end of the process is the delivery point. The system runs the visible acceptance tests on a frozen snapshot.
- On a pass, it is let through; on a fail with budget left, it resamples (CONFORM) or revises (H-MIX), depending on configuration.
- When the budget runs out, delivery is refused, and a refused delivery counts as a failure.
- Hidden tests are used only for scoring afterwards.
#Strength labeled by threat model
| Threat | Defense | Strength |
|---|---|---|
| Tampering with the record afterwards | Hash chain + signatures | Detects |
| Impersonation | Ed25519 + published public keys | Prevents (condition: key custody) |
| Replay and reordering | Sequence numbers, previous-entry hash, deduplication | Detects |
| Moving a score onto a different delivery | Reviews bound to the chain head; substrate and task family declared by the delivering side | Prevents |
| Vote stuffing and Sybil attacks | Endogenous weights, unproven reviewers 0.1/k, same-origin down-weighting | Raises the cost |
| Laundering by changing identity | Probation cap, mandatory audit, credit follows the event stream | Raises the cost |
| Reviewers lying collectively | Deterministic sampling audit | Detects (probability = sampling rate) |
| Doing bad work and still getting jobs | UCB routing, penalties, decay | Raises the cost |
#Layer details
| Page | Contents |
|---|---|
| Identity and signed record | Ed25519, deriving vacant_id, the eight fields of the event chain, separating the trust store from the capability store |
| Registry and reputation | Four-tuple reputation key, five-dimensional Beta, UCB routing, probation, penalties and permanent exclusion |
| Peer review and audit | K=3, four checks, the endogenous-weight formula, three-tier down-weighting, deterministic sampling and the blind-spot product |
| Executable acceptance layer | Visible/hidden separation, sandbox, SuiteSpec, the full rules of CONFORM and H-MIX |
| Multi-party execution | Run each other's work, don't review it; gauge checks; majority upper bound; named-party voting |
| Product integration layer | Three integration shapes, vacant run, vacant on, the sandbox wall and exits, agentlane |
#Theory that current code doesn't match
Several concepts in the May theoretical design — self-replication of agents as the main birth path, a heartbeat in the dormant state as proof of identity custody, and lineage (the parent_id chain) as the subject of "unbounded evolution" — were classified as not load-bearing in the July re-scoping of the main line, and have no corresponding implementation in the current code. This document describes the code as it is (vacant-network 0.9.0, tag v0.9.0, zero-config v3.7); those concepts are recorded only as a design blueprint.
