Inspiration
AI-assisted workflows can fail one step before the visible answer. An agent says a file was attached, a package was built, or a submission was completed, and that unsupported claim becomes input for later work. The rest of the workflow may look coherent even though its trace is already false.
Execution Receipt turns that failure into a small, inspectable product. It asks what bytes were actually created, from which source revision, and whether later source changes made the earlier result stale.
What it does
Execution Receipt gives a person and an agent one shared, revision-aware workspace.
Required document slots expose what is present and missing. An incomplete build is rejected with a concrete reason. A successful build creates real ZIP bytes, a manifest, per-document SHA-256 hashes, and a package SHA-256 receipt. Repeating an unchanged build returns the same receipt instead of inventing another execution. Changing a source document preserves the old package but marks its receipt stale. A download request is recorded only as a request; it is never reported as a confirmed save, submission, receipt, or acceptance.
The manual interface and WebMCP tools operate on the same state-transition logic.
Why WebMCP
This is a strong WebMCP use case because the human and the agent operate on the same visible application state and the same guarded transitions. The agent can inspect requirements, add a document, build the package, and read the receipt. The human can inspect the manifest, see the execution trail, and download the artifacts. Neither side has to trust a conversational claim that an action happened.
The application exposes four tools through document.modelContext.registerTool:
get_case reads requirements, the current revision, receipts, and the execution trail. attach_document attaches or replaces UTF-8 text in a fixed slot using the current expected revision. build_package creates the actual ZIP and receipt or returns a precise missing-evidence or revision-conflict result. get_receipt reports whether a receipt is current or stale.
WebMCP is feature-detected, and the application remains usable manually when it is unavailable.
How it was built
The prototype uses dependency-free HTML, CSS, and JavaScript. core.mjs owns requirements, revisions, ZIP creation, hashing, receipts, and the execution trail. webmcp.mjs registers the agent tools and adapts their inputs to the same core operations used by app.mjs. Documents exist only in the active browser session.
Codex helped implement the application, ZIP and hashing logic, WebMCP adapter, mobile presentation, tests, documentation, and public deployment. It also helped design adversarial tests for stale revisions, idempotency, cancellation, and competing builds, and verified ZIP output with an independent Python zipfile reader.
Challenges
The central challenge was defining a narrow proof boundary. A hash proves that specific bytes were hashed; it does not prove that a document is true or legally valid. Creating ZIP bytes does not prove that the user saved them. A WebMCP handler call identifies the application path used, not an authenticated agent identity. The interface and receipt wording preserve these distinctions.
Concurrency was another important failure mode. An older build can finish after a source change. The application performs a final revision check before committing a receipt, so obsolete work cannot become the current result.
Accomplishments
Real package bytes and inspectable manifest, not a simulated success state. Idempotent builds and preserved stale receipts. Optimistic revision checks for manual and agent-driven changes. Cancellation and concurrent-build protection. Binary-safe manual file attachments up to 2 MiB. 21 automated tests, including 50 deterministic chaotic sessions with 6,000 mixed operations and an independent archive verifier.
Testing
Open the live app. It initially shows two present documents and one missing approval document. Attempt a build and confirm the missing evidence is named. Add a clearly synthetic approval document, build again, inspect the receipt and manifest, then download the ZIP and Receipt JSON. Replace the project brief and confirm the prior receipt becomes stale.
For automated verification, run node --test tests/*.test.mjs with Node.js 22+. The suite passes 21/21 tests.
What we learned
The strongest reliability boundary is not a longer explanation from the model. It is a product state that makes unsupported transitions difficult, exposes missing evidence, and carries the exact source revision into the result.
Execution Receipt does not promise universal truth. It proves the execution that the application actually performed.
Real WebMCP validation
The public HTTPS deployment was tested in the ChatGPT Work cloud Chrome browser. The browser discovered all four page tools. A build with the missing approval was rejected, attach_document added a synthetic approval at the current revision, build_package created a 1,655-byte ZIP with SHA-256 3bd4de89043b067e3a8c2c5d9fe811f72d92b8673ea4010039befb02fba4d814, and get_receipt returned the resulting receipt as current.
Built With
- chatgpt-sites
- css
- html
- javascript
- node.js
- openai-codex
- webmcp