Retention Clocks and the Signed Record
Elena Volkov · · 9 min read
Inference gets the architecture diagrams. Deletion gets a paragraph at the end of the DPA. That is backwards. If you cannot prove what you destroyed, and what you were required to keep, you do not have a record. You have a pile.
We shipped retention as a clock on the signed record, not as a bucket lifecycle someone remembers to run.
Classes
Every project chooses a retention class. Production legal and risk cannot choose none.
ephemeral: payload dropped after success; hash kept for the evidence windowstandard: payload kept for the clock (default 90 days unless the tenant sets shorter)matter_hold: clock paused until hold is lifted by dual controlexam_pack: extended keep for named runs the control function flagged
The class is in the policy bundle hash. Changing class on a project does not rewrite history. Old runs keep the class they were born with unless a hold is applied.
Purge is dual control
When a clock expires, purge is automatic for standard payloads. It is still an event: what was hashed, what was dropped, who (system) executed it. Manual purge before the clock, or any purge under matter_hold, requires two humans. The model cannot request purge.
We had a tenant ask for "GDPR delete everything about this vendor" as a single button. We refused the button. Subject-access and erasure are a legal workflow with counsel, not a rm. The product can find runs by matter ID and apply hold or scheduled purge. It will not pretend a prompt store is a CRM.
Holds beat clocks
A hold is louder than a clock. If litigation or an examination lands, control officers apply hold on the matter ID. New runs on that matter inherit hold. Expired clocks do not fire.
Lifting a hold is dual control and writes why. We have seen holds left on for eleven months because no one owned the lift. That is now a monthly report to the project owner: holds older than 30 days, named.
Product, not folklore
Retention used to live in a runbook and a hope that logs compacted. It now lives next to routing and residency in the policy page a committee can read. If the clock is not in the record, we do not say we retain. If the purge is not in the record, we do not say we delete.
That is the whole feature. It is also the whole point.
Elena Volkov
Head of Product
Elena Volkov is Head of Product at Eridian. She translates supervisory and operating requirements into workflows that legal, operations, and risk teams can execute, review, and stand behind on the same system. Her work is to keep the product aligned to institutional standards rather than to novelty, with one operating surface, one review path, and one record.
