Review, then accept

The implementer's word that the goal is met is the start of acceptance, not the end of it. The agent that wrote the code shares its own blind spots, so a separate, fresh-context reviewer checks the work before it reaches you — and then you, the human, make the final call. This is the outer loop, and it's what turns "the implementer thinks it's done" into "this is accepted."

The reviewer judges the implementer's interpretation — not whether the code runs, but whether the build reads the spec the way the spec meant. It works against the judgeable acceptance checks, each of which names a spec section, and against the repo's standards in conventions/ and technical/ — including the nuanced bars the Goal can't fully state, like performance and security. The named section is what makes its judgment falsifiable: it isn't reviewing on vibes, it's checking the work against a clause someone can point to.

Like the inner loop, the outer loop has a budget: review_rounds_before_human, the number of times the reviewer can bounce work back to the implementer before it stops and hands you the result. The bounce budget gates the transition to you — never the inner loop. When it's exhausted, or the reviewer is satisfied, the work arrives at your gate.

Then you accept — tasteable, the second human gate, the one nothing else can settle.

The three altitudes are the handoffs

This is the clearest way to hold the whole model. The three acceptance altitudes aren't three flavors of test — they're the handoffs between who certifies done, in order:

Layered judgment, on purpose: the implementer asserts done and grounds it in evidence, the reviewer independently checks that interpretation, and you accept. Each altitude is a check on the one below it. That's why a stochastic builder's self-report is safe to build on — it's the first word, not the last.