Offline-first field capture

People doing the work are on their feet, on sites with no usable connectivity, and what they capture is the input to everything downstream. "Try again when you have signal" is not an acceptable answer when someone is standing in front of the thing they are recording.

Connectivity does not fail cleanly. It degrades, returns mid-request, and drops again — so the interesting cases are the partial ones:

a request that arrived but whose response never came back

two devices that edited the same record while both were offline

a queue that has to survive the application being killed

A naive "retry when online" design handles none of these. It handles the case where the network is simply absent, which is the easy one.

Work is written straight to the device and placed on a durable queue, so a dead connection never loses anything. When the network returns, queued events replay in order, and conflicts resolve against server state rather than overwriting it. Writes are idempotent, so the ambiguous case — the request that arrived but whose acknowledgement did not — costs a duplicate attempt and nothing else.

The measure of success is that the interface never waits on the network and the person using it never has to think about the word "offline".

The failure modes here are the same ones that decide whether a payment integration or an event pipeline is trustworthy: delivered-but-unacknowledged, delivered-twice, and two systems that disagree about state and must be reconciled rather than overwritten. Getting them right in a field app is the same discipline as getting them right where money is involved.