What the SDK handles - Offline Protocol

Use Offline Protocol when devices need to exchange information or use each other’s services directly. Examples include a driver handing work to a yard operator, a technician reading nearby equipment diagnostics, and two devices editing a shared checklist.

Responsibilities

Offline Protocol	Your application
Device addresses and session cryptography	Enrollment, account binding and authorization
Discovery and routing over configured transports	Hardware selection, OS permissions and deployment topology
Message acknowledgments, bounded retries and queues	Durable business records, acceptance rules and expired-work handling
Document replication and deterministic merging	Data model, access boundaries and business invariants
Service discovery and request/response	Provider selection, implementation, deadlines and safe retries

Keep your backend

Your system of record remains authoritative for the records it owns. A local application can finish an authorized handoff before the backend is reachable, retain the result, then submit it through your existing API or a destination adapter. Define when that backend has durably accepted the record before clearing the local queue.

Choose the right primitive

Use a message for an event or acknowledgment, a document for shared current state, and a service request for an operation on a selected provider. They solve different parts of a workflow and can be used together. Start with a local handoff, shared state or a nearby service.