"An adornment may fail without downgrading the existence of the original."
Name the protected result
If translation or audio fails, the hand still has a passage. Deleting or hiding the entry would let an optional service revoke the meaningful result after it was honestly delivered.
Put the promise in state
Store the compact error on the failed job and each attempt in job_attempts. Retryability is derived from failed status; it is not a second persisted truth. The entry remains queryable and its adornment slot reports failed instead of pretending empty means never requested.
The quiet failure
A cheerful spinner that runs forever is less honest than a visible failure. Automatic retry without a cap can burn resources and keep state ambiguous. Recovery must be explicit enough for both the writer and the worker.
Trace five moments
To test “Failure Keeps the Entry,” inspect the moment before creation, after commit, when a worker claims the job, when output returns, and on the next-day reload. At each point record entry state, job state, captured source text, and visible copy. A promise that survives only the successful request is conditional sovereignty.
Do the work
Design the UI state for an original with one succeeded, one failed, and one pending adornment. Add source editing, entry deletion, worker restart, and external-service failure to the same table. Mark when dropping an output is integrity preservation rather than data loss.
The final question
Does the screen keep the original visible while telling the truth about work around it? Then adornment serves. If a spinner hides failure or a late result overwrites current text, the adornment has stolen the throne.
Landing condition
A failed durable job exposes its error, its attempt history, and a retry action derived from failed status. The original entry remains live, and on-demand voice failure never invents an audio job or artifact row.
Failure belongs to the optional work that failed, not to the passage that already exists.