# Ask the offline demo to prove where the report lives

Review persistence and recovery at each boundary. An attractive offline screen says little about whether work survives a crash or reaches the right account.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Trace one submission through its evidence

Ask the presenter to save a synthetic report without a network connection, close the app and reopen it. Inspect the report and its queued command. Then reconnect and locate the matching server receipt.

The identifiers should explain the same business action across every stage. If a new ID appears on each retry, ask how the server distinguishes recovery from another inspection.

Look at the wording while each boundary is incomplete. Saved locally should not be presented as received by the office, and a completed file upload should not imply the report was accepted.

## Challenge the ownership assumptions

Switch accounts with work pending and change the report's permissions on the server. Confirm that the queue cannot borrow the next user's authority or overwrite a current office record with stale downloaded fields.

Ask which conflicts merge automatically and why. Adding separately identified observations may be safe. Choosing between two asset assignments usually requires a more specific rule.

Review the support workflow for a worker who leaves with pending jobs. The system needs an authorised disposition, not an undocumented instruction to sign in as someone else.

## Examine lifecycle boundaries

Upgrade the app with a partly uploaded report and an older queue schema. Show how the new version reads that work and how rollback would behave after the local database changes.

Remove background-sync capability from the test environment. The foreground path should still complete the job, with clear instructions if the app must remain open.

Inspect storage failure handling. The application should retain the editable screen when a save fails and distinguish replaceable cache content from irreplaceable pending work.

## Record the unresolved tradeoffs

A review may accept a defined maximum offline period or require managed devices for a sensitive workflow. Write those constraints into the product and support documentation so future changes do not assume broader guarantees.

For each unresolved issue, name the affected state and a proving test. “Improve offline reliability” is difficult to close. “Recover the accepted command after losing its response without creating a second report” gives the team a precise result to demonstrate.

## Sources

- [MDN: Background Synchronization](https://developer.mozilla.org/en-US/docs/Web/API/Background_Synchronization_API)
- [MDN: browser storage quotas and eviction](https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria)