Concepts
Saved, durable, backed up
Three states, with three different guarantees.
Saved
An application write can return while data is still buffered in runner memory. Abrupt runner loss may lose these changes. Do not label a write durable solely because the guest reports success.
Durable on live storage
A successful flush must reach the trusted storage path and its durable backing store. Earlier prototype experiments measured small atomic saves including file and directory fsync. The integrated service has not yet passed real storage transport qualification; durability under additional failure scenarios remains a release gate.
Backed up
A checkpoint published to the configured bucket is an independent recovery point. A snapshot kept only on the live pool is not an independent backup. The default checkpoint call waits for verified bucket publication. An explicit wait_for_publication=false response with captured_at confirms a retained live-pool snapshot; captured/pending is not an independent backup.
Submission lifecycle
Briefly stop accepting edits and flush saved work before requesting a checkpoint to define a submission boundary. Capture keeps the current writer mounted, and its lease can renew during upload. Wait for verified publication before declaring the submission independently backed up. Explicit wait_for_publication=false returns after a retained snapshot is captured; edits may resume while publication continues. If publication fails, keep the backup pending and retry with the same operation ID.