It was called preview, so it was deleted

A static capture of a customer's site had been deployed and left running. Some weeks later a cleanup went through the account and it was gone.

Nobody decided to delete it. That is the part worth starting from. It was not weighed and found unnecessary — it was swept, along with whatever else matched, by a pass whose entire view of it was the string `client-preview`. A preview is by definition a thing you keep until you do not need it any more. Nothing else about that deployment said otherwise, because nothing else about that deployment said anything at all.

What the name had to carry

The deployment was a frozen capture: seven and a half thousand files, six gigabytes, the whole of a live site rendered into static pages so that another system could be measured against it. It was load-bearing for work that had not happened yet.

None of that was visible from where the deletion happened. What was visible was a name.

I want to be precise about the failure, because *pick better names* is the obvious lesson and it is only half of one. Two kinds of reader look at infrastructure they did not create: a person with no context, and an automation that matches strings. Both get exactly one field. When that field says `preview`, neither of them has been given a reason to stop.

So the name is not a label on the thing. In a shared account it is the entire interface to the thing, for everyone who was not there when it was made.

What it cost

The capture was still recoverable, which is the only reason this is a story about naming rather than about loss. It existed on one machine, split across two folders — one holding the structure, the other the media that had been separated out of it during a disk clean-up months earlier.

Putting it back meant merging those halves and confirming the result was the same artefact rather than a similar one. That check was possible because the file count matched a number recorded on the day it was first deployed — the only reason there was anything to check against is that somebody had written the number down at the time.

Then a second pass, because the rebuild surfaced a defect that had been there the whole time: eight images had never rendered, and fifty-two more were one browser version away from the same fate. Their filenames contained commas and spaces, and a comma is what separates one candidate from another in an image's `srcset` attribute, so the browser had been tearing those URLs in half before requesting them. That had nothing to do with the deletion. It was found because the deletion forced somebody to look at the artefact again.

The half a rename does not fix

The rebuilt deployment now has a name that matches the repository that owns it. That solves the first glance and nothing else. Rename it and it is still an unexplained six gigabytes sitting in an account, and the next cleanup — human or otherwise — is making the same decision with slightly better odds.

What was actually missing is a place where the thing is described. So the second half of the repair was not a rename. It was a manifest and a short document, committed next to the code, saying what the capture is, when it was taken, what each part contains, how to restore it, and how to regenerate it from scratch. The bytes went to durable storage; the explanation went to the repository, where it is the first thing anybody encounters.

Name governs the first glance. Documentation governs the second. A thing with only the first is a thing you are hoping nobody looks at closely.

The same failure pointing the other way

There is a matching artefact from the same period, and it is the one I think about more.

An empty storage bucket, created weeks earlier, named in the same family as the deleted deployment. Never filled. Alongside it, in the repository, a manifest listing a hundred and thirty-eight videos recovered from the site — every entry pointing at the original host, because the files themselves had never been moved.

So: a name with nothing behind it, and a record pointing at somewhere we do not control. That is the deletion inverted, and the same underlying error. In one case the thing existed and nothing described it, so it was removed. In the other the description exists and the thing was never put where the description implies, so it will disappear on somebody else's schedule — and the record will go on looking healthy while pointing at a gap.

The name, the record and the thing are three separate objects. Nothing keeps them honest with each other except somebody checking.

What I would take from it

Name a thing after what owns it, not after the stage it is in. `preview`, `test`, `tmp` and `old` are not descriptions. They are permissions, granted in advance, to whoever arrives later with a cleanup script and no way of knowing better.

And then, because a name is only ever one field: write down what the thing is, where people already look, in a form that does not need anyone to remember to update it. The manifest for this archive states no totals in its prose — the counts exist only in the list itself, so there is no number for a future reader to find stale. A document that rots is a second name with the same problem.