Retention and erasure
What is kept, for how long, and how a deletion request is honoured without destroying the audit trail.
There is a genuine tension here and it is worth naming rather than hiding: the raw captures that make every figure auditable are also the largest body of stored data, and a deletion request has to be honoured against them.
Tiered deletion
| Tier | Policy |
|---|---|
| Result rows (scores, counts, classifications) | Permanent. These are the trend line; deleting them retroactively invalidates every report already delivered. |
| Answer payloads and answer text | Erased on a twelve-month rolling window, or on request, whichever is sooner. |
| Tombstone | The row survives with its payload removed, so a link to an erased capture answers “deleted” rather than “not found”. |
On request
An agency can request erasure of a brand's captures at any point — on contract end, for example. Stored objects are deleted before the row that references them, because the storage key is derivable only from the row: reversing that order would orphan the object permanently.
Sizing, for context
A brand at fifty prompts, six engines, three samples, weekly, generates roughly 47,000 captures a year averaging about 57 KB each — around 2.7 GB per brand-year. This is a cost line and a retention question, not an implementation detail, which is why it has an explicit policy rather than a default.
See it against your own client list
A working demo runs your prompts, in your market, on live engines — not a sandbox with seeded data. Bring one client brand and three competitors.