What to write down at delivery
The facts that matter later are the ones that were easy to note at the time: which tool and version produced the asset, which settings were in force, what the delivered file carried, where it went, and the date. None can be recovered reliably afterwards. As of 2026-09-12.
| Field | Why it disappears |
|---|---|
| Date | Relative wording decays immediately |
| Delivered file contents | Platforms transcode on the way through |
| Settings in force | Defaults change without notice |
| Tool and version | Interfaces stop showing what they showed |
| Where it was published | Accounts and links change hands |
Inclusion rule. Fields recoverable only at the moment of delivery. Order. Alphabetical by field.
1Why reconstruction fails
Tools update, default settings change, accounts change hands, and interfaces stop showing what they showed a year ago. A question that arrives late is nearly always a question about a specific asset at a specific moment, and the moment is the part that has disappeared.
The cost asymmetry is extreme. Noting five fields at delivery takes under a minute; reconstructing them afterwards can be impossible, and a confident reconstruction that turns out to be wrong is worse than an honest gap.
2The five fields
Tool and version. Settings that affect what the output carries. What the delivered file actually carried when inspected. Where it was published or sent. The date, in a form that does not depend on which timezone the reader is in.
Five fields fit in a spreadsheet row, and a spreadsheet row gets filled in. Anything longer becomes a form nobody completes, which is the same as no record while looking like diligence.
3Record the version, not just the tool
Named models and named versions are what make a record checkable against anything else later. A note that says a service generated it answers almost nothing; a note naming the model and version can be placed against that vendor's own published material.
Where a service does not disclose the version it ran, the record should say that rather than leaving the field blank. An explicit not disclosed is a fact about the route, and a blank is just a missing entry.
4Record the delivered file, not the export
What matters is the artefact that reached the audience, after any platform transcode or downstream edit. If those are different files, both belong in the record, because a question about what the audience saw is a question about the second one.
This is also where most surprises live. A route that strips attached metadata does so consistently, and finding that out at record time is a great deal cheaper than finding out when asked.
5One owner, one place
A record split across a producer's notes, an editor's folder and a platform dashboard is three partial records and no complete one. Name the person who owns it and the single place it lives before the first delivery rather than after the first question.
Distributed ownership feels more thorough and performs worse. The failure is silent until someone needs an answer quickly, which is exactly when there is no time to assemble one.
6Dates that survive
Write absolute dates. Relative wording such as last quarter or before the change decays immediately and cannot be repaired from the outside. Where something was checked rather than done, record the check date separately from the delivery date.
Every entry on this site carries a date for the same reason, and it is the field that most often makes an old row still usable. A fact without a date is a claim; a fact with one is a claim that can be rechecked.
7Keep corrections visible
When a record turns out to be wrong, amend it and keep what it said before, with the date of the amendment. A record that is quietly edited cannot be relied on, because a reader has no way to know whether today's version is the one that was acted on.
The same discipline applies here: where a vendor changes wording, the row changes and the date moves, and the change is visible rather than folded in.
8What this routine does not decide
Keeping a good record does not determine what anyone is required to do, and this page makes no claim about that. Requirements depend on role, place and the material itself, and the text of the instruments is recorded elsewhere on this site with its sources.
What a record does is make the factual question answerable at all. Whatever the requirement turns out to be, the answer starts with knowing what was produced, by what, carrying what, and when.
9Where the generator wording is filed
None of the three mechanisms belongs to any one vendor. What each generator publishes about its own outputs is recorded in the generator table, quoted from the vendor's page with the date it was read.
- Sourcing — how entries here are dated and corrected
- Duties by role — how the text separates the parties
Background on mechanism and practice. Nothing here is attributed to a product, and nothing here is a reading of any instrument. The sourced material is on the generator table. Related: Reading a plan table, Reading a system card.