Acceptance

Acceptance exercises the actual outcome after independent Review. Review answers whether the engineering is sound; Acceptance answers whether the thing behaves. They're different questions and they need different evidence, which is why one never stands in for the other.

Both Forge acceptance and Forge verify enter this phase. The verify.md filename and the verify/ evidence path are stable compatibility names rather than a separate phase.

Who owns itCopy Anchor Link

For software with an outcome to exercise, it's a clean-context QA professional; for general work, it's the acceptance specialist the deliverable calls for. Instruction-only work with no separate outcome to exercise reuses independent Review and deterministic checks by reference. Acceptance stays read-only on the candidate and doesn't prescribe implementation.

What it starts fromCopy Anchor Link

The Review-passed candidate and base, pinned, plus the accepted scenarios, NFRs, design revision, relevant decisions, environment and fixtures, runnable setup, and known gaps. If current independent Review is missing, changed, or unbound, Acceptance first obtains a bounded Review of the same candidate, which proves nothing about acceptance by itself.

If an approved Spec change was applied, the accepted baseline and approved delta remain independent inputs. The current canonical file and a matching receipt don't prove authority or implementation.

Acceptance loads the preservation scope the Builder proposed and the Reviewer challenged, then exercises the changed or new outcomes, the affected unchanged outcomes, and the material failure paths those obligations name. Unaffected proof is reused only with a reason tied to that scope. A changed path list alone doesn't establish preservation, and no patch requires reverifying the whole product.

What it producesCopy Anchor Link

For each applicable item, a row in acceptance.md recording the scenario or NFR, the environment and candidate, the action or command, the expected result, the observed result, PASS | FAIL | NOT RUN, and a trace, output, or visual link. Visual evidence goes through visual.md.

What proof it needsCopy Anchor Link

It needs current runtime proof that somebody actually observed. Written tests, generated mocks, structural validation, source inspection, and prior labels don't replace that. Required proof that isn't available blocks acceptance and stays explicit, and something that wasn't run is recorded NOT RUN rather than promoted to PASS.

The posture is adversarial and then conservative: try to falsify consequential claims through current public inputs and real failure paths, then require authority, reachability, observed evidence, and material consequence before declaring a failure. No finding quota, no manufactured nits, no personal taste, no speculative scale, no unrelated debt. Material accepted standards stay binding.

Browser and visual acceptanceCopy Anchor Link

For applicable UI work, Acceptance uses an actual browser against the identified candidate. It confirms URL and build identity, authentication, test data, browser ownership, states, and representative viewports, then exercises real interactions and inspects the console, network, persistence, focus, keyboard behavior, semantics, responsive behavior, and regressions where those matter.

The rendered candidate gets compared with the accepted design revision and its states, judging material fidelity, hierarchy, spacing, typography, alignment, clipping, overflow, contrast, interaction feedback, and responsive behavior. Reading the code is not visual acceptance. Pixel precision applies only when the accepted authority actually requires it.

Synthetic-user journeys exercise accepted scope from specific goals, knowledge, permissions, and starting states. They're simulated acceptance or exploratory tests, not real user research, and they can't invent requirements.

For a bug, Acceptance reruns the original reproduction plus the affected behavior. For a visual artifact, it opens or renders the thing and inspects the output. For other general work, it exercises or inspects the deliverable against its stated purpose and source standard.

The complete outcomeCopy Anchor Link

Acceptance also judges whether the integrated result realizes the accepted end state, including confirmed design, cross-Issue behavior, preserved standing commitments, and material regressions. Passing every listed Issue and scenario isn't sufficient when the combined experience is missing or contradicts itself. Current credible evidence gets reused, and a runtime contradiction outranks an earlier green check. This is part of Acceptance rather than an extra Product gate.

A project checkpoint uses the same Review-then-Acceptance composition over its stated completed scope, and names the unfinished outcomes without claiming the whole project is done.

Acceptance may use the knowledge base to locate authority. KB search, OKF validation, and history output never establish candidate compliance.

Where it stopsCopy Anchor Link

The verdict is PASS, FAIL, RETHINK, READY_FOR_USER, INCONCLUSIVE, or BLOCKED. A material failure returns the complete accepted packet and the evidence to Build, followed by the affected Review and Acceptance again, under the same finite repair count Build uses.

What it doesn't authorizeCopy Anchor Link

Acceptance PASS means the actual Review-passed outcome met the applicable acceptance evidence. It doesn't mean anything shipped, and it doesn't grant Ship authority.