What it does
Codex Foundry is a small trust workflow around Codex.
We built it because a patch being generated is not the same as a patch being trustworthy. Before accepting an AI-assisted change, a developer still needs to know what was changed, what was actually tested, who is making each claim, and whether the same bug will come back later.
Our reference workflow uses PAY-17: a checkout retry bug that creates two payment charges for one logical purchase.
Foundry records the task, prepares a bounded context package, keeps the implementation inside an isolated candidate worktree, and separates Codex's own report from independent verifier evidence. A human approves the patch separately from the engineering-memory write. Finally, we replay the original bad retry-key mutation and show that the unchanged proof catches it again.
What makes it different
The important part is the separation of authority.
Codex can propose and implement a narrow repair. It does not get to declare that the repair is correct. The independent verifier owns the build, health, PAY-17, and browser-proof results. Human approval remains a separate gate.
The dashboard makes this visible: amber cards are non-authoritative Codex claims; green cards are verifier-owned evidence.
How we built it
The project is a TypeScript workspace with a deterministic ecommerce fixture, a Markdown-first engineering vault, evidence records, a fail-closed evidence projection, a local read API, and a React dashboard.
The vault stores approved incident, ADR, proof, and evaluation notes as readable Markdown. The Memory Pack compiler selects a small, relevant set of fresh, verified context rather than sending an entire repository to the next task.
The dashboard's PAY-17 reference run shows the full chain:
Issue → bounded memory → approved plan → isolated repair → independent verification → human approvals → reusable memory → regression replay.
What we learned
The hard part was not generating a patch. It was being honest about what each artifact proves.
We added checks for contradictory evidence and incomplete workflow stages. If evidence disagrees, the projection fails closed instead of guessing a successful state. We also kept post-repair knowledge separate from the original planning context so future knowledge cannot appear to have influenced the earlier repair.
Current scope
This is intentionally a focused MVP with one fully evidenced workflow. It does not merge code, deploy changes, or grant production access. The goal is to prove the trust contract clearly before expanding to more scenarios.
Log in or sign up for Devpost to join the conversation.