A working product
Gary's conversational surface, the workforce model, and the Vibe Check scan pipeline were already live. The product predates the competition.
Before and During
What existed, and what Build Week added.
The Founder-to-Proof extension
Approval integrity bound to exact versions, council resolution with preserved dissent, fail-closed datastore safety, cost capture, and durable Proof Receipts. Demonstrated end to end with synthetic data in an isolated environment.
Honest status
The Build Week governance primitives are demonstrated and tested in isolation. They are not marketed as production runtime protection until they are wired and deployed.
How Codex and GPT-5.6 Were Used
A mixed-model build, governed like the product.
Codex was used from the terminal to trace a large existing codebase, turn founder direction into bounded implementation work, write and repair product code, create adversarial tests, review security controls, reconstruct a clean database path, prepare the judge experience, and document what changed.
Problems that crossed several layers at once: approval integrity, model-council resolution, datastore safety, cost capture, and Proof Receipt persistence.
The council-panel read model, a core component of the Founder-to-Proof journey, was implemented and tested in a Codex session with GPT-5.6 against a bounded maker packet, then repaired by Codex after independent adversarial review found real issues. Both Codex commits are preserved in the history.
GPT-5.6 also participates in the product itself, as one of the independent experts reviewing major recommendations. It is not a decorative integration added for the competition.
Claude Code served as the continuous integration controller: orchestrating independent reviews, applying one final residual fix to the Codex-built component, and reconciling the work into the demonstration branch. Credit stays with whoever authored each change.
The Build Week work was kept separate from the existing product with dated commits, a dedicated changelog, automated tests, and a record of the primary Codex session. That mixed-model process became a demonstration of the product thesis: different systems can perform different responsibilities, but the founder still needs one governance structure, explicit authority, independent review, and a durable record of what happened.
The Demonstrated Journey
Eight steps, run end to end.
The full Founder-to-Proof journey runs against an isolated environment with synthetic data: a founder states an outcome, Gary assembles the council, experts evaluate independently, dissent stays visible until the experts approve the same recommendation, the founder approves, one bounded action executes, Vibe Check evaluates and can block the result, and the system creates a durable Proof Receipt.
If the experts do not agree, it does not execute. If the founder has not approved the exact action, it does not execute. If Vibe Check blocks the result, it does not execute.
Judge Access
The judge demonstration runs in an isolated environment with synthetic data. Access instructions travel with the submission rather than through this page. The full step-by-step journey is described on the How It Works page.
The product the process built.
See the journey the way a founder experiences it.