The connection fails after arrival

A technician reaches an asset with the correct job open on a device. The network then becomes unavailable. The application can either preserve a usable working state or turn the visit into a sequence of screenshots, notes and later transcription. The difference starts before any code is written. The operating team must decide which information the technician needs to carry, which actions remain authorised without a connection and which decisions require a current central record. An offline interface is the visible consequence of those decisions.

Caching is only one part of that problem. Modern browser mechanisms can retain application resources and intercept requests; MDN's service-worker documentation describes those technical capabilities. They do not determine whether a technician may close an intervention, consume a reserved part or amend an asset's identity while disconnected. Those are operating rules. If the application offers a button without resolving the rule behind it, the organisation merely moves the uncertainty from the screen into the reconciliation work that follows the visit.

Define the smallest complete field packet

For Signal Grid's field-work model, a useful packet would include the work order, asset identity, latest approved instructions, relevant hazards, required evidence and the time at which these records were obtained. It should also state which parts can become stale. A drawing may remain useful for a long period; a shared access permission may change before the technician arrives. The interface must distinguish the two. A generic online indicator tells the user little about the freshness or authority of the particular information being used.

The packet should be intentionally bounded. Downloading an entire operating database to every device increases the burden of protection, updates and conflict resolution. Carrying too little creates another dependency on connectivity. The review should begin with a real sequence of work and ask what a person needs to complete that sequence safely and accurately. It should then test the packet under a lost connection, an expired instruction and an incomplete download. An offline label is credible only when those states produce clear and usable behaviour.

A local record is not yet a shared decision

A field observation can usually be retained as an observation even when it has not been reconciled. It should have a local identity, an event time and an author. Its state should remain visible: saved on this device, waiting to transfer, received centrally or awaiting review. These are different conditions. If the interface calls all of them submitted, the user cannot know whether another team can see the evidence. The application should help the operator recover from interruption without requiring them to remember which invisible stage had completed.

Conflicts require their own design. Suppose two devices record different conditions for the same asset, or a work order is cancelled centrally while a team is completing it offline. Automatically keeping the most recent timestamp may discard the observation that matters. A better rule identifies the kind of conflict and routes it to the person authorised to resolve it. Both original records remain available. The decision records which account becomes current and why. The required mechanism is a small review queue, not a claim that synchronisation can eliminate disagreement.

Test the return, not only the departure

Battery loss belongs in the same review as network loss. A device can hold a complete local record and still fail before transfer. Recovery must state what survives a restart and what evidence needs to be captured again.

An offline review should follow the whole journey: preparation, disconnection, field action, reconnection and reconciliation. The most revealing cases often occur at the end. A photograph arrives after its work order, an upload is retried, or a device restarts before receiving confirmation. The receiving system must recognise the same event rather than count it twice. The operator must be able to see whether any evidence remains local. A successful screen demonstration before departure does not establish that the completed record will arrive intact.

The proposed Signal Grid review would use a bounded set of interventions and deliberately interrupt the connection at each stage. It would record missing evidence, duplicate events, unresolved conflicts and recovery steps. No deployment improvement is asserted here; these are acceptance conditions for the next review. The principle extends beyond software reliability. A system built for field work should acknowledge that the field has its own timing, constraints and authority. Offline operation is complete when the work can continue appropriately and the organisation can later understand exactly what happened.

Sources and data notes

  1. MDN Web Docs — Service Worker API2026 · Technical reference reviewed for this revision; caching capability does not determine operating authority.