Stacking pod images leaves a 4,000-row tail of singletons - do you work it or abandon the hunt?

## Cost the review before you do it A tail is a bill. Four thousand rows at twenty seconds each - open the row, glance at the namespace and the creating identity, decide - is more than twenty hours of analyst time, and twenty seconds is optimistic for anything that needs a second lookup. That is not a detail to discover halfway through; it is the first number to put on the page, because it is usually larger than the hunt's entire time budget and it forces the real question early. ## Rare by exception versus rare by construction Stack counting assumes the estate has a **convention** on the field you counted, so that departures from it stand out. Some estates do not, and on those the technique produces a table that looks like a huge finding and contains nothing. A cluster with per-developer namespaces and a self-service registry is the canonical case. The platform team built it that way on purpose: every engineer can push an image and run it in their own namespace. The consequence is that a large share of images are pulled once *by design*. The tail is not a set of outliers - it **is the population**. Two measurements separate the cases, and both are one query: - **Tail fraction.** What share of all records - not of distinct values, of records - sits in count-1 rows? A healthy stack has a fat head: a few percent of records in the tail. If seventy percent of pod creates are singletons, the field has no convention behind it. - **Window sensitivity.** Re-run the stack over seven, thirty and ninety days. A genuine long tail shrinks as a fraction, because legitimate repeats accumulate and pull values up out of the singleton rows. A by-construction tail grows roughly linearly with the window, because each new day contributes new one-off values at the same rate. A third, cheaper sanity check: pull a random sample of thirty tail rows and review them properly. If they are uniformly explicable - a developer's build, a scratch job, a new service - and nothing distinguishes them from each other, the remaining three thousand nine hundred and seventy are unlikely to be different. ## Before you quit: regroup, then stratify **Regroup** on a field the estate actually standardises even though images are free-form. Candidates in this estate: the registry host, so that anything pulled from outside the internal one becomes the rare event; the base image or base layer, if most workloads inherit from a small set; the entrypoint binary; the service account the pod runs under; the node pool it landed on. The move is not to count harder, it is to find the dimension where the organisation has a convention worth departing from. **Stratify** if you cannot regroup. Cut the tail down to a population where a hit would actually matter: pods with privileged or `hostPath` specs, workloads bound to service accounts with broad RBAC, namespaces that hold production data, images from registries outside the internal one. Four thousand rows may become eighty. You have traded coverage for a reviewable list, and the trade belongs in the write-up rather than being quietly forgotten. ## Abandoning as a result If no field set stacks, stop. Grinding a by-construction tail burns the quarter's hunting hours to reach a conclusion you could have reached in an hour, and it is worse than stopping because it *looks* like work. An abandoned hunt is a genuine deliverable if the write-up carries: the hypothesis; the record source and the audit level in force; the window; every field set and normalisation tried, with the tail fraction each produced; the conclusion that the estate has no convention on those dimensions; and the specific change that would make it stackable. The last item is what makes it useful outside the SOC. ## The other chair That change is an ask to the platform team, and they may reasonably refuse. Per-developer namespaces and a self-service registry are a deliberate developer-experience decision with real value, and 'it makes our hunting harder' is not on its own a reason to unwind it. So ask for something cheap that adds convention without removing freedom: an internal mirror or pull-through cache, so that a direct external pull becomes the rare event worth counting; a required label or annotation carrying service and owner, giving you a low-cardinality grouping key; or a small family of base images most workloads inherit. You are asking for a **stackable field**, not for their platform model. ## Failure modes to avoid - Opening row one and grinding, without ever costing the review. - Reporting the tail's size as though four thousand unknown images were themselves a finding. - Pushing the tail into the analyst queue so somebody else pays for it. - Blaming the platform team's design and stopping there. - Abandoning without recording what was tried, so the next hunter repeats every step.