-
-
OFF everywhere the user can see, yet one identifiable request still reached recommendations. That is the broken promise.
-
GPT-5.6 ranks two explanations and requests one allowlisted replay. It proposes only; the model never decides the verdict.
-
Deterministic code ran the selected replay and captured the evidence. The model did not run or verify it.
-
Codex changed exactly two files in a throwaway checkout: a two-line reorder plus a regression test, approved by an exact human digest.
-
Five groups pass. GPT-5.6 diagnosed, Codex repaired, a human approved. None of them decided PASS; the unchanged evaluator did.
-
The same unchanged evaluator, running in your browser with no model call, returns PASS bound to this evidence across five clauses.
-
Change one observation and the same evaluator flips to a broken promise, while the report you sealed a moment ago goes stale.
-
The same deterministic authority in your terminal and CI: a kept promise exits 0, a broken one exits 2 and fails the build.
A setting is a promise. When a product tells you that personalization is off, you would expect that nothing identifying you reaches its recommendation/personalization system right?
But what if every setting, service and backend says it is off while one identifying event still crosses that boundary? With a coding agent these issues can be detected and repaired but how can you trust it to be fixed?
As a developer, I have learned firsthand that it claiming "it's fixed" is indeed a claim, not a fact. This is the catch PromiseProof tackles: the agent that changed the code should not be the one that decides whether its own repair worked.
PromiseProof separates those roles. GPT-5.6 investigates, Codex repairs, a human approves the exact patch and an unchanged deterministic verifier decides PASS.
Instructions for Judges
No account, API key or install is required to see the core idea. The verdict path uses no backend API, evidence upload or model call.
- Watch the five-stage walkthrough (a recorded run through all 5 steps: Observe, Investigate, Replay, Repair, Prove): https://promiseproof.alex0paiva0.workers.dev/walkthrough/
- Challenge the proof yourself: https://promiseproof.alex0paiva0.workers.dev/verify/?judge=1
- On load:
PASSandBOUND_AND_REPRODUCED. - Press Tamper OFF evidence:
BROKEN_PROMISE, violationPP_IDENTIFIABLE_EVENT_LEAK, and the report you sealed a moment ago becomesSTALE_OR_MISMATCH. - Seal the failing result: it binds honestly as
BROKEN_PROMISE. A report can bind a failure; it cannot manufacture a PASS. - Download
report.jsonandreport.md, or load your own OFF and ON bundles under "Bring your own evidence." - Reset to return to the original PASS.
- On load:
- Inspect the bundled GitHub Action: https://github.com/AlexPaiva/PromiseProof/tree/submission-rc-03/.github/actions/verify
What I built during Build Week
PromiseProof started as an empty repository during the submission period. In one week I built the Signal Shelf reference application, two distinguishable cross-system defects, the deterministic evidence and evaluation layer, a bounded GPT-5.6 investigation, an authentic Codex source-repair workflow, exact human patch approval, isolated verification, the five-stage walkthrough, an external-evidence CLI, a hosted semantic challenge and a standalone GitHub Action tested on Windows, Ubuntu and macOS. The public commit history, the Build Week log, the pull requests and the immutable submission-final tag make that work inspectable.
This is not a pre-existing platform with one new feature. The complete working implementation shown here was built, tested, productized and released during the Build Week window. See BUILD_WEEK.md and the immutable snapshot at tag submission-final.
Inspiration
A setting is a promise. When a product or service presents a control as off the users expect the system to honor it everywhere, not just on the screen. In the example of a distributed product the interface, browser storage, the network and the backend can each look correct on their own while the combined behavior quietly breaks the promise: one hidden path still behaves as if the setting were on.
There is a second problem arriving fast: while coding agents can now investigate and repair failures like this the model that changed the code is not a trustworthy judge of whether the change actually kept the promise. I wanted to let AI do the open-ended work of diagnosis and repair, while making it structurally impossible for a model to declare its own success.
What it does
PromiseProof takes one concrete user-facing promise, "when personalization is off, nothing that identifies the user should reach recommendations" and then turns it into a deterministic check, and carries a real failure of that promise through a complete repair-acceptance loop:
- Observe: A Playwright journey and independent network capture catch one identifiable request crossing the service boundary while personalization is off. Broken promise.
- Investigate: GPT-5.6 proposes ranked competing causes and selects one allowlisted diagnostic replay, within strict limits.
- Replay: Deterministic code runs the chosen replay and records the facts.
- Repair & approve: Codex prepares a constrained two-file patch containing the source repair and a focused regression test in a disposable worktree. A human reviews the exact diff and approves it by its digest.
- Prove: The approved patch is applied only in a fresh worktree and an unchanged Playwright journey and deterministic evaluator decide PASS.
And a judge can verify all of it directly: watch the five-stage lifecycle, tamper one meaningful observation (using the live challenge page), see the prior sealed report become stale, see the current evidence become BROKEN_PROMISE, seal an honest failing report, download JSON and Markdown proof and run the same authority through the CLI or a GitHub Action.
How I built it
GPT-5.6 investigates
- Receives a sanitized, versioned dossier through the OpenAI Responses API.
- Proposes two to four ranked competing hypotheses.
- Selects one of two allowlisted factual replays through a strict function call.
- Its result schema has no verdict field and no free-form cause field.
- It never sees the seeded fixture, source paths, logs, or root-cause labels.
Codex repairs
- Produces an authentic constrained two-file patch containing the source repair and a focused regression test.
- Works in a disposable git worktree with a restricted writable surface through the pinned Codex SDK.
- Codex also ran repeated red-team reviews that surfaced the original free-text-cause and verdict-language weakness, which led to the ID-only investigation schema and the strict report validation the verifier uses today.
A human approves
- Reviews the exact patch and approves it by its digest in a real terminal.
- Nothing merges automatically, no model approval.
The unchanged verifier decides
- The same Playwright journey and deterministic evaluator that caught the break.
- Checks OFF, Reload, ON, Browser and Control.
- Models are structurally excluded from
PASS.
Adoption surfaces: a hosted browser verifier, a repository-local CLI and a self-contained GitHub Action tested as a standalone consumer on Windows, Ubuntu and macOS. No model call runs in the verdict path on any surface.
Challenges I ran into
- Two failures with the same visible symptom: An initialization race and a preference-propagation failure both break the same OFF promise, but they produce different evidence, different violation codes and require a different diagnostic replay. One flag cannot explain both and one fix cannot silence the other.
- Preventing a false green: Disabling all personalization must fail and not pass.
OFFmust stay protected whileONfunctionality keeps working, and the contextual recommendation feed must stay useful. The check is designed so "turn everything off" cannot satisfy the promise. - Keeping AI useful without granting it authority: GPT-5.6 can reason about uncertainty but cannot declare success. Codex can prepare a patch but cannot merge or approve it. Only unchanged deterministic evidence determines PASS.
- Making the proof portable: Evidence is canonicalized and bound with SHA-256 to a pinned evaluator fingerprint, and
checkreproduces the complete report rather than trusting hashes, so a stale or forged report is rejected.
Accomplishments I'm proud of
- Built the complete product within the Build Week window as a solo developer.
- Two distinguishable seeded failures with different evidence and violation codes.
- Two allowlisted diagnostic replays.
- One authentic, human-approved Codex source repair.
- Five independent verification clauses.
- Three developer surfaces: browser, CLI and GitHub Action.
- The GitHub Action tested as a standalone consumer on Windows, Ubuntu and macOS.
- Byte-identical browser and CLI gate reports for the same evidence.
- A hosted semantic tamper challenge that runs entirely in the browser.
- Complete report reproduction rather than hash-only checking.
- Zero model-owned verdicts and zero model calls in the verifier verdict path.
- An immutable
submission-finalsnapshot of the complete submission.
What I learned
The most useful lesson to me was that integrity and correctness are two different things. A report can be perfectly attached to its evidence and still honestly say that the promise is broken. While binding proves that a report is faithful to its evidence it does not (and should not!) manufacture a passing verdict.
I also learned that bounded AI is not weaker AI. GPT-5.6 stays valuable precisely because it investigates uncertainty, while its inability to award PASS is what protects the result.
Finally, the hard part of AI-assisted repair is not producing a patch. It is building an acceptance process that proves the exact approved patch fixed the restricted state without breaking the permitted one.
What's next
- Build deterministic evidence-producer adapters so more apps can emit compatible evidence.
- Validate the architecture against a second real application.
- Add another contract family only after independent validation.
- Improve developer onboarding around normalized evidence production.
- Explore reusable typed interfaces once more than one integration proves the abstraction.
No promise of universal support, automated evidence collection or arbitrary contracts.
Testing and supported platforms
- Hosted, no rebuild: https://promiseproof.alex0paiva0.workers.dev/verify/?judge=1
- Repository-local CLI:
npm run promiseproof -- gate|verify|check - GitHub Action:
uses: AlexPaiva/PromiseProof/.github/actions/verify@submission-rc-03 - Install for local runs:
npm cithennpx playwright install chromium(Chromium is only needed for the walkthrough tests, not for the verifier!). - Supported platforms: the CLI is directly verified on Windows and the bundled Action is exercised on Windows, Ubuntu and macOS.
- Local no-key checks:
npm run demo:rehearse, thennpm run test:externalandnpm run test:action.
Current limitations
- One synthetic reference application (Signal Shelf), synthetic by design so one broken promise is visible and repairable end to end. Not a legal or regulatory compliance statement.
- Exactly one external contract family is supported:
activity-personalization/v1. - External evidence is evaluated but not collection-attested. Binding proves a report matches its evidence and the pinned evaluator source but it does not prove the evidence was collected honestly.
- Integrity is repository-level and content-addressed. It is not a signature, notarization, certification or third-party attestation.
- The
mainbranch stays intentionally seeded-broken so the red-to-green repair can be demonstrated, production is not automatically repaired.
Built With
- ci-cd
- cloudflare-workers
- codex
- codex-sdk
- deterministic-testing
- developer-tools
- esbuild
- express.js
- git-worktrees
- github
- github-actions
- gpt-5.6
- node.js
- openai
- openai-responses-api
- playwright
- typescript
- vite
- zod
Log in or sign up for Devpost to join the conversation.