When you download a hosted browser run's recording, whose keeping period then applies?

## Retrieval forks the clock, it does not move it The mental model people carry is that an artefact has one location and one lifetime, and that fetching it relocates both. It does not. Fetching produces a **second copy**, and from that moment there are two keeping periods running in parallel: - The provider's copy, governed by whatever the account and the product settle — a value you have to establish rather than assume. - Your copy, governed by whatever the place you put it does, which is usually nothing in particular. Neither one reaches the other. If the supplier expires its copy, yours is untouched. If you delete yours, theirs is untouched. That is the part people most often get backwards: they retrieve a file for a good reason, and then reason about its lifetime using the supplier's rules, which no longer apply to the thing in their hands. ## Where the copies actually land Retrieval is rarely a single act, and each hop makes another copy with another owner: - **A defect ticket.** The most common destination, and the most durable — issue trackers are designed to keep history, not to expire it. - **A chat thread.** Often searchable indefinitely, and visible to a wider group than the run ever was. - **A shared drive or a wiki page** attached to a post-incident write-up. - **A build cache or a job artifact**, if the retrieval happens inside a pipeline. - **An object bucket you control**, where a fleet pushes material for you on purpose. The last one is the deliberate version, and it is worth calling out because it is usually a good idea. Pushing run material into storage you own gives you something you did not have before: the ability to enforce a period at all, rather than establishing somebody else's. It also transfers the duty completely. The moment the bytes land in your bucket, the question "how long is this kept?" has exactly one answer, and it is whatever your team configured — including "forever" if nobody configured anything. ## The provider's interface is a store, and so is your tracker There is a habit of treating the supplier's run history as a system of record — the place where the evidence lives, searchable, always there. Two things go wrong with that reading, and they pull in opposite directions: 1. **It may not always be there.** Material held under a period you did not set can stop being available precisely when a regression investigation needs it, and no code of yours will warn you. 2. **What you took out of it is still there.** Every copy made in a moment of urgency — a video attached to a ticket, a screenshot pasted into a thread — outlives the urgency that created it by a very long way. So the supplier's store is simultaneously less durable than teams assume for the things they want to keep, and more durable in its consequences for the things they took copies of. ## Making the second clock somebody's decision The fix is unglamorous and mostly organisational: - **Decide where retrieved run material is allowed to go**, and prefer one destination that has a keeping period over several that do not. - **Attach a reference rather than a file** where the tooling allows it, so the copy is not made until somebody actually needs it. - **Treat a ticket attachment as held material**, subject to whatever rules your organisation applies to everything else it holds. - **Clean up the copy when the investigation closes**, in the same motion that closes it, while whoever made the copy still remembers making it. - **Configure a period on the storage you push to**, because "we own it now" is only an improvement if somebody then exercises the ownership. ## Why this matters most on a suite like a mortgage pre-approval questionnaire A questionnaire suite does two things that make retrieved copies awkward. It fills in fields that look exactly like the real thing, so a recording of it reads as a record of a person whether or not the values were manufactured. And it fails occasionally rather than never, so there is a steady trickle of investigations, each of which produces a copy, each of which lands somewhere convenient. No single retrieval feels like a decision. The accumulation is the decision, taken by default. ## The misreading to avoid "The provider deletes it after a while, so we are fine" is the sentence to watch for. It contains two errors at once: it assumes a keeping period nobody established, and it applies that period to a copy the provider is not holding. Even when the first half is true for the supplier's own copy, it says nothing about the video attached to a ticket, and the ticket is the copy a colleague will actually open long after the fact.