Scheduled deletion is a production change, and every record it removes needs a named owner, a downstream map, and a safe test before the job runs. If an automation depends on retained data, the team must decide whether to preserve a minimal derived record, change the automation, or stop the deletion until it can do so safely.
In April 1970, Jim Lovell, Jack Swigert and Fred Haise were in Apollo 13’s lunar module after an explosion had disabled their command module. The lunar module had carbon-dioxide scrubbers, but its square command-module canisters did not fit the lunar module’s round openings. Engineers in Houston had to work with the materials already aboard the spacecraft to make an adapter. NASA’s Apollo 13 Mission Report documents the failure and the response.
The problem was visible because the crew’s survival depended on it. Data dependencies rarely announce themselves so clearly. They surface as a failed nightly message, an empty account score, or a support queue that has stopped receiving the context someone assumed would always be there.
The deletion job exposed the system we had actually built
A retention policy can sound like housekeeping until the first scheduled run approaches. Then someone asks a plain question: what still reads this table?
The answer is often wider than the original product diagram. A customer record may feed an onboarding reminder. Its activity history may classify an account for a sales handoff. An old support conversation may provide the only text an internal assistant uses to draft a reply. None of those uses needs to be malicious or even badly designed. They may have been sensible shortcuts when the team had six customers, one engineer, and a roadmap that could not wait.
The risk comes from treating the database as if it were an archive with one purpose. In a small AI product, it is often also a training surface, an evaluation set, a workflow trigger, and a memory layer. Deleting records on schedule changes each of those things.
That is why “we have a deletion policy” is incomplete. The operational question is: which decisions, messages, and model outputs will change after this record disappears?
Find the hidden readers before they become incidents
Start from the data due for deletion and trace outward. Do not start with the services you remember building. Look at scheduled jobs, webhook consumers, exports, dashboards, prompt assembly code, CRM syncs, and manual spreadsheets maintained by someone in operations.
Three checks catch a surprising amount:
- Run the deletion against a copy of production data and compare automation outputs before and after.
- Search for the record identifier, customer email, and table name across code, workflow tools, analytics queries, and integration settings.
- Ask each workflow owner what minimum information they need after the original record is gone.
That last question matters because keeping everything “for safety” merely delays the decision. An onboarding automation may only need an account status and a timestamp. A reporting job may need an aggregate count. A support workflow may need a redacted case summary with a retention period of its own. Those are different records with different reasons to exist.
This is close to the ownership question in AI product defensibility: What Miriam’s Question Taught Founders About Workflow Ownership. A workflow is only defensible when the team can explain where its inputs come from, who can change them, and what happens when they disappear.
A retention rule needs an operating model
The smallest useful version is a deletion register. For each data category, write down the trigger, retention period, system of record, downstream readers, owner, and the test that proves deletion did not break an essential workflow.
Keep it close to the code and operating runbook. A document that lives only in a compliance folder will age quickly.
Then make the first runs deliberately boring. Delete a small cohort. Monitor the workflows that read from it. Check outputs the following day, especially any AI feature that assembles context from customer history. A model can continue producing fluent answers while quietly losing the evidence that made those answers useful.
The decision may be to delay deletion for one workflow. That can be the right call. Write down the exception, the reason, the owner, and the date it will be reviewed. “Temporary” data retention has a habit of becoming permanent when nobody owns the next decision.
The useful artifact is the map, not the cleanup
Apollo 13’s engineers could build an adapter because they knew the physical constraints of the spacecraft and the materials available to the crew. Your team needs the equivalent map before the deletion job runs: what data exists, where it travels, and which customer-facing action changes when it is removed.
A scheduled deletion should leave behind fewer records and better knowledge. If it only removes rows, you may have cleaned the database while making the product harder to reason about.
Before enabling the next run, choose one customer record due for deletion and follow it through every automation by hand. The gaps you find there are cheaper to fix than the ones your customers find first.
Comments
No comments yet.