Inspiration

A freelance website brief might say “mobile friendly” or “add a booking button.” Those phrases leave important decisions unanswered: which viewport, which button text, and which destination? Even after revisions, the client still needs to know exactly which delivery they are buying.

ScopeProof brings those decisions into one purchase workflow: agree what done means, inspect the evidence, accept a specific version, then pay for that version.

What it does

The freelancer enters a brief and fixed USD price. Gemini proposes acceptance requirements linked to exact quotations from the brief. Missing details become questions; people supply the answers. The seller and client separately confirm the corrected scope version.

The freelancer uploads a static HTML/CSS/assets ZIP. A restricted preview worker checks literal text, link destinations, raster-image presence and horizontal overflow at an agreed viewport. Each requirement appears beside its observation. An objective failed check blocks acceptance; the client can request a revision and review the next upload. Visual preferences remain a client decision.

When the client explicitly accepts a delivery, ScopeProof pins the scope version, artifact identifier, source hash and agreed price. The server creates a PayPal sandbox order for that acceptance, captures after buyer approval, and verifies the completed payment and its bindings before granting the source download.

A later upload cannot replace the purchased version. If payment confirmation is uncertain, the app keeps delivery locked while reconciling the existing attempt.

How we built it

The interface uses React, TypeScript and Vite. An Express server stores separate project, scope, artifact, acceptance, payment-attempt and entitlement records in SQLite. ZIP processing and static preview sanitization use fflate, yauzl and parse5. Playwright drives a restricted Chromium worker for delivery observations.

The native Gemini adapter requests structured JSON, then validates exact quotations, literal values and unresolved questions on the server. It has no automatic retry or provider fallback. A manual checklist remains available without AI credentials.

PayPal Orders v2 supplies server-side order creation, buyer approval, capture and status reconciliation in the sandbox. The server checks the merchant, amount, currency, order and capture bindings before unlocking the accepted source bundle. The local test adapter is explicitly labelled and exercises the workflow without representing a PayPal transaction.

We developed with separate working agents and an independent review agent in a feedback loop, with external AI reviews and coordinator verification. These development reviewers were not affiliated with PayPal. Abhishek made the product and scope decisions; AI assistance supported implementation, testing and review.

Challenges we ran into

AI sometimes finds a real value but attaches the wrong quotation. We reproduced a filename paired with “our logo” even though the filename appeared in another sentence. We strengthened extraction instructions and added regressions while keeping whole-draft grounding rejection intact.

Payment uncertainty needed separate treatment from ordinary failure: a timeout cannot establish that no charge occurred. We retained attempts and acceptance bindings, kept uncertain outcomes locked, and tested duplicate and delayed-response behavior with controlled provider responses.

Uploaded bundles also require honest evidence. Scripts and outside fetches are disabled in the preview; browser failure produces review-required observations instead of a fabricated pass. Static checks support review but cannot prove that a booking service works or that a visual design is good.

Accomplishments that we're proud of

  • A complete agreement-to-delivery workflow with explicit consent on both sides.
  • AI drafts that expose missing decisions and preserve their source quotations.
  • Evidence attached to individual requirements, with failed checks blocking acceptance.
  • One historical USD 1.00 PayPal sandbox capture verified against the provider order, followed by a download matching accepted version two after version three had been uploaded.
  • An immutable accepted-source entitlement and persistent payment recovery behavior.

What we learned

The useful AI contribution is making ambiguity visible before agreement. A confident suggestion is not consent, and a passing static check is not visual approval.

We also compared an experimental AI change-request triage approach with a structured picker. A small diagnostic exposed misleading use of evidence, and human utility remained unmeasured, so we excluded that feature from the MVP.

What's next for ScopeProof

Run a small comparison with freelancers and clients to measure whether the checklist reduces clarification effort. Improve requirement-level explanation and accessibility, then evaluate broader deliverable types and authenticated multi-user access before considering public deployment.

What makes it different

ScopeProof connects three decisions that are often separated: what was agreed, what the delivered evidence shows, and which exact source version was purchased. AI proposes the checklist; people resolve ambiguity and accept the work; verified PayPal completion grants access to the accepted source hash.

We do not claim a new verification algorithm or a first-ever product. The current differentiator is this specific, explainable agreement-to-version-bound purchase workflow.

Demo and judging access

The public walkthrough shows saved live Gemini output, a separate clearly labelled LOCAL_TEST journey, and a previously completed USD 1.00 PayPal sandbox receipt. It records no fresh AI generation or PayPal buyer approval/capture.

Setup and full testing instructions: https://github.com/Hermes-25/scopeproof/blob/main/JUDGE_SETUP.md . The manual local workflow needs no API key or account; the guide separately documents native Gemini Free Tier and PayPal sandbox setup with your own eligible provider credentials. For help with live-provider access, contact the project creator through Devpost; keys and private role links are never published. This is a local single-merchant static-bundle prototype. Static checks support human review; they do not prove live booking functionality or design quality. It is not escrow or a production public service. Human usefulness and a physical second-machine setup have not yet been established.

Share this project:

Updates

Submission history