Offline availability is a hard requirement
Aliases: disconnected operation · conflict resolution · offline-first architecture
What it is
Offline-first maintenance information means that in a tunnel, underground, a shielded building, or during a network outage, the system still provides authorized essential documentation, asset data, and record-keeping capability, and syncs auditably once connectivity returns. "Hard requirement" refers to continuity for safety-relevant tasks, not that every cloud feature must be replicated offline verbatim — how far offline capability extends should be set by risk, not by chasing full feature parity.
Why it happens
If authentication, content retrieval, search, and record submission all depend on an online service, one network interruption removes both guidance and record-keeping capability at once — a common-cause failure that looks like a network problem on the surface but actually leaves a person with neither knowledge of what to do nor evidence of what they did. A controlled local cache decouples this dependency so critical content doesn't wait on the network, but that decoupling introduces its own consistency problem: cached content grows stale over time, edits or records made independently on different terminals while offline can conflict once reconnected, and a lost device or a long offline period can let credentials expire. Reliable offline design is not simply "store a copy locally" — it requires making data age, sync state, and any conflicts visible to the user at all times, and deciding in advance how conflicts get resolved, rather than improvising once one occurs.
Studying it
Cut network connectivity partway through a task and measure whether personnel can still retrieve the correct content version, complete task records, how often version conflicts or data loss occur, and what errors surface during sync once connectivity returns. Testing must cover extended offline periods (not a few minutes of demonstration), clock skew between device and server, credentials expiring while offline, and multiple people editing the same record independently while disconnected — a brief airplane-mode demo cannot reveal these cumulative problems, which tend to surface only once offline time is long enough and several changes have stacked up.
Where it stops holding
Certain real-time permit decisions, current interlock states, or highly sensitive data may not be authorized for offline caching for safety or compliance reasons; in that case offline capability should support safely stopping or holding the work, not "continuing no matter what" — offline-first does not mean offline-everything. The specific cache expiry period and encryption strength depend on the industry's risk level and applicable regulation; there is no single number that transfers across sites, and each context needs its own assessment.
Applying it
- Preload the critical content and task queue most likely needed while offline, and clearly show each item's version, download time, the equipment configurations it applies to, and the specific basis for judging it stale.
- Record offline events as a conflict-free append-only log with timestamps rather than overwritable fields, and when syncing present the differences for human judgment instead of silently letting one side overwrite the other.
- How to check: run drills covering extended disconnection, use of stale caches, a simulated lost terminal, and concurrent multi-person edits, and verify the system degrades safely and merges data correctly on reconnection, not just basic usability under a brief outage.