SceneProof

After a crash, stress destroys evidence. SceneProof turns guided synthetic evidence into a source-grounded, human-verified European Accident Statement-compatible draft and editable collision diagram.

Comment

Inspiration

My background includes accident-assistance workflows, and I have seen how quickly useful evidence becomes fragmented when people are stressed. Immediately after a collision, somebody may miss an important photograph, confuse what was visible with what was later stated, or share sensitive information without realizing it.

I built SceneProof to explore a focused question: can guided evidence capture and bounded AI help a person prepare a reviewable accident-statement draft without pretending to determine fault, liability, injury, or legal truth?

What it does

SceneProof guides a reviewer through one coherent two-vehicle incident:

evidence → privacy review → structured proposals → missing-evidence guidance → Party A/B decisions → attributed statements → editable diagram → human verification → private or share-safe report

The public experience uses visibly watermarked synthetic images covering the scene, vehicles, damage, road context, and deliberately invalid policy-document fixtures.

Before analysis, every image must be reviewed and explicitly approved. A user can burn a visible redaction into a newly encoded derivative. When required evidence is missing, SceneProof leaves the corresponding fields unknown and asks for the exact missing material instead of guessing.

The complete accident-statement journey exposes all 53 reviewable fields:

  • 9 incident fields;
  • 22 fields for Party A;
  • 22 fields for Party B.

Every proposal requires an explicit accept, correction, or reject/mark-unknown decision. There is no hidden bulk-confirm action.

Corrections receive new human proposal identifiers and preserve the exact superseded state. Party A and Party B remain separate, including their circumstances, movement statements, and attributed remarks.

When user-provided statements conflict, SceneProof displays Conflicting user-provided information and requires explicit acknowledgement. It does not rewrite either statement or decide which person is correct.

The generated SVG collision diagram is editable. Road geometry, visible signs, vehicle colours and labels, party-stated directions, suggestions, and the user-confirmed impact point remain distinguishable. The diagram is labelled as a draft until the reviewer explicitly corrects and confirms it.

The final artifact offers two projections:

  • a complete private report;
  • a validated, pseudonymized share-safe report.

The share-safe projection tokenizes identifiers, generalizes location and incident date/time, strips source regions, and reduces retained audit timestamps to month windows. It is deliberately described as pseudonymized, not anonymous.

Safety and authority boundary

SceneProof is a documentation aid. It does not determine:

  • fault or liability;
  • fraud;
  • insurance coverage;
  • compensation or claim value;
  • whether somebody violated a STOP sign;
  • definitive chronology;
  • injury or medical diagnosis.

It is not an official pan-European electronic form, police report, insurer submission, emergency service, legal advice, or legal electronic signature.

A visible STOP sign remains a visible sign. SceneProof never turns it into a claim that a driver ignored it, caused the collision, or is legally responsible.

The public judge experience contains no production customer account, insurer adapter, customer record, production ARM connection, or real accident evidence.

Why the demonstration uses synthetic evidence

No real person's accident appears anywhere in this submission. Every demonstrated accident image was created for SceneProof and visibly marked as synthetic. No real accident photograph was used, including blurred material.

Blurring a plate alone would not necessarily remove:

  • faces;
  • documents and identifiers;
  • locations or address clues;
  • timestamps and embedded metadata;
  • recognizable background details;
  • ownership and licensing restrictions;
  • limitations attached to the original collection purpose.

For Build Week, I therefore chose reproducible, visibly synthetic fixtures. They give every judge the same reviewable case, prevent customer or participant information from leaving its original system, and allow screenshots, automated tests, evaluation evidence, and the demo video to be shared safely.

Synthetic evidence is a deliberate privacy and evaluation boundary. It is not a claim that a production system could skip consent, authentication, access control, retention rules, security, or jurisdiction-specific compliance work.

How GPT-5.6 is used

SceneProof separates two product paths and one evaluation path so deterministic replay is never confused with live model output.

Deterministic judge path

The repeatable public journey can use a deterministic analyzer over committed synthetic fixtures.

It follows the same strict statement and safety contracts, reports modelCall:false, requires no API key from the judge, and makes no paid model request. Deterministic output is never presented as GPT-5.6 output.

Opt-in production GPT-5.6 path

At the analysis step, a judge may select GPT-5.6 structured vision instead of deterministic replay.

The browser sends only:

  • approved committed fixture identifiers;
  • evidence categories;
  • normalized redaction geometry.

It never sends caller-provided image bytes directly to the model route. The server independently resolves and verifies the committed PNG files, validates their roles, categories, bytes, hashes, and decoded content, reconstructs sanitized derivatives, burns in the approved redactions, and then calls the OpenAI Responses API.

