FAQ

#What it is

#How is accountable different from trustworthy?

Trustworthy is a judgment about a property of the system; accountable is a judgment about a property of the record.

Our precise definition is: the traceability and verifiability of events signed by a specific key, with no psychological sense of trust included.

Why not "trust": the classic definition of trust includes "no need to monitor," and monitoring is exactly what Vacant does. Saying "it increases trust" gets read as "you can check a little less," which is the opposite direction.

An independent review in 2026-07 settled this, and its conclusion was one sentence:

What this architecture currently increases is accountability, not trust.

The accountability layer has the full explanation.

#Why is it called Vacant?

In English it means "empty, unoccupied." We use it to name the gap in the agent ecosystem that has not yet been filled: a responsibility layer that lets an agent's actions be recorded, be checked, and carry consequences.

#Is it another AI framework?

No. It doesn't decide for the agent how to reason or how to call tools. It is a layer wrapped around the outside: it runs the acceptance tests you wrote once, and the work reaches you only if it passes.

#How it differs from other things

#vs OpenTelemetry / structured logging

They can be used together: a receipt that Vacant produces can be an attribute on an OpenTelemetry span. But it does not replace a trace.

#vs evaluation tools like LangSmith / promptfoo

Those are evaluations: you give them a batch of tasks and answers, and they tell you a score.

Where Vacant differs is that the referee is data, not rules written by people, and the verdicts are signed into a chain that can be re-verified afterwards. The acceptance gate page has our equal-budget comparison against committee-style review — the committee lost to majority vote, and we measured that ourselves.

#vs blockchains / notaries

Three differences:

1. A blockchain needs consensus and incentives. Vacant has neither — it allows forks; anyone holding the public key can run a chain of their own.
2. A blockchain defends against replay attacks. Vacant does not defend against replay, but it detects replay and reordering.
3. A blockchain's cost pays for immutability. Vacant's cost is only the signatures themselves.

In other words: Vacant is not a blockchain; it is a signed append-only log plus an executable referee. Identity and signed records

#vs in-toto / SLSA / Sigstore

The opposite direction. Those are software supply-chain practices: the builder produces an attestation, and the consumer verifies it.

Vacant is an intake point: a delivery without a verifiable receipt is not accepted. The credential structure of the publish module is taken from SLSA's verification summary attestation.

The difference is who decides: a supply-chain attestation states "this artifact was built by this pipeline"; Vacant decides "this artifact passed your acceptance tests."

#Can I use it on my own project?

#Yes, but you have to write tests

This is a hard requirement.

If your requirement can't be written as an executable test — "write me a quarterly report" — the gate has no referee. It then degrades into "ask a model," which is exactly the thing that measured worst for us.

#Three ways to hook it up, with different degrees of enforcement

The Install page has the full explanation.

#Will it slow me down?

Yes, and we should say so plainly.

• The gate averages 1.51 – 1.71 calls/task (versus 1.00 for a single draw).
• The comparison baseline, OFF5, is 5.00 calls/task.
• H-MIX vs OFF is 2.23 – 2.78× tokens/task.

The full token ledger (including the reasoning share)

This is a gain in success rate, not a gain in token efficiency. Calling it an efficiency gain is a statement we have already refuted ourselves.

#Questions about the results

#Which number are you proudest of?

Not "14–19 percentage points more than trying once" — that one was downgraded by our own stability rule.

The hardest one is this: the three loop arms against a single draw, with all 15 blocks passing their own Holm correction, differences of +17.5 ~ +29.2 percentage points, across five replications and across four mutually exclusive task sets.

The full numbers

#What have you refuted yourselves?

The three that hurt most:

1. "An AI reviewer committee beats majority vote" — refuted. The reviewer votes are nearly constant (accuracy 0.7552 vs a zero-intelligence baseline of 0.7522).
2. "A revision loop beats resampling with a fresh attempt" — downgraded to Same sign, unresolved. Across five replications, 0/5 passed Holm.
3. "Blocked at the exit" — refuted. The audit found that refused delivery is only a flag.

The full verdicts are in the evidence ledger

#Why refute your own things first?

Because it is the only way to be accountable to ourselves. If a system that claims to be accountable cannot be held accountable for its own claims, its assertions have no content.

In practice it is also necessary: the 2026-09-19 audit found that "blocked at the exit" did not hold, and if we had not been using this vocabulary at the time, that error would have stayed on the site.

#What we don't know

#Will people rely on AI more willingly because of this?

We don't know. We did not recruit users, and we did not measure trust.

"Warranted reliance," as we use it, is a technical term (built on acceptance results and records that can be independently checked), not a psychometric result.

#How much does the gate's effect depend on how well the acceptance tests are written?

Not measured. This is first on our own list of next steps. The gauge check gives only a one-sided guarantee: blocking known errors does not mean it covers the real requirement.

#Does your attacker model match reality?

Not fully. Mechanism simulation cannot establish security; it only gives a lower bound on the upper bound of attack cost. The attacker's strategy space is three to four hard-coded strategies, and the true value of the blind spot has no exogenous anchor.

#Is this ready for production?

We make no such claim. On the current product path, the private key is a plaintext file readable by the same OS user, with no hardware protection. This is reason number one for "accountability is not trust."

#Quick reference