How would you set a retention policy for archived test cases and their execution evidence in a managed case repository, so the tree stays navigable without discarding what a past release was signed off against?
answer
- navigability is not custody
- age is the wrong trigger
- cases outlive their executions
- hide the layer, do not destroy it
- a quiet rule looks like a stopped one
basics
~20 sTier retention by what the record proves: archived cases stay while the releases they evidence are supported, executions live as long as their release, and the tree hides rather than destroys. Enforce the rule in the tool, not by hand.
solid answer
~50 sStart from what each record proves rather than from how old it is. An execution is evidence for a specific release, so its retention follows that release's support life. An archived case is the thing an execution resolves against, so it must outlive every execution that names it — which makes archived cases the longest-lived tier, not the most disposable one. Navigability is a separate problem and gets a separate answer: hide the archived layer from the views people plan in, rather than destroying it to shorten a list. Write the rule as classes of record with a trigger, not as an age threshold, get the owner of the releases to approve the first cohort it would remove, and enforce it as a scheduled action inside the tool that reports what it did. A retention rule nobody can see running is indistinguishable from one that has stopped.
go deeper
Know that retention means deciding how long records are kept, and that hiding retired cases from the planning views is a different action from deleting them.
Explain why retention should follow what a record evidences rather than its age, and why an archived case has to outlive every execution that still names it.
Show how you would actually operate it: dry-run the rule, look at the first cohort it would remove, automate it in the tool, and review the report each run produces.
Own the tradeoff between keeping everything, tiering by what a record proves, and deleting by age — and place the sign-off with whoever is accountable for the releases, not the tool.
## What retention is actually for A case repository accumulates. Cases are archived, cycles close, and the estate becomes harder to navigate every quarter. Two distinct complaints hide behind the word retention, and conflating them is the classic mistake: - **Navigability** — planners cannot find current work in a tree full of retired material. - **Custody** — the organisation is holding records forever with no statement about how long it intends to. Only the second is a retention question. The first is solved by *filtering*, and reaching for deletion to solve it is how signed-off evidence gets destroyed to shorten a list. (Evidence that captures real personal data carries obligations of its own, decided outside this policy; what follows is about the case and execution records themselves.) ## Age is the wrong axis The intuitive rule — remove archived cases older than some threshold — is wrong on its face, because age has nothing to do with whether the record is still doing work. A case archived long ago may be the only thing that explains a pass on a release still running in production. A case archived last month may back nothing at all. The right trigger is **the life of the thing the record evidences**: | Record | Retention follows | Removable when | |---|---|---| | Execution | the release it was recorded for | that release is out of support | | Archived case | every execution that still names it | nothing resolves against it any more | | Cycle or run container | its executions | its executions have gone | | Never-executed draft or duplicate | nothing | immediately, on judgement | Read the second row carefully: because a case must outlive every execution naming it, **archived cases are the last tier to go, not the first**. Policies that delete cases while keeping executions produce exactly the unreadable rows that make an audit fail. ## Keeping the tree navigable without destroying anything - **Make archived the default exclusion** in every view where work is planned or selected, so the archived layer costs planners nothing. - **Give the archive its own navigation** — retired material browsed on purpose, not encountered by accident. - **Fix saved filters and exports written against raw attributes**, which are the usual route by which archived cases leak back into current views. - **Retire whole subtrees rather than individual cases** where you can, so the archive stays structured instead of becoming a flat heap. - **Label the archived layer visibly**, so nobody mistakes reachable old text for current specification. ## Writing a rule that will actually be trusted 1. **Express it as classes of record with triggers**, never as a single age number. A rule anyone can apply mentally to a record in front of them is a rule that gets followed. 2. **Dry-run it and show the first cohort.** Approving a policy in the abstract is easy; approving the actual list of records it would remove is instructive, and frequently changes the policy. 3. **Get the owner of the releases to sign it**, not the tool administrator who implements it. Whoever is accountable for what shipped is accountable for what proves it shipped. 4. **Automate it inside the tool.** A rule executed by a person once a year is a rule that stops the year that person is busy. 5. **Make each run report** what it archived, removed and skipped, and review that output. A quiet rule and a disabled rule look identical. 6. **Re-derive it when support terms change.** A release whose support is extended has just extended the retention of everything backing it, and nothing tells the policy that automatically. ## The tradeoffs you are actually making This is a judgement call, and the defensible positions differ: - **Keep everything forever.** Zero evidence risk, and it degrades navigability and cost indefinitely. Reasonable in regulated estates where deletion needs its own justification. - **Tier by what the record proves.** The balanced position described above. It costs more to design and needs periodic re-derivation, but it never surprises an auditor. - **Delete aggressively by age.** Cheapest, and the only one that can destroy the evidence for a release that is still live. It is almost always chosen because a tree got hard to browse — a problem filtering would have solved for free. A good answer names the axis (what the record proves, not how old it is), separates navigability from custody, and puts the sign-off with the person accountable for the releases rather than with whoever operates the tool.
- Who signs off a retention rule that will eventually destroy records, and what do they need to see before they do?The person accountable for the releases the evidence backs, not the administrator who implements the rule. They need the classes of record it touches, the actual first cohort it would remove, and what stays readable afterwards. Approving a policy in the abstract is easy; approving the concrete list is what surfaces the exceptions.
- How do you keep a retention rule from silently stopping?Make it report. A rule that runs quietly is indistinguishable from one that has been disabled, so each run should emit what it archived, what it removed and what it skipped, and someone should read that output on a schedule. A long stretch of removing nothing is a signal to investigate, not a success.
- A release you thought was retired gets its support extended. What does that do to your policy?It extends the retention of everything evidencing that release — its executions, and every archived case they resolve against — and nothing propagates that automatically. This is why retention has to be re-derived when support terms change, and why an age-based rule is dangerous: it would have kept counting down regardless.
saying these in an interview costs you the question
- Sets retention by age alone, ignoring release support
- Deletes archived cases to make the tree shorter
- Removes cases while keeping executions that name them
- Leaves the rule as a document nobody enforces
- Has the tool administrator approve destroying evidence