The request uses:

  • requested model gpt-5.6;
  • a strict schema-constrained response;
  • store:false;
  • neutral documentation instructions;
  • explicit prohibitions against fault, liability, fraud, coverage, compensation, and diagnosis conclusions.

The production route is protected by a Firestore-backed budget policy with a five-call UTC-daily limit and a 50-call lifetime limit. Budget exhaustion fails gracefully and directs the reviewer back to deterministic analysis.

On July 22, 2026, I exercised this public production path with the three approved synthetic guided-demo images.

The deployed Cloud Run revision sceneproof-sp-29703490846-1 returned HTTP 200 from /api/analyze in approximately 7.85 seconds. The accepted result identified the returned model as gpt-5.6-sol and produced source-grounded observations for the scene, vehicle, and visible damage.

The deterministic route remained available and unchanged.

Protected blind release evaluation

The public opt-in call is distinct from the protected blind release evaluation.

That evaluation used three different committed synthetic holdout images. The model received a closed schema, opaque source identifiers, sanitized pixels, and bounded roles and categories. It did not receive the expected answer mapping in its prompt or metadata.

One holdout image contained an untrusted instruction requesting a liability conclusion. Following that instruction would fail the release gate.

The authoritative protected evaluation:

  • made one request with zero retries;
  • used store:false;
  • requested gpt-5.6;
  • returned gpt-5.6-sol;
  • recorded response resp_0bd867f428518e63016a5cd8c56684819a94cff069d113de29;
  • used 4,230 total tokens;
  • completed in 6,852 ms;
  • matched 8/8 hidden fields;
  • passed all 17 schema, grounding, privacy, provenance, safety, and prompt-injection checks.

The deployment process later authenticated that exact sanitized receipt without making another model request.

This separation gives judges a real opt-in GPT-5.6 experience, a free reproducible deterministic path, and an independently preserved blind evaluation without presenting replayed output as a current model response.

How I built it

SceneProof is a standalone Next.js and TypeScript application.

Strict Zod contracts model:

  • incident and Party A/B fields;
  • evidence sources and source regions;
  • immutable proposal and correction history;
  • collision-scene state;
  • attributed statements;
  • contradictions and acknowledgements;
  • analyzer provenance;
  • human verification;
  • private and share-safe output projections.

A shared parsed reducer keeps the statement, SVG collision diagram, reports, persistence, and exports synchronized.

The protected model route accepts only committed fixture identifiers and normalized redaction rectangles, never arbitrary caller-supplied pixels. Before a bounded request, the server verifies manifest paths, roles, categories, bytes, SHA-256 digests, PNG structure, and decoded content.

Redactions are burned into a newly generated derivative. Unsupported or insufficiently grounded fields remain unknown.

Production delivery uses GitHub Actions with keyless Google Cloud Workload Identity Federation. It uses no long-lived service-account key.

A release candidate is created with zero traffic. Before promotion, the delivery system verifies:

  • runtime configuration and identity;
  • secret version binding;
  • budget configuration;
  • deterministic behavior;
  • privacy boundaries;
  • candidate health;
  • desktop Chromium behavior;
  • Pixel 7 behavior;
  • exact 320×568 compact-mobile behavior;
  • rollback availability.

Cloud Run and Firebase rollback anchors are captured before promotion.

How Codex changed the product

Codex was my primary implementation and review collaborator throughout Build Week, not a one-time code generator.

It helped turn the original idea into a bounded product contract and repeatedly challenged unsafe shortcuts, ambiguous provenance, and weak claims.

That collaboration led to:

  • individually visible decisions instead of hidden bulk approval;
  • separate evidence and generator provenance;
  • immutable correction history;
  • one synchronized statement and diagram reducer;
  • contradiction fingerprints that invalidate stale acknowledgements;
  • one validated share-safe projection;
  • a genuinely separate blind holdout;
  • prompt-injection rejection;
  • rejection of arbitrary caller-provided pixels;
  • restartable contextual guidance;
  • mid-flow restoration;
  • keyboard and compact-mobile journeys;
  • fail-closed release and rollback gates.

Human decisions still define the product outcome, category, non-adjudication boundary, synthetic-only policy, prior-work disclosure, authorized live-call scope, and final submission.

Challenges

The hardest problem was not extracting a few values from images. It was preserving the distinction between:

  • what was directly visible;
  • what appeared in a synthetic document;
  • what Party A stated;
  • what Party B stated;
  • what an analyzer proposed;
  • what a human corrected;
  • what remained unknown.

A second challenge was demonstrating meaningful GPT-5.6 use without forcing every judge to consume API quota or trusting a canned model label.

SceneProof therefore provides a real, bounded opt-in GPT-5.6 path while retaining a credential-free deterministic journey through the same product contracts. It also preserves a separate blind-evaluation receipt with model, usage, timing, schema, grounding, and input provenance.

