What local-first protects
Contracts, task state, event history, and delivery packages are designed to persist locally. This keeps the work available for inspection and recovery even when a hosted session is not.
It also gives the user a clearer ownership model: the source of truth is a portable store they can retain, back up, and export.
When data leaves the device
Some capabilities necessarily use an external destination. Web research may send a query to a search provider. A cloud model processes the prompt. An external email creates a side effect that cannot be recalled.
A mature product does not hide these facts behind the phrase local-first. Each capability should declare its data boundary and side effect before it can be selected.
The boundary should be part of the decision
When the task contract and capability card say that data may leave the device, the system can require confirmation for that specific action. The user sees the destination, the purpose, and the effect.
The policy should not ask for approval on every low-risk local operation. Confirmation is most useful when it is rare and consequential.
Precise claims build more trust
“Your data stays on your device” is a strong statement that may not be true for every workflow. “Task state is local by default; external capabilities are explicit and constrained” is more accurate and more useful.