# Eve data-rights propagation — Task 14.4

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.