Edits made offline must be mergeable on reconnect, not discarded

What it is

Edits made while disconnected — the paragraph revised on the subway, the spreadsheet adjusted in airplane mode, the annotation written in a dead zone — must enter the system on reconnection as pending changes to be merged, not be discarded on the grounds that "offline state doesn't count." This requirement turns offline from a fault state into a normal operating mode: the right to edit does not depend on the connection; the connection only carries propagation. The user-level test: any valid operation performed offline must, after reconnection, appear either in the result or in the pending-conflict queue — everything except silently evaporating.

Why it happens

A system that discards offline edits treats "connection" as the source of an operation's legitimacy: a command that did not reach the server in real time is treated as never having happened. That model barely held in the desktop-broadband era (disconnection was rare) and collapses under mobility — commutes, travel, and dead zones are daily life. If every outage gambles the edits, users fall back on defensive local backups, and the core value of a collaboration tool (feeling safe putting work into it) dissolves. The mergeable-offline model returns legitimacy to the operation itself: edits land in a local queue carrying target, time, and intent; on reconnection the queue replays and merges with server state. The merging machinery (automatic fusion or conflict presentation) is an old concurrency problem; offline's real increment is at the two ends of the queue: the disconnect moment must switch to local mode seamlessly (no error dialog, no locked features), and the reconnect moment must tell the user "you have N changes merging now, and here is the outcome." The longer the outage, the more others have changed and the higher the conflict probability — so the metadata of offline edits (when made, against which revision) must be preserved intact, because it is what decides "can this still merge automatically" on reconnection.

Where it stops holding

Mergeable offline is not equally applicable to every collaboration type. Offline editing of text and free canvases is mature (fine-grained, semantically forgiving); strongly competitive operations (claiming a slot, decrementing stock) cannot execute offline — a local "success" may already be taken by someone else at reconnect, so such operations can only queue for confirmation offline and must never display as completed. Real-time collaboration (co-driven demos, joint device operation) loses its meaning offline, and the correct offline behavior there is pause and notify, not accepting further operations. The viable offline horizon also scales inversely with conflict density: a document under heavy co-writing may accumulate, after half a day offline, conflicts whose merging costs more than rewriting; low-conflict contexts (personal notes, lightly shared artifacts) tolerate days offline without strain.

Applying it

• On disconnect detection, switch to local mode silently: editing continues, with a persistent "offline — changes will sync later" status.
• Persist the local operation queue with full metadata (target object, base revision, timestamp) to feed reconnection merging and conflict detection.
• On reconnect, replay and merge automatically, then report: what merged cleanly, and which conflicts arose (routing into conflict handling — never a silent pick).
• Mark strongly competitive operations "pending confirmation" while offline; never show them as completed.
• Verification: across a gradient of outage durations from one minute to one day, perform each operation type and, after reconnection, account for every item: in the result or in the conflict list. Any third outcome (vanished) is an incident-grade defect.

Related

• Same group: V3.06.1 Local-first display masks latency but brings later rollback · V3.06.2 Rollback changes content that was already seen, which confuses more than waiting · V3.06.3 Temporary divergence between clients is the norm in synchronous collaboration, not a fault · V3.06.4 Degrading connection quality must be signaled explicitly, not silently
• Nearby: V3.01 Concurrent Editing · V3.02 Conflict Handling
• Search terms: offline-first · reconnection merge · local operation queue · disconnected operation