ProofRestore

• 

  ProofRestore turns backup status into recovery proof—before an emergency forces you to find out the hard way.

• 

  Start with a demo vault, import a manifest, or open the browser-only Recovery Lab to test your own files safely.

• 

  A backup job can complete successfully while deterministic checks still uncover corruption, missing objects, or retention risk.

• 

  Describe what you need in natural language, choose a protected path, and let tested code resolve the eligible recovery point.

• 

  ProofRestore verifies the selected version, confirms object availability and integrity, and explains the recovery verdict clearly.

• 

  The restore simulation exposes conflicts, warnings, and exact evidence without changing, overwriting, or deleting any real files.

• 

  Generate a portable Proof of Recoverability with the selected snapshot, verified data, restore plan, warnings, and evidence appendix.

• 

  Recovery Lab creates a local test vault from selected files and lets you inject corruption, missing objects, or conflicts safely.

• 

  Break a virtual backup and watch ProofRestore trace the failure through deterministic evidence to an unrecoverable verdict.

Inspiration

“backup completed” badges create confidence, but they do not answer the question that matters during an emergency:

Can the files actually be restored?

ProofRestore was inspired by hands-on experience building backup software and seeing how helpful restore tools and verification is

What it does

ProofRestore analyzes backup snapshots and verifies whether a selected file or folder can actually be recovered at a chosen point in time.

A user can ask:

Can I recover my thesis from Tuesday evening?

GPT-5.6 interprets the user’s intent, including the requested path and recovery time. ProofRestore then passes that structured request to a deterministic recovery engine that verifies:

• snapshot eligibility;
• file and folder history;
• object availability;
• expected and observed hashes;
• size consistency;
• destination conflicts;
• retention risks.

The user can safely simulate the restore without modifying any real files and inspect what has been done behind every result.

It can expose missing objects, silent corruption, partial folder recovery, overwrite conflicts, and healthy copies that may soon be removed by retention rules.

The final result is a downloadable Proof of Recoverability report containing the selected recovery point, restore plan, warnings, metrics, methodology, and complete evidence appendix.

Recovery Lab

ProofRestore also includes a browser-only Recovery Lab.

Users can select files or a folder, create a local baseline snapshot, add history, and inject controlled conditions such as:

• corruption;
• missing backup objects;
• destination conflicts.

Every operation is shown before analysis. Selected files stay in the browser, are never uploaded by the Recovery Lab, and are never modified.

How i built it

ProofRestore is designed around a strict trust boundary between interpretation and authority.

The OpenAI integration uses the Responses API with structured output. GPT-5.6 translates natural-language requests into constrained recovery parameters such as:

• intent;
• candidate path;
• requested date and time;
• recursive folder scope;
• destination mode;
• clarification requirements.

The model is never allowed to decide whether a file exists, whether a hash matches, or whether recovery will succeed.

A deterministic TypeScript engine independently performs:

• snapshot selection;
• path and version resolution;
• object availability checks;
• hash and size verification;
• recursive folder analysis;
• destination conflict detection;
• restore-plan generation;
• retention-risk analysis;
• item-level and request-level verdicts;
• evidence generation.

This means natural language makes the product easier to use, while deterministic verification keeps every consequential result reproducible and auditable.

ProofRestore is built with Next.js, React, strict TypeScript, Tailwind CSS, Zod, the OpenAI Responses API, Vitest, and Playwright. It is stateless, requires no database, and is deployed on Vercel.

Codex with GPT-5.6 Sol was the primary development environment from start to finish. A lead agent coordinated architecture, implementation, integration, validation, and scope. Independent subagents worked on non-overlapping areas including:

• the manifest schema;
• the deterministic recovery engine;
• automated tests;
• the adversarial demo vault;
• accessibility;
• documentation;
• submission readiness.

Codex was also used for adversarial correctness reviews, browser-flow verification, deployment checks, and submission-media quality assurance.

Challenges we faced

Preserving a real trust boundary

The hardest challenge was making natural-language recovery useful without allowing a model to become the source of truth.

GPT-5.6 can interpret “my thesis from Tuesday evening,” but allowing it to infer that an object exists or that a hash is valid would undermine the purpose of ProofRestore.

We solved this through a narrow structured handoff: the model proposes constrained request parameters, while pure TypeScript recomputes every consequential decision.

Representing recovery accurately

Recovery is more nuanced than one green or red badge.

A file may be fully recoverable but still conflict with a newer destination version. A folder may be partially recoverable because one child is healthy while another references a missing object. A retention warning only matters when no other healthy copy survives.

These cases required separate integrity, availability, restore-safety, and retention models.

Making evidence understandable

The final challenge was presenting technical evidence without overwhelming the user.

Accomplishments that i am proud of

• A complete recovery-verification flow that works both with the OpenAI interpreter and through deterministic manual controls.
• Evidence-backed verdicts where every snapshot, path, integrity, destination, and retention claim comes from deterministic code.
• A safe restore simulation that never writes, overwrites, deletes, or executes real data.
• A realistic eight-snapshot vault where apparently successful jobs hide corruption, a missing object, destination conflicts, partial recovery, and expiry risk.
• A browser-only Recovery Lab for testing selected files and controlled failure scenarios without server upload or filesystem writes.
• An escaped Proof of Recoverability report containing metrics, warnings, methodology, restore actions, and a complete evidence appendix.
• A successful validation chain covering formatting, linting, strict type checking, 66 unit and integration tests, a production build, and 8 Chromium end-to-end tests.

What we learned

The most useful AI boundary is not simply AI versus no AI. It is interpretation versus authority.

Natural language makes the system accessible, while deterministic verification preserves trust. Structured outputs and supplied path candidates reduce ambiguity, but model output must still be treated as input rather than proof.

i also learned that evidence changes the user experience. A status becomes credible when the user can inspect the exact snapshot, object, hash, size, destination, and retention facts behind it.

Finally, backup completion describes the result of a job. It does not prove the future ability to recover. Recovery readiness has to be tested independently.

What's next for ProofRestore

• a versioned evidence contract that backup tools can export without exposing internal storage;
• adapters for additional backup formats and providers;
• scheduled restore simulations;
• isolated test restores in disposable environments;
• signed recovery reports;
• team and compliance workflows;
• continuous recoverability monitoring.

Built With

• api
• codex
• css
• github
• gpt-5.6
• next.js
• node.js
• openai
• outputs
• playwright
• react
• responses
• sol
• structured
• tailwind
• typescript
• vercel
• vitest
• zod