A Filename Is an Assertion

2026-09-11 · Philip Choo · AI9OS

A screenshot arrives. It is named for a date in August.

It goes into the schedule under August. The schedule goes into a chronology, the chronology informs a narrative, and the narrative is the thing anyone argues about six months later.

The transactions inside the screenshot were from June.

Nobody in that chain did anything careless. Each step read the name, because the name was right there and the file was one click further away, and by the third step there was no longer any reason to suspect the name of anything. The error entered at the only moment it was invisible, and then it became the record.

Who wrote that name

This is the question that makes the whole problem tractable, and it is almost never asked.

A filename is not produced by the document. It is produced by a person, at a particular moment, with a particular belief about what they were sending you, and often in a hurry. It is a characterisation, and characterisations are the category of thing this trade exists to test rather than to inherit.

Sometimes the author is a machine, which is not the reassurance it sounds like. A name like Screenshot_2026-08-14_09-31-22.png is the capturing device's clock, expressed in whatever timezone that device believed it was in. That is a real and useful claim, and it is a claim about when the picture was taken, not about what period the picture shows. A screenshot taken in August of a statement covering June is named correctly by the device and is still wrong for the schedule.

So a supplied file usually carries three separate assertions:

1. The name. What the sender believed, or what the capturing device's clock said.
2. The file's own timestamps. When the bytes were created, modified or last touched, on whichever machine handled them last.
3. The content. What the document says on its face.

All three can disagree, and only the third is the document.

The timestamps are a weaker witness than people assume

It is tempting to treat the file's creation date as the arbiter. That is the wrong instinct.

Whether a timestamp survives depends on how the file travelled. Copying to another volume, uploading, re-downloading, forwarding as an attachment, and sending through a messaging app that re-encodes images can each reset or strip the thing you are relying on. Some of those preserve a modified date while writing a fresh creation date, which produces the memorable absurdity of a file that appears to have been modified before it existed.

The rule that survives all of that is not a rule about which timestamp to trust. It is this: timestamps are evidence of handling, not of content. Check them rather than memorise how they behave, and if a date matters to the case, take it off the face of the document.

The opposite of the failure we keep writing about

Most of the discipline problems recorded here are about a value arriving with its provenance stripped off. A search returns nothing and you cannot tell whether it found nothing or broke, which is a nil result that is not a finding. A form comes back empty and you cannot tell a denial from fatigue, which is a blank field that is not a no.

This one runs the other way. Nothing has been stripped. Something has been added. The document asserts less than the bundle around it now claims, and the extra claim came from the label rather than from the evidence.

That makes it harder to catch, because the failure does not look like a gap. It looks like a slightly more complete file than you actually have.

It is the same shape as a bill that gets read as proving ownership when it only proves who paid it. In both, the document is genuine, the reading of it is the problem, and the reading happened somewhere upstream of anyone who would have questioned it.

A related error runs one layer up, where the claim being trusted is not a filename but an agreed sequence: a story built from several documents whose dates nobody actually checked against each other.

Open it, and compare it to its own name

The control is not clever, and that is its main virtue.

Every supplied file is opened before it is registered, and its content is compared to its name. Not skimmed for relevance, which is a different task and happens later. Compared, specifically, against the claim the name is making: the date, the party, the account, the characterisation.

That is the same distinction as cataloguing an exhibit not being the same as reading it. A catalogue built from filenames is a catalogue of what somebody said they sent.

Where name and content differ, rename to what the document shows. Then write the note, which is the part that gets skipped.

Never rename silently

The original filename is evidence, and it is evidence of something specific and occasionally important: what the sender believed at the time they sent it.

A file named for the wrong month is nearly always an honest slip, and the overwhelming majority of them are exactly that. It does not follow that the slip is uninteresting. It records a belief, held on a date, by someone who may later be asked what they understood and when. Overwriting the name for tidiness deletes that.

So the note is short and fixed in form:

Original filename  : Aug statement.png
Renamed to         : 2026-06_account-statement_screenshot.png
Reason             : content shows transactions 3 to 28 June 2026,
                     no August entries present
Checked by / date  : <initials> / 2026-09-11

Four lines. It makes the rename reversible, it preserves the original assertion, and it turns a silent correction into a visible one. If the discrepancy ever matters, the note is already there and nobody has to reconstruct it from memory.

Why the fix has to live at registration

The instinct is to handle this with care: remind people to check filenames, add it to the review step, mention it at the briefing.

That fails the way every remembered control fails. It works on the days somebody is thinking about it, and a filename's whole character is that it does not prompt anyone to think. It answers the question before the question forms.

So it belongs at intake, where the file is touched once by someone whose only job at that moment is this, and where the cost is a minute. Every later stage is working from the schedule, and by then the name has stopped being a claim and has started being a fact.

The one worth a second look

Where a file has been renamed by more than one person in the chain, you no longer have an assertion. You have a small history of what each handler thought they had, and they may not agree with each other.

That is usually nothing. Occasionally it is the most informative thing in the bundle, and it costs nothing to notice, because the chain-of-custody notes are already written.

If you are the one paying for the work

"Did someone open every file I sent, or did the schedule get built from the names?"

It is a fair question and it has a concrete answer. A file list assembled from filenames can be produced in an afternoon and looks identical to one assembled from documents.

Then the follow-up that actually tests it: "Which of my files were renamed, and what did each one originally say?"

If the answer is that none were, on a bundle of any size, that is worth a gentle second question. Real bundles from real people almost always contain at least one file whose name and contents have drifted apart, and finding none is more often a sign that nobody looked than a sign that everything matched.