Offline IoT: specify continuity, storage and recovery separately
"Works offline" is not a specification. A promise you can hand to an operator or an integrator answers three questions separately: which functions keep running while the system is disconnected, how much history the configured storage can actually retain, and which checks must pass before recovery is considered complete. Write all three down as an offline operating contract for the actual configuration — do not infer it from the mere presence of an edge computer or a local dashboard.
Specify what continues
Name the accepted functions that must remain effective without central services: sensor collection, declared local control and deterministic safety behaviour. State the behaviour after a local restart as well as during a network interruption. Keep operator access separate: continuing a control function does not mean a cached user session stays authorised indefinitely.
State the history boundary
Local storage is finite. Commercial platforms make this concrete: Microsoft's Azure IoT Edge documentation states that upstream messages are stored until reconnect, the default message time-to-live is 7,200 seconds (two hours), expired messages are not delivered, and longer offline periods need a raised TTL and/or more disk space (Microsoft Learn).
Whatever the platform, define which data is buffered, how storage pressure is detected and what happens when capacity is exhausted. If history is lost, the system should expose the gap rather than present the surviving records as complete. And use measured storage and workload evidence before promising an offline duration — a design requirement is not a tested retention period.
Make stale commands expire
Queued commands have lifetimes too. In MQTT 5.0, the Message Expiry Interval defines a message's lifetime in seconds, and the server must delete its copy for a subscriber if that lifetime elapses before onward delivery (MQTT 5.0 specification); session state likewise survives a disconnect only while the Session Expiry Interval is non-zero. Apply the same principle in your own application logic: a stale queued command must expire rather than execute merely because the connection came back.
Separate reconnect from recovery
A reconnect is not recovery. Reachability, fresh required data and accepted buffered history are three separate conditions. An illustrative recovery sequence separates them: the node answers, new measurements arrive, and buffered history is accepted centrally — these need not happen together, and a device that answers a ping while holding stale data is not yet healthy. Azure's documentation notes a related trap: a disconnected IoT Edge device cannot report deployment status, so a portal can keep showing stale status (Microsoft Learn).
Before resuming deferred changes, revalidate identity, permissions, configuration and input freshness. The exact checks depend on the system and its risk assessment.
Test the contract
Create a permitted interruption test with clear expected local behaviour and recovery evidence; include restart and storage-pressure scenarios where appropriate and safe. This test method is an editorial synthesis for writing your own acceptance check, not a published standard. The result should be a scoped statement — these functions continued, these gaps occurred, these recovery conditions were verified — which is more useful than an unlimited "offline capable" label.
Where MIND AIoT stands
Manna MIND AIoT is designed offline-first at the edge as a principle: accepted applications, sensor collection, declared local control and deterministic safety continue without cloud connectivity; buffered data catches up only with acknowledgement after the cloud accepts it; and health is reason-coded so a returned connection does not automatically clear stale-data alarms. This describes the accepted design baseline, not a verified release or an unlimited offline promise.
If you need such an operating contract specified and tested for your own facility or equipment, discuss a project with Manna Insect. For how the work splits between edge and cloud in normal operation, see Edge vs cloud IoT responsibilities.
Prepared with AI assistance for Manna Insect Oy.