Overview
Plant works in basements, tunnels and paddocks, so the app treats no-signal as the normal case, not an error. A machine in a valley with no coverage is inspected, recorded and — where an Interlock is fitted — electrically unlocked, with no server in the loop at all. The evidence syncs when coverage returns.
The design principle behind everything here: a stale cache never blocks an inspection, and compliance data is never silently discarded.
What works offline
- The full pre-start, end to end: the checklist is cached, the result is computed on the phone by the same rules the server uses, and the submission queues.
- The signed unlock. The Bluetooth exchange between phone and Interlock needs no network. Once your phone has cached a machine's unlock key from an earlier online session, the unlock works with zero bars.
- Defect capture, including photos — everything queues.
- Confirm against a pre-start that is still valid and has already reached the platform, and the emergency bypass path on a failed pre-start.
- Browsing your licensed equipment, checklists, and cached defect history.
The one hard requirement: the unlock key for each machine is fetched online the first time. A machine your phone has never connected to before needs one online session; from then on it's offline-capable.
What needs a connection
| Action | Why |
|---|---|
| First unlock of a machine new to your phone | The per-machine key is issued by the platform after its authorisation checks |
| Commissioning, releasing, tag install/replace | Hardware lifecycle changes are online-only, deliberately |
| Service mode | Never queued — replaying a deferred service-mode command later would be unsafe |
| Fresh server data | New checklists, licence changes and other updates arrive on the next sync |
What blocks an inspection — a deliberately short list
Only four things stop a pre-start from starting: no cached data at all (a brand-new sign-in that has never synced), no resolvable equipment group, no valid licence for that group, and no usable checklist. That's the whole list. An out-of-date cache, a lapsed sync, a poor signal — none of those block. A lapsed account is the exception to all of this: the inspection can still be done and waits on the phone, but the machine may not unlock until the account is brought up to date — see What Happens If a Subscription Lapses.
A licence that has expired does block the unlock — the app enforces your licence locally, offline included — but the machine stays visible in your list with a renew prompt, rather than vanishing confusingly.
The pending queue
Everything you do offline lands in a durable, encrypted pending queue, uploaded in dependency order — a check first, then the defects raised from it, then their photos — so the server always receives records in a sequence that makes sense.
- Retries are automatic. Momentary failures retry on every sync; you don't manage this.
- Nothing is silently dropped. An action that keeps failing is surfaced, not deleted: the failed uploads screen (from the Alerts tab) lists it with per-row Resend and Remove, and the Profile screen's sync card shows the queue state at a glance.
- All data is encrypted at rest on the phone (AES-256), and cleared on sign-out.
How syncing happens
You never have to trigger a sync. The app syncs on launch and resume, the moment connectivity returns, after each action you take, on a period in the background, when the server pushes a "sync now" signal, and on pull-to-refresh if you want to force it. During a sync, queued actions upload and fresh server data replaces cached data — the server's version of a record wins.
Edge cases
- A long stretch offline is fine — days in a black spot don't invalidate anything. What eventually bites is licence expiry (a wall-clock fact the app enforces locally) and drafts: an in-progress checklist draft is kept for 30 minutes on the phone, and a synced draft is kept server-side for 30 days.
- Tampering with the phone's clock doesn't help anyone — compliance timing runs on server-anchored time the app maintains itself, so backdating the clock neither extends an unlock window nor forges a timestamp.
- A pre-start done offline can't be confirmed until it has sent. Until it reaches the platform, the next operator — or you, after a key-off — does a new pre-start. A pre-start that has already synced can be confirmed offline, against the phone's saved copy.
- Confirm with signal checks the platform first. Just before it unlocks, the app fetches the machine's latest record, so a pre-start the office has cancelled is refused. If the fetch is slow or fails, the app uses its saved copy, as it does offline.
- Two phones, one machine — each phone acts on its own cache. What one phone did offline reaches the other only after both have synced.
- Signing out flushes first. Sign-out pushes any queued compliance records before clearing the cache, and warns if something can't be flushed.
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| "Can't unlock offline" on a machine | This phone has never fetched that machine's key | Connect once with coverage (any earlier online session at the machine does it) |
| A record shows "pending" for a long time | Still no coverage since the action | It uploads on the next sync — check the Profile screen's sync card |
| A record shows "failed" | The server rejected it, or retries ran out | Open the failed uploads screen and Resend; contact support if it repeats |
| Checklist changes made in the office not showing | The phone hasn't synced since | Pull to refresh with coverage |
| Machine visible but Start is unavailable | Licence expired, or the machine is out of service | Renew the licence, or see the defect blocking operation |