Offline first inspection: thirty days without signal

A turnaround on a crude unit runs thirty days. The inspection crew works inside a steel structure that blocks every signal, in vessel internals that block the rest, on a site where the network was designed for the control room and not for a scaffold at the sixth level. The inspection software will be offline for most of the month. Whether it was built for that, or merely tolerates it, decides whether the readings, photos, and sign-offs from those thirty days exist at the end. This paper covers what offline inspection software has to do, from the local store to the sync engine to the encryption on the device, and how to test each part before the turnaround starts.

Why is offline the normal condition for inspection work?

The places inspection happens are the places radio does not reach. Congested pipe racks scatter signal. Vessel internals are Faraday cages. Tank floors are underground for radio purposes. Remote pipeline sites and mine sites have no infrastructure at all. Even where a site network exists, it was scoped for operations, not for two hundred contractors on a turnaround.

An app designed for the office assumes connectivity and treats offline as an exception: cache what was viewed, queue what was typed, hope it reconnects soon. This design fails in predictable ways. The drawing the inspector needs was not viewed before the signal dropped. The prior readings for the next CML are on the server. The workflow transition to submit the report needs a round trip. The photo attaches to nothing until sync.

An offline first design inverts the assumption. Everything needed for the work pack is on the device before the shift: forms, drawings, prior readings, reference data, the workflow state machine. Every action completes locally and is durable locally. Connectivity is an opportunity to sync, not a requirement to work. Offline is not a feature to evaluate; it is the whole exam.

For a thirty-day turnaround this is not a matter of convenience. If the app cannot complete the work offline, the crew reverts to paper and the software becomes a data entry step after the fact, with every error that transcription introduces.

What must work offline in an inspection app?

The test is simple: everything the inspector does at the asset must complete with no connection. In practice that means:

• Forms and workflows. Every inspection form for every module, with validation, calculations, and conditional logic running locally. Workflow transitions such as submit, approve, hold, and reopen execute locally and reconcile on sync.
• Reference data. Prior readings at each CML, the equipment hierarchy, drawings and P&IDs, procedures, and the option lists that populate dropdowns. A picklist that needs a server call is an offline failure.
• Media capture. Photos and video bound to the component and finding at capture time, stored locally with their metadata.
• Annotation. Marking up a drawing or a PDF and having the mark become a record, not a screenshot.
• Signatures. Sign-off on the device with per-signer identity, including when several people sign on one shared tablet.
• Instrument input. Gauge readings over Bluetooth entering the form without the network.
• Search. Finding an asset, a CML, or a prior report on the device.

Two things distinguish a genuine offline implementation from a cache. First, creation works, not just reading: new findings, new CMLs, new records, all with durable local identities that survive until sync. Second, the app behaves the same offline as online. If the inspector has to know which features are available in which state, the design has already failed.

The turnaround case adds one more requirement: bulk pre-load. Before the shift, the device must be able to take the whole work pack, including the drawings and history for hundreds of items, and hold it for weeks.

How long should data survive on the device?

This is the question that separates products, and it is rarely asked in a demo.

Some inspection apps expire or evict local data after a fixed period. The reasoning is usually storage management or a belief that the device will sync within a few days. On a long turnaround, or a remote site visit, or a vessel entry that runs longer than planned, a fixed expiry means data captured early in the job is deleted before it ever reaches the server. The inspector may not find out until the report is due.

The right answer is no time limit. Data captured offline stays on the device until it has synced and the server has acknowledged it. Storage on a modern tablet is not the constraint it once was, and the cost of a lost reading is a repeat entry into a vessel or a gap in the record that an auditor will ask about.

Two related properties matter:

• Durability across restarts. The app closes, the device reboots, the battery dies at the bottom of a drum. Everything captured must still be there.
• Visibility of sync state. The inspector must be able to see, on the device, what has synced and what has not, item by item. Silent sync failure is how a month of readings disappears; visible sync state is how it is caught on day two.

When evaluating, ask the vendor directly whether the local store expires, and ask to see what happens to a record captured thirty days ago on a device that has not connected since. The answer should be that the record is still there, encrypted, waiting.

How should sync handle conflicts between inspectors?

Two inspectors on two devices update the same record while both are offline. One corrects a CML's nominal thickness; the other adds a finding to the same component. When both sync, what happens?

