Builds fail in the same three places: nobody wrote down what was being built, nobody adversarially reviewed it, and nobody checked the live response after deploy. Our process, called FORGE internally, is a gate at each of those places.
Seven phases
Classify: entity, security level, regulated claims, custody, chain actions, surface. Brief: what, why, in and out of scope, acceptance criteria, security properties a reviewer can exercise. Build: code with tests; no stubs shipped. Report: an honest deviation log. Review: a second context exercises the failure path (runs the denied access, not reads the policy). Decide: a numbered decision record for anything load-bearing, including every marketing phrase. Ship: a deploy receipt with a rollback, then a check against the served response.
The served-response rule
Repo-green is not live-green. After every deploy, a sweep fetches the live pages and APIs and records pass or fail per check; the number is published in the repository's test report. On the NIL33 rebuild that sweep grew from 229 checks to 379 in a week, and the failures it caught along the way were real: a route that swallowed a page, a rate limiter that hit a platform quota, a regex mangled by a file encoding.
Founder flags
Anything the builder cannot decide alone (a price, a legal claim, a key, a one-way door) becomes a numbered flag the founder resolves in writing. Nothing ships past an open flag on its gate. Clients get the same file: a running list of what is waiting on whom.
Why we publish this
Because it is the difference between a site that says "secure" and a site that can show you the review that tried to break it.
Questions people ask
What is a deploy receipt?
A written record before deploy of what goes where, on which surface, and how it is rolled back, followed by a check of the served response.
Who reviews?
A second context, human or a separate agent, that exercises the failure path rather than reading the policy.