-
-
Historical 16 Oct workflow overview. Core PayPal Sandbox create/read-back was verified separately on 19 Oct; see the story.
-
Local safeguards: edits revoke acceptance; uncertain creation blocks blind retries; mismatched read-back stays unverified.
-
Historical 16 Oct internal checks. Later 19 Oct Sandbox result: VERIFIED_DRAFT in run #1, linked in the project story.
Inspiration
A studio can finish a fixed-price website milestone and still struggle to answer a simple question: which version of the work did the reviewer accept? The agreed scope, delivery report, review and invoice often live in different places. ScopeProof makes that handoff inspectable before a draft is prepared.
What it does
ScopeProof connects a milestone's agreed criteria and integer-cent price to a saved version of textual delivery evidence. An external AI tool can propose criterion-level findings with supporting quotations. The application checks the imported response's schema, criterion IDs, quoted substrings and snapshot binding; it does not treat a model finding as acceptance. A reviewer explicitly considers each criterion and accepts the current version. Changing the report or scope invalidates stale analysis and approval.
Version 0.3.5 also exports a portable delivery record so the recipient can inspect the saved scope, findings, review and draft status together.
The merchant separately confirms an invoice draft. The PayPal Invoicing v2 adapter is restricted to Sandbox OAuth, draft creation and direct read-back. It checks the returned DRAFT status, invoice number, currency, seller, recipient, item and amount against the agreed scope. An uncertain creation outcome stays unresolved instead of triggering a blind automatic POST retry. The app has no invoice-send or payment-capture action. Its default browser mode is visibly labelled LOCAL SIMULATOR · NOT PAYPAL.
How we built it
The local desktop-browser application uses Python 3.11+, SQLite and HTML/CSS/JavaScript. Versioned state, short-lived local review capabilities, explicit approval, a durable billing intent and guarded provider responses keep the review and billing stages separate. The AI workflow exports a prompt for the current snapshot and imports a structured answer from an external tool. The application did not make an in-app model API call in the recorded demonstration; imported authorship is not authenticated. Local lexical retrieval is separately labelled and is not presented as an LLM.
What we demonstrated
Working version 0.3.5, October 22: We operated the actual application in Chrome using a fresh synthetic workspace. We saved the complete report, exported its current snapshot-bound prompt, generated a new structured response with ChatGPT outside the app, and validated that response through the interface. A separate local review session explicitly selected the three criteria and accepted v2; the merchant then created one simulated draft, INV2-MOCK-0001. Both browser roles were operated by the AI assistant as a test, not by a real customer. Importing does not make an in-app model call or authenticate authorship.
Editing the report blocked actions until save or discard. Saving v3 invalidated acceptance, retained the draft as a record of v2 and made the next draft action return CURRENT_REVIEW_REQUIRED. The demonstration uses sampled consecutive browser captures with editorial cuts and reading holds; it is not a continuous screen recording.
Portable delivery records: Version 0.3.5 exports a readable HTML record containing the saved scope, findings, review and draft status. Supplemental exports from the same local database preserved v2 as accepted and v3 as pending with a historical draft. The offline verifier passed their consistency checks. The browser displayed its export notification, but completion of its download was not confirmed in this managed browser; the preserved files were exported locally and are labelled accordingly. Local consistency does not establish customer identity or the truth of supplied evidence.
PayPal Sandbox integration, separate historical execution: On October 19, a one-shot GitHub Actions run of the public 0.3.4 adapter authenticated with authorized Sandbox test accounts, created one unsent synthetic EUR 125 draft, and directly read it back as VERIFIED_DRAFT. No invoice was sent and no payment was attempted. Run #1 and its redacted receipt omit credentials, account emails and invoice identifiers. This core-adapter run did not include the browser or fresh model inference. A continuous 0.3.5 browser-to-PayPal execution is not claimed.
Validation: The merged 0.3.5 tree passed 215 Python tests, five HTTP failure scenarios and 24 JavaScript controller-adapter checks. Earlier recorded AI-import runs also exercised incomplete evidence and stale-response rejection. These are internal engineering checks, not independent certification, a customer study or a comparative model benchmark.
Unicode import hardening, October 30: The current source rejects an imported JSON review containing an escaped lone Unicode surrogate before saving. The reproduced defect changed from a successful import followed by a broken delivery export to 400 INVALID_JSON, with the previous saved state preserved and export still working after restart. Valid emoji, multilingual text and exact quotations remain supported. The audited correction passed 224 Python tests and five HTTP fault scenarios in local simulator and loopback tests. It does not migrate an already-corrupted database, and adds no new browser-to-PayPal or model-execution claim.
Challenges and lessons
We corrected stale asynchronous responses that could otherwise overwrite unsaved edits, put the criterion, quote, finding and human decision together, and separated definite provider rejection from a genuinely uncertain outcome. Hashes and exact quotations bind records to supplied bytes; they do not prove the report is true, that the work was delivered, or that the model is always right. The local ledger prevents this app from blindly retrying an uncertain creation; it is not a provider-wide exactly-once guarantee.
What's next
Evaluate the complete browser-to-provider path under its own authorization without rerunning the one-shot invoice test. Then test whether small web studios actually understand the handoff and whether it saves time. No customer study, paid pilot, revenue or production readiness is claimed yet.
Built with and access
Python, SQLite, HTML, CSS, JavaScript, PayPal Invoicing v2 Sandbox, and external ChatGPT-assisted analysis imported by the user. The public MIT-licensed repository includes a working local simulator and setup instructions. Judges can run that mode without credentials; a separate Sandbox mode requires their own free PayPal Developer Sandbox app and test accounts. The recorded Sandbox runner is one-shot and must not be dispatched again.
Log in or sign up for Devpost to join the conversation.