Hosted documents
A hosted document is the easiest kind of sheet to work with and the easiest to lose. It opens in a browser tab, it keeps a version history, and it holds real text that can be copied row by row into another file. The catch sits in the word hosted: the document lives on an account, and access is decided by whoever controls that account rather than by whoever holds the address. A sheet shared as a link and a sheet shared with three named people look identical from outside, until one of them stops opening.
Google Sheets is the common case, and it is common for a reason that matters here: the text is text. A column of addresses pasted into a hosted document stays searchable, stays sortable, and can be handed to the sheet column mapper without retyping a single digit. Screenshots and photographs cannot do any of that, which is why the hosted kind is the one worth archiving first. If you can select a row and copy it, you can also check it, and checking is the whole point of keeping the file.
Ownership questions decide how long the document survives. When the person who created it stops using the account, when a workspace subscription lapses, or when an owner decides to tidy up, the address stays in old messages and stops resolving for everyone else. Two copies in two accounts is the cheapest insurance available, and it takes one afternoon at the moment the sheet still opens. Copies made afterwards are worth much less, because the rows you cannot open are the rows you can no longer copy.
The practical move for a holder is unglamorous. Open the document, use the copy route while the page still loads, and store the result somewhere you control. Keep the original address written down beside the copy, because that address is evidence of where the rows came from. In the 2026-W39 window, ninety-three records were read from pages that were still public, which is a reminder that public and permanent are different words. Anything not copied before that point leaves no trace in the record at all.
Web pages built from images
The second kind of sheet is a page assembled from images. The rows are real, the numbers are readable, and none of it is text. A reader can study the page and copy values by retyping them, one cell at a time, which is exactly as reliable as it sounds. Search finds nothing inside an image, sorting is impossible, and a single mistyped digit produces an address that looks entirely plausible. Pages like this usually exist because somebody wanted a sheet to survive being shared, and pictures survive copying in a way that shared documents sometimes do not.
Retyping is where errors enter, and they enter quietly. A transposed pair of digits, a dropped character in the middle of a long identifier, or a digit read as a letter produces a row that no longer points where the original did. Checking a typed row against the image costs one glance. Trusting fifty typed rows costs a wasted evening, and the mistake will be found by whoever tries to order from the sheet. Reading each identifier aloud while typing is slower and produces fewer of these mistakes than typing in silence.
Image pages also age differently from documents. A hosted document can be updated in place, so the page you bookmarked keeps improving or decaying in front of you. An image page is a fixed picture of one moment, and a later version usually arrives as a new picture under a new address. That is a weakness for freshness and a strength for the record, because the picture cannot change under you while you work. What you read today is what the page said on the day it was made.
When an image page is the only version left, treat it as a source to transcribe rather than a file to link. Retype the rows you actually need, check each identifier against the picture, and write the page address and the date beside the transcription. The weekly snapshots keep their own rows public for the same reason: a value with no date attached is a story, and a value with a date is a record. Nobody has to trust your memory of the page when the date sits next to the row.
Attachments inside chat channels
The third kind never becomes a page at all. It sits in a chat channel as an attachment, posted by somebody who was sharing a working sheet with a group. Channels are good at many things and bad at one thing that matters: the file is not the message. It has a name, an upload time and a size, and everything else about it is decided by the channel rather than by the sheet. Members scroll past it, react to it, and the file keeps sitting wherever the channel put it.
Attachments are easy to lose in a way documents are not. A channel can be reorganized, archived or emptied by whoever runs it, and an attachment that was only ever posted, never saved, disappears with the rest. Pinned messages help, and pinning is not the same as copying. The version you can open today is the version you still have tomorrow only if you took it out of the channel yourself. Ask who posted it and when, then write both answers beside the copy.
Provenance is the reason chat attachments keep showing up in these discussions. A file passed through a channel usually carries no statement of where its rows came from, no note about which day anything was checked, and often no author beyond a display name that changed last month. Everything downstream depends on that missing information, and it cannot be recovered afterwards by looking harder at the file. What can be recorded is what you know at the moment you copy it: the channel, the poster and the date.
The working habit is short. Save the attachment the first time you see it, keep the original file name unchanged, and add a note naming the channel and the day. Then rebuild a couple of rows from it and check whether they answer, because a file that circulated for months may describe listings that were already gone when it was posted. Copies are cheap, and the one you did not make is the one the argument is about later. A saved copy that turns out stale still beats an attachment nobody can open.
Finding the current version
Three places, one question: which copy is current. The answer is rarely the one at the top of a search result, because a sheet page indexed months ago can sit above the version its own author now uses. Working out which is which takes four checks, and none of them requires an account. Start with dates, then row counts, then the naming, then the person who posted it, in that order. The order matters because the cheapest signal is also the one most often wrong, and a date copied from another file proves nothing.
Dates come first, and they deserve care. A sheet page carries a date in its own title, a date in its last row, and often a third date in a note about the window it covers. When those three disagree, the newest one is not automatically the truth; the one that matches the rows is. A column of check dates ending on 2026-09-29 tells you more about the file than a header claiming this month. Headers are edited less often than they are copied.
Row counts come second because they are harder to fake by accident. A table with sixty-two entries and a table with thirty-one are different documents, whatever their titles say, and the smaller one is often the newer because somebody trimmed it. Compare the counts, then compare the first and last identifiers, which move slowly even when everything around them changes. Two files that share a first identifier and differ at the end are versions of one another rather than rivals. The platform ledger keeps the same discipline for platform records, and its rows carry dates.
Naming and authorship settle the remaining cases. Files carry the habits of the person who made them: some date every version, some number them, some overwrite and keep one name forever. Numbering is a gift to a reader and overwriting is a trap, because the address stays the same while the contents change underneath. When nothing resolves the question, the open questions page is where unresolved readings are listed rather than guessed at, which keeps the guess out of the table. Two candidates that cannot be separated are best kept side by side, each with its own date.