Encryption is not a boolean added at the end of a save. It changes a Memory's text, external links, files, visibility constraints, and derived data. If that multi-step transition fails, the safe result is to preserve the prior state—not silently save a readable replacement.
A protection change is a transaction
Turning an existing Memory into Protected writing & files replaces multiple stored representations: title, rich-text body, link values, attachments, inline images, derived summaries, and visibility state. Updating only one field and setting an encrypted flag would create a misleading mixed state. The atomic transition design covers the coordinated workflow.
A locked vault blocks the protected save
Protected content needs the browser's unlocked Master Key. If the vault is locked, the editor leaves protected content unavailable rather than submitting the current text as Standard. This is a deliberately less convenient failure mode: it avoids turning an encryption problem into an unnoticed plaintext write.
Uploads create an intermediate stage
Files cannot be folded into one database write. The browser encrypts and uploads candidate blobs before the Memory record can attach them atomically. An upload succeeding therefore does not prove the Memory is protected; it is only an intermediate state that needs a later ownership and cleanup decision.
The final commit names the state
The server validates the encrypted payload shape and current Memory version, then persists the replacement fields, attachments, and protected state together. If it cannot do so, the original Memory remains the current representation. The protected state also forces private visibility, so a failed transition cannot leave newly encrypted data halfway into a public route.
Failure still needs cleanup
A safe failure path must identify blobs uploaded for an abandoned transition without purging files that became attached to a Memory. That is an integrity concern as much as a storage-cost concern. See the abandoned-upload cleanup note for the lifecycle distinction.
Test the failure paths
Useful tests lock the vault, interrupt an encrypted upload, submit a stale editor version, reject invalid encrypted payloads, and verify that no plaintext replacement appears after each failure. The browser encryption test strategy treats those negative cases as part of the security guarantee rather than optional edge coverage.