Date: 2026-09-15
Scope: deletion, export, legal-hold conflict, and no-resurrection behavior
Machine record: docs/audits/eve-sota-data-rights-propagation/2026-09-15.json
Result#
The candidate binds all fifteen named Task 14.4 data families to an explicit lifecycle class and to deletion, export, legal-hold, and no-resurrection postures. A semantic verifier requires the exact inventory, exact posture for each family, live source and test tokens, the two legal-hold checkpoints, the pre-HTTP recovery replay, and four exact non-claims. Ten mutation controls must fail before the committed record is admitted.
Durable subject stores are reached through the account-wide signed deletion fan-out. The same fan-out is wrapped by a live legal-hold resolver both at request intake and immediately before mutation, so a hold placed during a grace period produces an HTTP 409 conflict, leaves the request scheduled, and invokes no eraser. A completed deletion is then recorded in the independent encrypted recovery journal. On process boot, verified receipts replay through the original idempotent fan-out after ordinary snapshot hydration and before HTTP admission, which removes rows restored from an older database or object backup.
Export closure#
The existing customer bundle already covers conversations, semantic memory, personalization vectors, generated media, schedules, notification state, channel identity, and the wider profile/session/support families. Task 14.4 adds the durable operational partitions that deletion already erased:
- operator memory;
- assistant audit runs and trace-adjacent state;
- assistant turn-cancellation/effect records;
- governed agent-run lifecycle, cost, and control state; and
- watchers across every tenant partition when the PostgreSQL watcher authority is configured.
The watcher reader is exact-user scoped and ordered. When the deploy-bound operator-memory or watcher PostgreSQL authority is unavailable, the export names the affected coverage gap instead of fabricating an empty result.
Non-durable and non-subject families#
Tool-result arrays, sanitized screenshots, and raw voice recordings are bounded to the active request/turn locally. They have no independent local export row or post-request deletion target; durable derived text follows its owning conversation, memory, audit, or artifact store. Checked-in eval datasets are static governed assets and are rejected if the privacy scanner detects subject data, so they are not reclassified as a hidden customer store.
Workbench DCC records contain attributed metadata, content hashes, and storage references. Those rows and their ledger are redacted by the exact-subject workbench eraser and replayed after backup restoration. Registered generated media/object versions use the generated-artifact eraser and customer export. No unregistered owning DCC binary store is admitted or claimed.
Exact limitations#
- Screenshot and recording bytes are not retained locally. Provider no-retention admission comes from Task 14.2; this task does not claim an independently observed provider-side deletion operation.
- Workbench metadata/reference propagation is covered, as are registered generated-artifact stores. Unregistered DCC binary custody remains denied; complete attachment and generated-file lifecycle policy remains Task 14.8.
- Eval fixtures must remain subject-free. User-derived feedback, audits, and review records stay in their governed runtime partitions and are not excused as static datasets.
- The encrypted recovery journal intentionally retains only the minimum completed-erasure receipt needed to prevent backup resurrection. It is not a customer-content store and is withheld from subject export.
Task 14.4 does not set retention periods or admin-access policy (Task 14.5), make jurisdictional compliance claims (Task 14.6), or close Phase 14/G16.