Reports that expire, and why that is a feature

When it comes to generated reports, one of the less obvious design decisions is what should happen to a report after it has been read. Most reporting tools assume that every output is worth keeping forever, and they store, index, and surface each one indefinitely. However, when we look at how analysis is actually used, the majority of it is temporary, a question is asked, an answer is read, a decision is made, and the report has done its job. This means that treating every report as permanent is, for most cases, the wrong default.

##Most analysis is temporary

Consider the typical reasons a report gets generated (e.g., a pre-call account brief, a weekly campaign check, a data-quality snapshot, or a one-off investigation into an anomaly). In each of these cases the report is highly relevant for a short window and then loses almost all of its value, because the underlying situation has moved on. A campaign review from eleven weeks ago is rarely consulted, and a pre-call brief is usually irrelevant the day after the call. The fact that these reports are useful does not mean they are durable, and conflating the two leads to surfaces cluttered with stale artifacts that nobody quite trusts.

There is also a quieter cost to keeping everything. When every report persists, the act of finding the one that still matters becomes harder, and the permanence itself creates a maintenance and governance burden (e.g., access reviews, data-retention questions, and the risk of an old link exposing information that should no longer be available). In this case, storing less is not only simpler, it is arguably safer.

##Expiry as the default, persistence as a choice

Our approach is to make reports temporary by default, with an explicit expiry, and to let persistence be a deliberate choice rather than an automatic one. A report is created with a lifetime (e.g., seventy-two hours), and when that window passes the report expires unless someone has decided it is worth keeping. This way the common case (a report that matters briefly) is handled without anyone having to clean up afterwards, while the rarer case (a report that becomes a reference) is still fully supported, it simply requires a conscious decision to persist it.

##What this changes in practice

Making expiry the default changes the feel of the system in a useful way. Teams generate reports more freely, because creating one is cheap and forgetting one is automatic, which encourages asking questions that would not justify a permanent dashboard. The reports that do persist carry more meaning, because persistence now signals that someone judged the artifact important. However, we should acknowledge the limitation directly: expiry is only safe when it is predictable, which means the lifetime must be visible and a report must never disappear in a way that surprises the person relying on it.

In summary, the default lifetime of a report is a design decision that most tools make by accident, and we think the accidental default (keep everything) is wrong for the majority of cases. Treating reports as temporary by default, with persistence as an explicit choice, matches how analysis is actually used, and it keeps the surfaces people rely on focused on the artifacts that still matter.