The lazy answer is last write wins: whichever device syncs second overwrites the first. This is a data loss policy with a friendly name. The first inspector's correction disappears without anyone being told.

The better design works at the field level:

• Field-level merge. Changes to different fields of the same record merge without conflict. The nominal thickness correction and the new finding both survive.
• Field-level conflict records. Where both devices changed the same field, the sync engine records a conflict carrying the local value, the remote value, the record and field, and the two actors. Neither value is silently discarded.
• Resolution with identity. A person resolves the conflict, and the record carries who resolved it and when. The unchosen value remains in the conflict record for the audit trail.
• A visible queue. Conflicts surface in a queue that someone owns, not in a log nobody reads.

Conflict handling also has to cover identity. Records created offline need identities that do not collide when two devices each create a new finding on the same component. And it has to cover deletion: a record deleted on one device and edited on another is a conflict, not a race.

The test in evaluation is to create the conflict deliberately. Edit the same field on two devices in airplane mode, sync both, and look for the conflict record. If the second edit simply won, the product has told you how it treats your data.

What does device security look like for a month in the field?

A tablet that spends thirty days moving between a contractor trailer, a scaffold, and a vehicle is a data security problem. It holds a month of inspection records, drawings of the unit, and the credentials of the inspector. Tablets are lost. Tablets are stolen. Tablets are left on a bench.

Transport encryption protects data in flight and says nothing about the device. The requirements for the device itself:

• Encryption at rest on the device. The offline store, including the media, is encrypted so that a lost tablet does not expose the data. This is separate from, and in addition to, the operating system's disk encryption.
• Authentication that works offline. The inspector must be able to unlock the app without a network, and the credential must expire on a sensible schedule.
• Revocation. When an inspector leaves the project, their access is revoked centrally and a stale token on a device cannot sync. Permission changes should invalidate outstanding tokens.
• Per-signer identity on shared devices. Crews share tablets. Each signature must carry the identity of the person who signed, not the identity of whoever logged in that morning.
• Audit trail of device actions. What was captured, by whom, on which device, and when, arriving with the data at sync and joining the server's audit chain.

Security reviewers will ask for all of these. A field app that answers "the tablet is encrypted by the operating system" has not answered.

How do you evaluate offline inspection software before the turnaround?

The demo always works on office wifi. Run the evaluation the way the turnaround will run.

1. Airplane mode first. Turn the radio off before the demo starts, not after.
2. Load a real work pack. Several hundred items with drawings and history. Watch how long the pre-load takes and confirm it is all on the device.
3. Complete the work. Readings, findings, photos, a drawing markup, a signature, a workflow submit, all offline.
4. Create a conflict. Same field, two devices, both offline. Sync both and find the conflict record.
5. Restart everything. Kill the app, reboot the device, confirm nothing is lost.
6. Wait. Leave a device offline for as long as your longest turnaround. Confirm the data is still there and still syncs.
7. Lose the tablet. Ask what an attacker with the device can read. Ask what happens to a revoked user's pending sync.
8. Check the sync state. Confirm the inspector can see, per item, what has and has not synced.

Bring two skeptical technicians. If the app survives them offline for a shift, it will survive the turnaround.

How intelliSPEC handles it

intelliSPEC's field app was designed for the thirty-day case.

• Full offline capture for every module. Forms, images, and workflows for all inspection modules work offline, including intelliINSPECT, intelliNDT, and the turnaround tooling in intelliPROJECTS. Workflow transitions execute locally and reconcile on sync.
• No time limit on the local store. Offline data stays on the device until it syncs. There is no expiry and no eviction after a fixed number of days.
• Field-level conflict records. The sync engine records conflicts per field with the local value, the remote value, who resolved the conflict, and when. Non-conflicting fields merge.
• Encryption on the device. Offline data is encrypted at rest on the device, in addition to AES-256 encryption at rest on the server side and TLS 1.2 or later in transit.
• Identity that travels. Signatures carry per-signer identity on a shared device. Permission changes invalidate stale tokens, so a revoked user cannot sync. Actions captured offline join the hash-chained audit trail on sync with actor, tenant, and request id.
• Instruments without the network. Seven device profiles over Bluetooth or keyboard wedge, including UT gauges, feed readings into the record offline.

Security details, including encryption and token revocation, are on the Trust Center.