From late August through 4 September 2026, I tested an offer to help someone receiving a proof or verification artifact obtain the same result in another environment. The proposed service covered that handoff: fix the version and execution conditions, rerun a public example or supplied artifact, and leave a concise record of what reproduced.
I called it a replay receipt. A related release-gate proposal placed an outside check immediately before deployment. Both tested whether somebody responsible for a real handoff or release would pay for that additional check.
What the receipt was meant to contain
Lean checks formally expressed proofs. Possessing a file, however, does not by itself identify the tool version and dependencies used to check it. The offer pinned a repository commit and toolchain, then called for a clean rebuild rather than relying on the prepared environment.
The targets to compare would be agreed in advance. For a Lean artifact, the scope included inspecting placeholders and axioms and checking that one deliberately broken control actually failed. A passing example alone would not show whether the check could detect an input intended to fail.
The proposed receipt used PASS, PARTIAL and BLOCKED states, with version information, hashes and rerun commands. Its scope was replay under stated conditions. I did not offer to produce a new theorem, judge a proof’s scholarly value or certify a product’s safety.
Four replies pointed in different directions
I recorded four cases from 31 August to 2 September at a 3 September cutoff. One recipient reviewed the release-gate proposal internally and declined because it did not fit the existing QA process. Another asked for a few days to examine the details of a Lean handoff check.
The other two responses were different again. One pointed to concentration on an existing public roadmap. The other said a comparable capability was already available in its product.
Combining these cases into one rejection rate would obscure what needed attention. An existing-capability reply called for product research; a roadmap reply concerned priorities at that time. A request for time to review was not a purchase signal or a contract.
Keeping the 4 September follow-up separate
Two further recipients replied to the replay-sample offer. One was not interested; the other had no time to inspect the example. The latter said I could experiment and share results, but did not agree to review the work or collaborate. Neither reply accepted a paid pilot or a purchase.
A separate business inquiry produced a final delivery-failure notice because the recipient’s server could not be reached. I kept that apart from a recipient reading and declining an offer. Neither this event nor the additional replies resolved the earlier pending case, which retained its 3 September state without a newly verified decision.
The purchasing question remained
The proposals and replies checked at that point did not establish a contract, paid pilot or revenue. They also did not supply a basis for judging demand across formal-verification services. They were records of distinct steps: whether an offer arrived, was read, was considered and led to a purchase.
I set a stop rule before further implementation: do not build when a comparable capability is already available or when I cannot identify the person who owns a release decision and a budget for outside verification. Before another trial, I would look at what the existing tools already cover and who would pay for the remaining check, rather than add more fields to the receipt.