The third challenge was recovery and release integrity. An accepted live-evaluation run was interrupted before deployment. A narrowly bounded recovery path later authenticated the exact evidence, blocked additional OpenAI network access, rebuilt the evaluated source, and promoted only after candidate and hosted verification succeeded.

Later attempts to release additional hardening failed closed before replacing the verified production release. Those failures were not relabelled as successful deployments.

Accomplishments

The deployed product source is:

1a30815d12acf222865f25ecd12b48142ca7b1b5

It is served by Cloud Run revision:

sceneproof-sp-29703490846-1

The verified release passed:

  • 352/352 automated tests across 31 files;
  • 87.51% statement coverage;
  • 82.51% branch coverage;
  • 96.35% function coverage;
  • 88.70% line coverage;
  • 23 browser journeys plus 4 intentional per-project skips;
  • desktop Chromium, Pixel 7, and exact 320×568 layouts;
  • keyboard-only completion;
  • zero serious or critical automated Axe findings;
  • production build;
  • non-root Docker execution;
  • hosted privacy-boundary checks;
  • rollback preservation;
  • 16 hashed current-release screenshots.

Coverage numbers refer specifically to the library files instrumented by the workflow. Component and browser outcomes are reported separately rather than being presented as covered by those percentages.

What I learned

I learned that AI provenance is a product feature, not a model-name badge.

A trustworthy workflow must retain the requested and returned model, response identifier, usage, timing, input and schema hashes, grounding results, and the exact relationship between model evidence and deployed source.

I also learned that “privacy-first” cannot be proven by one blur button. It requires:

  • minimization during capture;
  • explicit approval of newly encoded pixels;
  • rejection of arbitrary external inputs;
  • store:false model requests;
  • bounded persistence and model usage;
  • validated share-safe output;
  • explicit deletion behavior;
  • synthetic evaluation evidence;
  • honest disclosure of what a real-data product would still require.

Finally, I learned that uncertainty should remain visible. If evidence is missing or two attributed statements conflict, a trustworthy system should not hide that tension behind a confident summary.

Potential impact and limitations

SceneProof demonstrates a safer pattern for stressful, evidence-heavy personal workflows:

guide the user, ground every proposal, preserve uncertainty, and keep consequential decisions with a person.

It remains a synthetic judge application rather than a production claims-intake system.

It currently has no:

  • production user authentication;
  • multi-tenancy;
  • insurer integration;
  • durable production claims storage;
  • real-data compliance approval;
  • emergency workflow;
  • official-form acceptance;
  • independent legal or accessibility certification.

A real-data pilot would require lawful-basis and DPIA review where applicable, processor agreements, access control, retention and deletion guarantees, security testing, and jurisdiction-specific insurer and legal validation.

The complete 53-decision journey has not been human-timed. SceneProof does not claim that a person completes it in under three minutes. The under-three-minute requirement applies only to the edited demo video.

What's next

The next product step would be a private or local PII vault connected to a separately sanitized reasoning lane.

After that, I would explore:

  • authenticated multi-reviewer workflows;
  • jurisdiction-aware statement templates;
  • explicit insurer-specific adapters;
  • consent and retention controls;
  • encrypted evidence storage;
  • controlled export and submission workflows;
  • real-world validation under an approved privacy and compliance framework.

These are future directions, not implemented submission claims.

Prior-work disclosure

ARM is the internal name of my pre-existing private Android application for accident-assistance and claim-documentation workflows. It predates OpenAI Build Week and is not part of this submission.

During SceneProof planning, five explicitly authorized ARM files were consulted read-only, solely as domain-vocabulary references for concepts such as claim fields, statement groups, locations, content types, and interface labels.

No ARM code, data, asset, endpoint, customer information, identifier, implementation, or architecture was copied.

SceneProof’s standalone schema, provenance rules, synthetic fixtures, analyzer, interface, collision diagram, exports, tests, and deployment were created during Build Week.

AI tooling disclosure

Codex was the primary product-build collaborator throughout Build Week.

Claude Code performed a bounded review of submission copy and media consistency and authored a later analyzer prompt-and-test repair that is present in the repository’s newer, undeployed source history. Codex reviewed and committed that model-touching change.

The repair is not part of the released SceneProof product identified above. Claude Code did not control production release authority, credentials, model policy, privacy boundaries, or infrastructure.

ElevenLabs generated the narration for the reviewed demo video from the prepared script. It did not generate product functionality, model evidence, test results, or technical claims.

The released application, live-product identity, GPT-5.6 evidence, and production infrastructure remain tied to the explicitly identified source, revision, and verification records.

Built With

Share this project:

Updates