Field acceptance checklist
Test the Field Workflow Before the Field Tests You.
A reliable offline workflow lets teams prepare work, capture evidence, understand what is saved, recover from interruption and prove what reached the server. Test those outcomes on real devices and weak networks before rollout.
Define what must work without a network
“Offline” can mean a cached screen, read-only access or a complete write-and-sync workflow. List the exact tasks that must remain available for each role. For every task, name the records, maps, reference lists and attachments required; the maximum expected disconnected period; and what the user must see when information is stale.
Android's official offline-first architecture guidance describes a local data source as the source read by higher application layers and discusses queued work, retries, synchronization and conflict resolution. Treat that as an engineering reference, not proof that a particular mining application implements the pattern.
Run the checklist before field acceptance
Work-pack preparation
- Can a coordinator select only the authorised project, area, task and reference data needed by the assigned user?
- Does the device show package version, download completeness, last successful synchronization and expected expiry?
- Can the team prove that required maps, forms and controlled vocabularies are usable in airplane mode?
- Are package size, storage headroom and download time measured on each supported device class and connection route?
Capture and local persistence
- After each save, can the user distinguish draft, locally committed, queued, synchronized, rejected and conflicted states?
- Do app closure, device restart, low storage, battery loss and interrupted attachment capture preserve or clearly reject the record?
- Are timestamps, time zone, device clock variance, author, original units, coordinate reference system and attachment provenance retained?
- Can validation rules explain the problem without forcing the user to discard unrelated completed work?
Synchronization and conflict handling
- Are retries idempotent, so repeating the same command or upload cannot silently create duplicate observations or files?
- Can synchronization resume after partial transfer and show which item failed, why it failed and what action is safe?
- Does a conflict preserve both versions, identify the affected fields and route regulated or evidentiary decisions to an authorised reviewer?
- Can administrators reconcile device, queue, API and server audit records using a correlation identifier?
Generic mobile guidance may describe “last write wins” as one possible strategy. Do not apply it automatically to geological, safety, environmental, community, permit or other evidentiary records. The rule must follow the domain's authority, materiality and review requirements.
Device loss and access
NIST SP 800-124 Rev. 2 covers enterprise mobile-device security across deployment, use and disposal. Translate the organisation's risk assessment into testable controls for enrolment, supported operating-system versions, local access, encryption, remote action, backups, ownership changes and disposal.
- Document what unsynchronised data remains on a lost device and whether remote action depends on the device reconnecting.
- Test expired credentials and extended disconnection without creating an unsafe field lockout or indefinite access.
- Separate personal and organisational data where personally owned devices are permitted.
Use a witnessed field acceptance run
Prepare fictional test records and a route that includes good, weak and absent connectivity. Witness initial download, multi-hour capture, duplicate taps, conflicting edits, damaged attachments, clock drift, restart, partial sync and final reconciliation. Retain device models, operating-system and app versions, network conditions, participants, timestamps, queue evidence, exceptions and sign-off. Repeat after material mobile, sync or policy changes.
Limitations
No universal storage, package-size, authentication-age or attachment threshold is safe for every operation. Determine thresholds from measured field data, legal and safety needs, supported hardware and recovery objectives. This guide is not a device-security standard, field procedure or proof of OreLynx capability.
Continue the workflow review
Compare the OreLynx offline field workflow, use the broader software evaluation guide, and review acceptance-led implementation before selecting the first scope.