Return tag CASE-0042
Custody
Technician → carrier scan pending
Synthetic demo
Field surface · mobile-first · synthetic demo
Capture the failed part where it happens.
The technician surface is built for a truck cab, a warehouse cage and gloves: large targets, few fields, and no finance numbers anywhere in the payload.
New failed part
Starts intake for one failed-part occurrence.
My open items
Assigned cases that still need evidence or a handoff.
Scan case label
Resolves an internal case label after sign-in.
These are intentionally disabled demonstration controls. The separate local app prototype is not connected to this static preview.
Four things, one scrollable screen
- Job reference — typed or scanned from the internal job record.
- Equipment label — model and serial read from the unit label.
- Failed part label — the part identifier, photographed if readable.
- Custody location — where the part physically is right now.
Optional fields include a replacement part reference and a photo of the work area. Missing values stay visibly pending; nothing is guessed into a confirmed state. The technician confirms readable text — no serial number is ever invented for a blurred label, and a blurred photo asks for a replacement instead.
Capture target: under two minutes on a representative physical device. That target is not yet measured; physical-device acceptance remains an open gate.
What the technician sees
The field tag shows custody only. Credit status belongs to the office surface and is never returned in technician API payloads or stored in offline drafts.
Permissions in plain words
Assigned work only
- The technician reads and edits only assigned or own intake.
- Authorized custody events can be added; unrelated cases and team dashboards are not returned.
- A revoked membership stops the next action, even in an open tab.
- Financial totals are not part of the field schema at all — not hidden, absent.
Camera, connectivity and drafts — stated honestly
Camera and files
Capture uses the browser camera where permission is granted, with a file-input fallback for denied permission, unsupported browsers or a locked-down device. Denied camera is a supported state, not an error loop.
Location metadata is stripped from photos before the first durable upload. The stored file is a sanitized evidence original, not the unmodified camera file, and the product says so.
Drafts and offline limits
- On-device drafts are opt-in and hold intake fields and scrubbed photos only.
- Browser storage is not a secure vault: it can be read on a shared, unlocked device and can be evicted by the operating system.
- Default draft expiry is 24 hours, enforced whenever the application runs; cleanup while the app is closed is not guaranteed.
- Local, uploading and server-saved are visually distinct — an unuploaded item is never shown as saved to the workspace.
- Finalization, allocation and disposal decisions are online-only. When background sync is unavailable, a foreground retry is required.
Offline draft behavior on real iOS and Android devices is a physical-device acceptance gate. This page makes no promise about closed-app delivery.
Next
Follow the same case into the office desk, or read the security posture behind these states.