Six months of retention is not an archive strategy
A retention floor tells you when you may delete, not when you will be asked. Most of the questions that matter arrive well after month six, and by then the problem is not storage cost, it is that nobody can read what you kept.
A number in a regulation is an unusually effective way to stop a conversation. The EU AI Act’s Article 12 sets a retention floor of six months for the logs it requires, twenty-four for biometric and law-enforcement uses, and the moment that number reaches an engineering team it becomes a configuration value. Someone sets a lifecycle rule to 180 days, the ticket closes, and the organisation believes it has an archive strategy.
It has a deletion schedule. Those are not the same thing, and the gap between them is where the expensive surprises live.
My position: retention length is the least interesting property of an archive, the questions you will actually be asked mostly arrive after your floor expires, and the hard part is not keeping bytes but keeping them meaningful. I am not a lawyer and none of this is legal advice.
A floor is not a design
Read what the floor is for. It is a minimum below which a record is considered unavailable for the purposes the requirement cares about. It is written as a lower bound because regulators cannot know your risk profile, your product lifetime or your liability window.
Building exactly to a lower bound is a specific decision, and it is almost never the one the organisation would make if it were asked directly. Ask an engineering leader how long the code merged last Tuesday will be in production and the answer is years. Ask how long the record explaining why it was merged should survive and the answer, implied by the lifecycle rule, is six months. Those two answers are incompatible and nobody has ever chosen the second one on purpose.
The questions arrive later than you think
This is the part that changes minds, so it is worth laying out against a calendar.
The remediation case is the one I would put in front of a finance director. Reconstructing why a change was made, from a codebase alone, is enormously more expensive than reading a record you kept. CAST’s estimate of global technical debt runs to something like 61 billion workdays, which is a number too large to mean much, but the shape of the cost is right: most of the effort in remediating unfamiliar code is establishing intent, not editing.
Bytes are cheap. Meaning is not.
The objection to longer retention is always cost, and for delivery records that objection does not survive contact with arithmetic. A structured record per change, holding what acted, what it acted on, what authorised it and which checks passed, is a few kilobytes. Even a very busy organisation produces less of this in a decade than it produces in application logs in a week.
The real cost is interpretability. A record written today has to be readable in four years by someone who does not have your current tooling, does not know your current team, and cannot ask anyone what a field meant.
That produces three design rules, and they are cheap now and impossible to retrofit.
Self-describing over referential. A record that says policy_id: 47 is worthless once that policy table is gone. Store the resolved values you will need to read later, even though it duplicates.
Stable identifiers over live links. A URL into your current tracker is a promise that you will still be running that tracker, on that domain, with those identifiers. Keep the URL by all means, and store the ticket key, title and criteria text alongside it.
Schema versioned and never silently reinterpreted. When the meaning of a field changes, add a field. A quiet redefinition makes every historical record subtly wrong in a way nobody will detect until it matters.
Retention
How long you keep it. The only property most policies specify, and the easiest one to get right.
Retrievability
Can you produce all records for one change, or one quarter, in an afternoon? A tape you cannot search in time is a record you do not have.
Interpretability
Will the fields still mean what they meant, to someone with none of your context? This is the property that decays silently.
Disposal
What is deliberately destroyed, when, and with what evidence that it was. Keeping everything forever is a liability, not a strategy.
Disposal is part of the argument, not against it
I am arguing for longer retention of a narrow class of record, and that argument fails if it collapses into keeping everything.
Delivery records containing prompts and diffs can carry personal data, customer content and credentials that were pasted where they should not have been. Every additional year is additional exposure in a breach and additional scope in a discovery request. The organisations that end up in the worst position are not the ones with short retention. They are the ones with no policy at all, holding eleven years of everything in a bucket nobody owns.
So the strategy has two halves. Keep the structured record of what happened and why, for as long as the code it explains is in production plus your liability window. Keep the raw material, the full prompts, intermediate outputs and model responses, for a short, deliberate period and then destroy it on a schedule you can evidence.
Where this breaks down
Legal may want less, and they may be right. Retaining more than you must is discoverable, and counsel will sometimes tell you that a shorter window is the correct risk position. That is a legitimate answer from people who know the exposure better than engineering does. What is not legitimate is deleting by default because nobody asked.
Longer retention of the wrong thing is worse than nothing. Four years of records with an untrustworthy schema, gaps where a pipeline was down, and no evidence of integrity gives an investigator something to attack rather than something to rely on. If you cannot keep it well, a defensible short window beats a sloppy long one.
Nobody rehearses retrieval. The failure I see most often is an archive that technically exists and has never been queried. The first retrieval attempt happens under pressure, discovers the export path was never built, and burns two weeks. If you extend retention and do not exercise it quarterly, you have bought storage rather than capability.
The floor may genuinely be enough for you. If your systems are short-lived, your regulatory surface is narrow and your code does not persist, six months may be the right answer arrived at by accident. My argument is that it should be an answer you chose, with a reason you could give out loud.
And this is a governance desk arguing for more governance. Discount for that. The specific test to run against your own organisation, rather than against my reasoning, is whether any question asked of your delivery record in the last two years could have been answered from a 180 day window.
The takeaway
Six months is a floor, and floors are written for the least demanding case. Your code outlives it by years, your liability outlives it by longer, and the questions that require a record almost all arrive after it expires.
Set retention against the lifetime of what the record explains. Then spend the effort where it actually goes: making records self-describing, retrievable in an afternoon, and interpretable by someone who was not there.
If you take one thing into next week: ask for every delivery record from a single change made nine months ago. The time it takes, and what comes back missing, is your archive strategy stated honestly.