---
title: Local Commit Boundary
status: draft
maturity: hypothesis
families: [mutation, authority]
scales: [L2, L6]
admission: research-candidate-only
---

# Local Commit Boundary

Context: an offline editor must survive an ordinary process restart after it tells
the user an edit is saved. Problem: immediate visual feedback is faster than storage
completion. `perceived-responsiveness` competes with `recoverability`; atomic storage
adds `implementation-complexity`.

Proposed solution: distinguish visible input from acknowledged local commit. Persist
the document revision and its pending-sync intent in one recoverable transaction;
only then report saved locally. This is a proposed design contract, not a claim
about Joplin or Obsidian internals. A storage error leaves the edit visibly unsaved.

Result: restart can reconstruct acknowledged work and pending propagation under the
selected storage assumptions. Remote acceptance is still unknown. Power loss, disk
corruption, quota exhaustion and device loss need separate guarantees and recovery.
The alternative of saving only in memory cannot satisfy the stated restart requirement;
waiting for a server commit cannot satisfy offline editing.

Evidence: LocalFirstEvidenceExpansion E01/E04/E05 motivates local storage and separate
sync; it does not establish this transaction or its crash guarantees. Known uses of
this exact boundary: unknown. Recurrence: unknown. Hypothesis only.

Proposed connection: enables [Pending Synchronization](PendingSynchronization.md)
when the transaction records the pending revision. This is a research relation,
not an admitted canonical edge. Test: [VC-02](../walkthroughs/VC02-OfflineFieldNotes.md).

## Recovery evidence boundary — 2026-09-26

Name the storage transaction and acknowledgement assumptions, then test ordinary
restart, interrupted commit and any claimed power-loss/flush behavior separately.
An untested guarantee is unknown, not demonstrated impossible. Synchronization or
a second copy on the same device does not establish independent backup protection.
Define a separate backup retention/failure scope and test restoration to a clean
store, including pending operations and their reconciliation, before promising
recovery from device loss or replicated deletion. Respect access and retention
policy during backup and restore. See [shared guidance revision](../reviews/SharedGuidanceRevision.md).