Problem
Saving an inspection offline preserves the form, but the next person may still be waiting for it. An inspector finds seepage at a pump seal; the maintenance lead is nearby, yet cannot review the finding in the application until a phone reconnects. The team falls back to a conversation, a separate message, or a later handover. The missing step is local action on the finding while the site is still disconnected.
Solution
The controlled demo uses the Offline Protocol Mesh SDK1 to connect an inspector's phone and a lead's phone over a qualified nearby transport. The inspector saves the defect locally; the lead receives it, acknowledges it, and takes ownership of a follow-up without internet access. That authored response returns to the inspector. Both phones retain the finding and review events, then submit the same event identities to a test backend when connectivity returns.
Outcome
The result to demonstrate is a completed human handoff before cloud synchronization: the inspector knows the lead has reviewed the defect and owns the next step. The test checks that this exchange survives a lost receipt and that uploads from both phones produce one finding and one lead review. Physical-device measurements are pending; the protocol below defines the evidence needed to publish the result.
A finding becomes somebody else's next action
The demo follows one asset, two people, and one defect. The inspector selects pump P-17, records a seal inspection finding, and saves it. A locally committed record appears immediately on that phone. The lead's phone must receive the finding while both devices remain unable to reach the backend.
The lead opens the finding and selects Acknowledge and take ownership, with a next-action note such as “Check seal before restart.” This creates a separate review event referencing the original finding. The inspector's screen advances only after that event arrives and is committed. A transport acknowledgment establishes delivery; the lead's review establishes that a person acted on the record.
The action is a recorded maintenance follow-up. Equipment operation, isolation procedures, repair approval, and any existing work-order authority remain outside the demo.
Two local commits before either cloud upload
OfflineID2 identifies the enrolled participants, and Messaging Layer Security3 protects their exchange. The local application validates the inspector and lead roles. Discovery finds the nearby endpoint; the SDK supplies delivery tracking and retries.4 Automatic transport selection through the Dynamic Offline Relay Switch (DORS) is recorded, while the baseline run permits only the nominated nearby transport so the result is attributable to that path.
Each phone owns a durable event log and application outbox. Creating a finding commits its event and outbox entry together. Receiving a new event commits the event ID and local projection before returning an application receipt. The lead's response follows the same rules. A lost receipt resends the original event, so the receiving application can return its existing outcome.
The native composition uses offline-protocol, offline-protocol-core, offline-protocol-transport, offline-protocol-router, offline-protocol-reliability, and offline-protocol-mls, with offline-protocol-uniffi or the supported native bridge. The initial record has two authored event types, finding_created and finding_reviewed; it does not require a shared editable document to decide who owns the follow-up.
Both phones upload, one finding remains
Each event carries a run ID, event ID, finding ID, author identity, payload hash, and schema version. The lead review also names its parent finding event. Uploading a peer's event preserves that original author and identity. It does not create a new event for the forwarding phone.
The test recipient uses a unique key on run ID and event ID. Identical replay returns the prior commit receipt; an ID reused with different content raises a conflict. If the review arrives before its finding, the backend retains it as a pending dependency and builds the complete finding view after the parent arrives. The phones retire their outbox entries only after the backend confirms the accepted event identities.
The inspection application's database, forms, asset register, and production maintenance system remain separate. The first integration uses a test recipient and synthetic defect record. Photo transfer is a separately measured extension; the baseline finding contains structured text so attachment size cannot obscure the nearby handoff result.
What the controlled run must show
Test status: protocol prepared; two-phone run and measured results pending. The baseline uses two supported phones in the foreground, with Bluetooth enabled and cellular and Wi-Fi disabled. Backend reachability is checked from both devices throughout the offline phase. A separate run can test a store LAN with its WAN blocked; its results must not be combined with the Bluetooth-only run.
Record handset models, OS versions, application and SDK commits, permissions, battery mode, transport configuration, separation, obstructions, payload bytes, and backend build. A screen recording captures both people’s actions and the connectivity checks. Local monotonic timestamps measure round trips on the originating phone; cross-device one-way timings require a documented clock-offset bound.
| Publish this measure | Evidence and acceptance condition |
|---|---|
| Nearby delivery | Lead commits and displays the finding before either phone regains backend reachability. |
| Human response during isolation | Lead records ownership and the inspector displays that review while WAN remains unavailable. Report human decision time separately from transport time. |
| Receipt recovery | Suppress one application receipt after receiver commit; resend the same event ID and confirm one local application record. |
| Duplicate-free reconciliation | After both phones upload, require one finding, two distinct authored events, and one lead review. Report upload attempts and deduplicated retries separately. |
| Order-independent recovery | Restore phones individually and deliver the review before the finding; verify the same final view and no unresolved parent. |
| Durable retention | Restart each application after local commit and compare event IDs and pending outbox state. |
| No nearby path | Move peers out of reach or disable the nominated radio. The finding stays pending; it must not be labeled lead-reviewed. |
Run the baseline at least 20 times and publish every attempt, including failures, with median and p95 timing only where the sample and timing method support them. Keep restart, lost-receipt, and out-of-range trials separately labeled.
Managed services and expansion
From one lead to a maintenance team. Capability Exchange5 can expose an authorized asset-history lookup or review request at the site. Shared checklist progress and multiple inspection notes can add Data Edge Sync6, while authored findings and approvals retain their identities. A construction adaptation follows the same human handoff for a snag or trade inspection, with its own acceptance rules.
From the test recipient to maintenance operations. Hosted Relay can carry retained findings to an authenticated maintenance-system adapter. That adapter maps an accepted finding into a work request and records the external reference, avoiding a new work order on every retry. Opt-in managed Telemetry7 adds visibility into delivery failures, queue age, and reconciliation so support can distinguish a coverage issue from an application-ingestion problem.
Contractor inspection evidence. Proof of Location8 can supplement a visit with witnessed presence at an equipped site. The finding, lead review, and existing approval process still establish what was inspected and accepted. A first paid prototype can stay narrow: one customer's existing inspection form, one supported handset pair, one reviewer role, and one maintenance-system adapter, qualified against their actual site conditions.
