Deletion is recoverable archival
The architecture's durability section has a sentence that reads like a slogan and works like a rule: deletion is recoverable archival. Assets, batches and preset collections carry an archived flag. Setting it moves the record out of the default views. The row stays, the original stays, and clearing the flag brings it back. Assets could be archived from the birth night, 2026-09-29, already with a refusal for anything still in use. Batches and preset collections gained the flag the next day.
What archived means for each kind of read
- Listing hides it. The image library shows unarchived assets unless the request asks for
archived=true, and the Batches page hides archived batches until the Archived box is ticked. The one exception is the batch you have open: archive it, or untick the box while it is selected, and it stays in the list, marked(archived), so it does not vanish under your cursor. - Use refuses it.
Studio.assetis the door every reference, every choice and every publication frame goes through, and it refuses an archived image withThis image is archived. Restore it before use.An archived picture cannot quietly come back as a reference. - Policy ignores it. The comment above
export_policysays it: an archived copy of a protected image is still a protected image. Archiving is housekeeping, never a way out of protection. Protection Follows the Pixels picks up that thread.
What keeps an original alive
Archiving an asset is a PATCH with archived: true and the version the client read. Before the flag changes, the route asks four questions. Each yes is a 409 with a sentence that tells Dad what to do instead.
| Still used by | What the refusal tells Dad |
|---|---|
| the frames of any publication, past or present | it is retained by publication history and must stay available for recovery |
| a set's published map or its current selection | replace that use in the set before archiving |
| a reference profile or a saved look | replace that use in the profile or look before archiving |
| the references of an unfinished task: queued, preparing, submitting, running, copying or uncertain | finish or cancel that generation first |
Publication history is the strictest row, because it covers the past. A publication is a frozen snapshot, and restoring an earlier one sends those exact originals back to Pippa. The publish preview reads every frame through Studio.asset, so one archived original would turn an old publication into a restore that fails.
Batches and collections
A batch can be archived once nothing in it is still working. A task that is queued, preparing, submitting, running or copying blocks it with Finish or cancel this batch's running images before archiving it. One detail is worth noticing: the asset rule counts an uncertain task as unfinished, and the batch rule does not. A batch whose only open question is an uncertain task can be archived, while the references that task used stay pinned.
A preset collection, such as a chef set, can be archived. The standard/default collection never can: The default collection anchors this soul's references and cannot be archived. In default mode, a soul's reference profile resolves to the default frame of that collection, so archiving it would pull the floor out from under every new picture of that soul. That refusal comes back as a plain 422 rather than a 409: nobody else's write is in the way, the rule simply forbids it.
The one delete
Store.delete exists, and its docstring draws the line: only records that carry no lineage, the editable settings, are ever deleted. It has exactly one caller. Resetting a workflow template removes Dad's saved text, and the workflow falls back to its seed. No picture names a template as an ancestor, so nothing is lost but a setting Dad chose to drop. Nothing in the engine removes an original either. The only file removal in the backend is the family kit's atomic writer cleaning up its own temporary file after a failed write.
Why the studio is this stubborn
Avatars exists to hold a second durable copy of every picture that matters, so that cleaning up Ember's history can never take a chosen avatar with it. A delete button would reopen that hole from the inside. Archival gives Dad a tidy library without making anything unrecoverable, and the refusals make sure a tidy-up never breaks a set, a profile, a running job or a restore.
The test for all of this reads like a short story. It uploads a reference and a stray image, puts the reference into a default set, and fails to archive it. It renames the stray and archives it, and watches it leave the library and show up under archived=true. It fails to archive a batch with a queued task, cancels the task, and then succeeds. Last, it tries to archive the default set and gets the 422.