Define result deletion boundaries

docs/spec/architecture.md

@@ -121,6 +121,15 @@ flowchart TD
 - A Hugging Face branch or tag is resolved once to a full commit. The source identity includes repository type and ID, that commit, and the exact file inventory with Git blob or LFS identities. Retries and cache reuse remain pinned to the stored commit and member identities.
 - A checkpoint never authorizes best-effort concatenation. An unavailable explicitly pinned or resolved snapshot produces a structured source-changed outcome rather than silently resolving a newer snapshot.
 
+## Result Visibility and Deletion
+
+- `JobProtocol` remains the sole owner of execution phase. Deletion never rewrites a terminal execution outcome and is available only after a job is terminal; cancelling active work remains a separate protocol operation.
+- Soft deletion tombstones Remora visibility immediately without deleting target objects. It is idempotent and may be restored until hard deletion begins.
+- Hard deletion atomically tombstones visibility and creates one durable, idempotent deletion operation. Once that operation exists, the result cannot be restored even while physical deletion is pending or retrying.
+- A hard-deletion operation uses the `ResultManifest` and durable attempt ownership to materialize exact deletion work with bounded memory. It removes committed members and eligible attempt data, treats an already-missing exact identity as success, and deletes the manifest only after its members.
+- Physical deletion is asynchronous and recoverable across worker loss and transient target failures. It does not depend on client request lifetime or reconstruct work by listing a target prefix.
+- A permanent minimal tombstone retains job identity, owner, terminal outcome, deletion identity, and audit timing. Retention of more detailed job metadata is deployment policy and never restores result visibility after hard deletion begins.
+
 ## Requirements
 
 ### Functional Requirements