The 10/10 Gate: How the Engine Finishes a Task Without Hallucinating "Done"

In short

The signature disease of AI agents is declaring "done" when it isn't. The 10/10 gate turns doneness from a feeling into a set of criteria, each of which closes only against executed evidence: command output, a test run, a screenshot. There are exactly two outcomes: VERIFIED 10/10, where every required criterion has evidence attached, or an honest gap report saying what's left and why. A fabricated "10/10" with no evidence is banned, and an honest report is a legitimate result rather than a failure — which is exactly what removes the model's incentive to lie. Criteria split into ENFORCED (checked by an exit code) and ADVISORY (judgment, labeled honestly). One important note: the gate is a builder layer; it isn't part of the base Quest seed yet, you assemble it on top.

What it is

The signature disease of AI agents is declaring "done" when it isn't. The 10/10 gate (engine.doneCriteria) treats that structurally: it turns "doneness" from a vibe assessment into a set of criteria, each of which closes only against executed evidence.

Status. The 10/10 gate is a builder layer: the schema and the exporter support it, but it isn't part of the base flagship Quest seed yet (in development for the flagship). Meaning a purchased Quest package doesn't bring doneCriteria out of the box — it's something you assemble on top when you describe your own engine in the configurator. What follows describes how this layer is built, not "the behavior of an installed Quest."

When the layer is switched on, the exported package carries a literal recipe with a hard rule: exactly two outcomes, there is no third.

1. VERIFIED 10/10 — EVERY required criterion has EXECUTED evidence (paste the command/test output, the browser screenshot). No evidence means the criterion is NOT closed.
2. HONEST GAP REPORT — if even one required criterion isn't proven: list honestly what's left and why. This is an equal outcome, not a failure.

BANNED — fabricated 10/10: declaring "10/10" without executed evidence is forbidden. No command output = no closed criterion.

An honest gap report is not a defeat but a legitimate second outcome. That's precisely what removes the incentive to lie: the model doesn't need to pretend, it has a sanctioned way to say "this part isn't proven."

ENFORCED vs ADVISORY criteria

Every criterion has a checker, and checkers fall into two classes:

• ENFORCED (cmd / test / file / http) — proven by an exit code: a command, a test, a file's presence, an HTTP response. A machine verifies it, not a judgment.
• ADVISORY (behavior / human / rubric / reference) — proven by judgment and labeled honestly as advisory.

That split is visible right in the package, so nobody passes off "a human looked at it, seems fine" as a machine-verified fact.

Proportionality

The gate doesn't bury small work in ceremony. proportionality: full (every required criterion proven) or light (for quest-fix — prove only the required ones, no ceremony). In auto mode a small fix (kind: quest-fix) drops into light by itself.

When to use it

• Any task where what matters isn't "almost works" but "proven to work": features, bugfixes, releases.
• Especially valuable on a weak target model that tends to report success prematurely.

What it looks like at the builder layer

The example below illustrates the shape of the doneCriteria layer — how it would be described in the configurator. This isn't a scenario from the base Quest; it's what your own set of criteria turns into after export.

Input: "add a POST /login endpoint with a rate limit." An engine with doneCriteria.criteria:

• [required] "Auth tests are green" — checker test, detail npm test -- auth [ENFORCED]
• [required] "Rate limit kicks in after 5 attempts" — checker http, detail curl -X POST /login × 6 [ENFORCED]
• [required] "No secrets in the diff" — checker cmd, detail git diff | grep -E 'SECRET|TOKEN' [ENFORCED]
• [additional] "Error messages are clear to a beginner" — checker human [ADVISORY]

What the engine does with this layer:

1. Implements the endpoint.
2. Walks the required criteria and executes the checks. Runs npm test -- auth → 12 passed. Sends 6 curl requests → the 6th returns 429. Greps the diff → empty.
3. Attaches output to each criterion: the test log, the body of the 429 response, the empty grep result.
4. Marks the additional (advisory) criterion as a judgment, honestly labeled.

Result: "VERIFIED 10/10 — all 3 required criteria proven by executed output," with the artifacts attached.

The alternative (honest) outcome: if the curl check showed the 6th request still returning 200, the engine is FORBIDDEN to write "done." It issues an HONEST GAP REPORT: "2 of 3 required criteria proven; the rate limit doesn't fire (request 6 returned 200 instead of 429), criterion not closed." That outcome is exactly what protects you from a hallucinated "done."

Honest caveat

First, the status: the 10/10 gate is a builder layer, not built-in behavior of the base Quest. The schema and the exporter support it, but it isn't in the flagship seed yet (in development). Everything above applies to an engine you explicitly added this layer to.

Now the boundary of the guarantee. The gate is strong exactly where a criterion is ENFORCED (there's an exit code). ADVISORY criteria rest on the model's good faith and are labeled advisory — they aren't a guarantee. You can't fully remove the possibility of lying, but BANNED — fabricated 10/10 plus an equal-standing HONEST GAP REPORT strip the model of the motive: admitting a gap honestly is a permitted and expected move.