Outcome focus: Reader can scope an adjuster-focused claims MVP around offline capture, on-device triage, sync recovery, audit receipts, and acceptance tests that produce pilot evidence instead of demo theater.
product engineeringpwaoffline-firstmachine learninginsuranceauditability
The demo failed in the parking lot.
Not because the model was bad. Not because the capture form was ugly. The adjuster opened the app, took three inspection photos, added notes, walked back toward the truck, and the network dropped. The UI still looked confident. The backend had nothing. The photo triage score existed only in a browser tab. The evidence bundle could not prove which image was original, which version was exported, or whether the server ever received the file.
That is the claims MVP trap. Teams build the visible workflow first: case form, camera button, severity prediction, export button. Then the pilot discovers that field work is an adversarial environment. Connectivity is uneven. Photos are large. People close tabs. Duplicate uploads happen. A model score without a review path creates risk instead of speed. A PDF export without digests is a pretty receipt, not chain-of-custody evidence.
I would scope the first version around those failure modes, not around a maximal claims platform.
I built a small interactive walkthrough for the shape I mean: open the offline claims pilot demo. It is not a production app. It is a product artifact that makes the acceptance tests visible: offline queue, photo triage, sync recovery, audit receipts, and bundle readiness.
The Pilot Constraint#
Assume a two-developer team and a six-week window.
That rules out the tempting version: native mobile apps, generalized claims workflow, full carrier integration, perfect model training, full admin portal, and a compliance engine. That plan is not ambitious. It is muddy.
The useful MVP is narrower:
- one adjuster-facing PWA,
- one claim capture flow,
- multi-photo local storage,
- on-device severity triage,
- resumable sync through signed upload URLs,
- server-verified file digests,
- a review queue for low-confidence or high-severity cases,
- one exportable evidence bundle with signed metadata.
The tradeoff is that the MVP does not try to automate the claim. It tries to make the field capture event reliable, reviewable, and auditable.
That is enough value for a pilot. If adjusters can capture evidence offline, recover cleanly when connectivity returns, and hand the back office a bundle that can be verified, the team has learned something real. If the model helps route obvious severe photos faster, even better. If the model misses, the human review lane catches it.
System Shape#
The architecture is intentionally ordinary.
On the client, use a PWA shell, a service worker, IndexedDB, and a sync queue. The capture UI asks for the fields the pilot needs: policy identifier, loss date, location, required inspection fields, notes, and photos. Each local operation gets a client operation ID so retries are idempotent.
For photo triage, run a tiny on-device model. A compressed MobileNet-style classifier is enough for a pilot if the task is only "severe vs non-severe" or "route this to review." The model output should be a severity bucket, confidence, model version, and timestamp. It should not be treated as claim truth.
For sync, do not stream photos through the metadata API. Ask the server for a short-lived signed upload URL, upload the object directly to storage, then send metadata and the client-computed SHA-256 digest to the API. The server verifies the object digest after receipt and writes the audit record.
For audit, use an append-only table. Every important event gets a server timestamp, signer ID, signature, entity ID, event name, and digest. That is enough to make tampering visible without adding blockchain machinery to a six-week pilot.
The Data Contract#
The pilot-level schema is small:
create table claim_case (
id uuid primary key,
policy_id text not null,
adjuster_id text not null,
loss_date date not null,
location_json jsonb not null,
rma_fields_json jsonb not null,
status text not null,
retention_tag text not null,
created_at timestamptz not null,
updated_at timestamptz not null
);
create table claim_photo (
id uuid primary key,
case_id uuid not null references claim_case(id),
object_url text not null,
sha256 text not null,
captured_at timestamptz not null,
device_meta_json jsonb not null,
created_at timestamptz not null
);
create table photo_triage (
photo_id uuid primary key references claim_photo(id),
severity_bucket text not null,
confidence numeric not null,
model_version text not null,
created_at timestamptz not null
);
create table claim_audit_event (
id uuid primary key,
entity_type text not null,
entity_id uuid not null,
event text not null,
server_ts timestamptz not null,
signer_id text not null,
signature text not null,
digest text not null
);That schema is not complete enough for a carrier system. It is complete enough for the pilot's evidence question.
Can a claim capture event survive offline use, sync to the server, keep photo artifacts immutable, record model triage separately from human review, and export a verifiable bundle?
If the schema cannot answer that, the MVP is not scoped tightly enough.
The Compliance Boundary#
I would describe the RMA alignment carefully.
The pilot can support RMA-style operational needs: required field capture, validation rules, retention tags, evidence bundle export, and audit logs on demand. It should not claim that the app is RMA-compliant by itself. Compliance depends on the actual program, carrier workflow, jurisdiction, retention schedule, evidence policy, and review process.
That wording matters because a field capture app can create a dangerous illusion. A required field validator is not a compliance program. A PDF export is not an evidence policy. A model score is not an adjuster decision.
The pilot should produce the artifacts a review process can inspect:
| Artifact | Why it belongs in the pilot |
|---|---|
| Required field map | Shows which inspection fields the app enforces before submission |
| Retention tag | Makes lifecycle treatment explicit at record and bundle level |
| Original photo digest | Proves the export refers to the captured artifact |
| Server receipt | Proves the server saw the artifact at a timestamp |
| Triage record | Separates model score from human review outcome |
| Export manifest | Lets the bundle be verified after download |
Keep the claim modest: this MVP creates auditable evidence for a pilot workflow. It does not replace policy, legal, carrier, or regulator review.
Acceptance Tests#
The strongest part of the plan is the acceptance-test list. I would make it the center of the build.
| Test | Pass condition | What it protects |
|---|---|---|
| Offline capture reliability | Create case, photos, and notes offline; close and reopen; all local records remain readable | Prevents "demo worked until the network dropped" |
| Sync recovery | After connectivity returns, at least 95 percent of queued items upload within two minutes in the pilot test | Prevents invisible stuck queues |
| Photo triage quality | Severe vs non-severe precision reaches the agreed pilot threshold; low-confidence routes to review | Prevents treating a model demo as a workflow decision |
| Chain-of-custody verification | Bundle includes original digest, signed receipt, server timestamp, and verification endpoint result | Prevents pretty but unverifiable exports |
| Export fidelity | Required fields appear in PDF, CSV, and metadata JSON with retention tag | Prevents back-office retyping and evidence gaps |
The numeric sync and precision targets are pilot targets, not universal truth. The team should tune them against real field conditions. A 95 percent queue-drain target in two minutes might be reasonable for a demo route with intermittent coverage. It might be too weak for another workflow and too strict for remote inspections.
The point is not the exact number. The point is that every number changes a build decision.
Six-Week Delivery Plan#
The first week should not start with code.
Week 0 is where the MVP is saved or lost. Map the required fields, choose the export schema, name the pilot claim types, define severity buckets, write the acceptance tests, and decide who reviews low-confidence photos. A capture app with unclear required fields will spend the rest of the pilot pretending UI polish can fix product ambiguity.
Weeks 1 and 2 build the field surface:
- PWA shell,
- service worker cache strategy,
- IndexedDB schema,
- local case/photo/notes capture,
- local operation queue,
- offline reopen test,
- basic visual state for unsynced vs synced items.
Week 3 builds server sync:
- signed URL request endpoint,
- direct photo upload,
- metadata write endpoint,
- relational tables,
- idempotent operation keys,
- server-side digest verification,
- append-only audit writes.
Week 4 adds triage and review:
- compressed on-device model,
- severity bucket and confidence,
- threshold flags,
- low-confidence routing,
- high-severity review queue,
- pilot confusion-matrix logging.
Week 5 builds export:
- PDF bundle,
- CSV export,
- signed metadata JSON,
- digest verification endpoint,
- end-to-end acceptance run.
Week 6 is pilot hardening:
- metrics,
- logging,
- runbook,
- demo script,
- field-test checklist,
- known-risk register.
The failure to avoid is using Week 6 for features. Week 6 belongs to proof.
The Demo Contract#
The demo should not be a slide deck pretending to be software.
It should let the reviewer see the operational contract:
- toggle offline and online,
- add a photo while offline,
- see the queue grow,
- run triage locally,
- route low-confidence items to review,
- sync after the connection returns,
- inspect digest and receipt records,
- generate an evidence bundle preview.
That is why I made the companion route as a pilot console rather than a landing page. The first viewport is the workflow. It shows the case, photos, queue, acceptance status, and audit bundle together because those are the pieces that make the MVP defensible.
For a real implementation, I would add the actual PWA and sync test harness:
test("offline case capture survives restart and syncs after reconnect", async ({
page,
context,
}) => {
await context.setOffline(true);
await page.goto("/claims/new");
await page.getByLabel("Policy ID").fill("POL-4107");
await page.getByLabel("Loss date").fill("2026-05-16");
await page.getByLabel("Inspection notes").fill("Northwest field edge, visible wind damage.");
await page.getByRole("button", { name: "Add photo" }).click();
await page.reload();
await expect(page.getByText("POL-4107")).toBeVisible();
await expect(page.getByText("Queued locally")).toBeVisible();
await context.setOffline(false);
await page.getByRole("button", { name: "Sync now" }).click();
await expect(page.getByText("Audit receipt verified")).toBeVisible({ timeout: 120_000 });
});That test is more valuable than another feature because it defends the pilot's central promise.
What I Would Cut#
I would cut native mobile for the first pilot unless device APIs or enterprise distribution require it. The PWA path is not perfect, but it is fast to demo, easy to iterate, and good enough to test offline capture and sync behavior.
I would cut generalized claims workflow. One case type. One required-field map. One export bundle.
I would cut fully automated adjudication. The model routes photos. Humans decide.
I would cut blockchain. Append-only audit records, digests, server signatures, and optional external attestations are enough for the first learning loop.
I would cut advanced conflict resolution. Last-writer-wins is acceptable for mutable notes in a pilot if photos are immutable and client operation IDs make retries idempotent. Add vector clocks or CRDTs when real collaboration patterns justify them.
This is not underbuilding. This is preserving the learning question.
The Metrics#
Define the pilot scoreboard before launch:
| Metric | Why it matters |
|---|---|
| Time to first sync after reconnect | Shows whether field work clears the device quickly |
| Queue drain success rate | Shows whether retry behavior is trustworthy |
| Severe precision and recall | Shows whether triage helps or creates review debt |
| Low-confidence review rate | Shows whether the threshold is operationally usable |
| Capture-to-submitted time | Shows adjuster workflow value |
| Audit verification pass rate | Shows whether evidence bundles can be defended |
If the pilot cannot report those numbers, the team will leave with anecdotes.
The app can be rough. The evidence cannot.
The Decision After the Pilot#
A good MVP does not end with "users liked it."
It ends with a decision.
Continue if adjusters can capture offline without losing work, queues drain reliably, reviewers trust the model routing enough to keep it in the loop, and exported bundles verify without manual repair.
Narrow if field capture works but triage quality is weak. Ship the offline evidence workflow and keep model scoring in review-only mode.
Pause if sync recovery is unreliable. No severity model can compensate for lost evidence.
Kill or rebuild if the required-field map cannot be made stable enough for the pilot case type. The product problem is not ready for automation yet.
That is the MVP standard I would use here: not the smallest set of screens, but the smallest workflow that can survive the parking lot, produce a verifiable bundle, and teach the team what to build next.