UndoProof: prove the way back

A deployment can pass every forward test and still have no safe way back. A renamed column can break the previous application version. A rollback script that restores yesterday's table can quietly erase orders placed after today's deployment. The script succeeds, but the business loses data. UndoProof improves the developer workflow between a migration pull request and release approval. A developer supplies a small release contract: synthetic seed data, forward and rollback SQL, old and new query contracts, representative writes, and a canonical data invariant. UndoProof executes the rehearsal in isolated PostgreSQL databases powered by PGlite. It checks compatibility with the previous application contract, exercises rollback after new writes, compares the customer-visible data, and attempts the migration again. The interface connects each result to the executed SQL, database errors, and before-and-after rows. A developer can inspect the failure, export an evidence packet, and hand IBM Bob a repair prompt grounded in the actual contract and result. The supplied scenarios include a destructive rename, a rollback that loses new orders, and an additive migration. A repair preview makes the change reviewable before another run. The same engine supports a command-line release gate. The key distinction is the data that arrives between deployment and rollback. Reversing a schema does not automatically preserve that data. UndoProof makes the missing check visible and repeatable. A safe application rollback can retain a compatible expanded schema instead of destructively reversing it. Shivam Gupta created UndoProof for the IBM Bob 2.0 Hackathon. The initial commercial audience is a platform or engineering lead at a SaaS company that ships relational database changes regularly. An MIT local runner provides a low-friction starting point. Retained evidence, shared release policies, and private runners are the proposed paid offering, subject to customer validation. The prototype uses original synthetic data and needs no database credentials or paid inference API for rehearsals. Results establish what happened for the supplied SQL contracts and fixtures. They do not establish full application behavior, production lock safety, concurrent transaction behavior, or complete production parity.