Sheet A: what it listed
Sheet A is the ordinary case: a public sheet page that somebody built once and stopped maintaining. Thirty-one rows were collected from pages of that kind for the 2026-W39 window, and every one of the addresses in them failed at the network layer. Not slowly, not partly — the addresses themselves did not answer. What the page still held was the shape of a link, plus whatever text the person who built it had typed beside each row. What those pages also share is a date, usually months old, that nobody updated.
A row in sheet A usually carries a title, a price with no stated currency, sometimes a batch label and sometimes a note about photos, and the wrapped address that ties the row to an item. Only the address is checkable by a stranger, and it is the piece that stopped working. Everything else in the row is a memory of what a listing looked like on the day the sheet was built, which is useful context and useless proof. That asymmetry is the whole reason a dead row still has any value at all.
Follow the item we hold up throughout this piece and sheet A reads like a dead end. Product 7577045115 appears as one row among many, wrapped in an address of the form the platform used for hand-offs, and requesting that address returns nothing at all. Anyone reading only sheet A would reasonably conclude the listing had gone. Hold that conclusion for one more section before acting on it, because the next sheet contradicts it inside a minute and the contradiction is the point of this case.
Sheet A is still worth keeping, for two reasons. The identifier inside each wrapped address is the key that everything else opens with, and the batch labels tell you which rows arrived together, which is how you find relatives of an item you liked. Pages of that kind are also the largest single source of identifiers this site collects. Treat the page as a key ring rather than as a status board: it tells you what to look up, and never tells you what is currently true.
Sheet B: what it listed
Sheet B is a maintained directory, which is a different kind of document. Sixty-two source addresses were drawn from one for the same window, and all sixty-two answered when requested. The rows are simpler because they never passed through a wrapper: what you see is the address of the listing on the source marketplace, written in the form that marketplace uses, with the identifier sitting openly inside it. A row like that can be tested without any rebuild step at all.
A directory row typically pairs that address with the identifier, a title, and a directory page that describes the item. There is no hand-off layer to fail, so there is nothing between the reader and the listing. That is the structural advantage, and it is why a maintained list tends to be more useful than a bigger, older sheet. An unmaintained sheet says something about the person who built it, not about the items listed in it, and the same is true in reverse for a list somebody still walks.
The same product behaves differently here. Product 7577045115 sits in sheet B as a bare source address, and requesting it returns a normal response with the listing intact. Nothing moved, nothing was taken down, and no verification step blocked the read. Same marketplace, same listing, two documents that disagree about whether it can be reached at all. The difference lives entirely in the form of the address, not in the item and not in the seller.
What sheet B cannot tell you is whether your copy is current. A directory removes listings it can no longer reach, so an entry that is present was reachable when the maintainer last walked the file. That date is usually not printed. Freshness is a property of the document, and it travels badly between copies. Copy the row into your own table with the day you found it, and then check it yourself rather than inheriting a freshness claim you cannot see.
Sheet C: what it listed
Sheet C is the forwarded row, and it is the shape that causes the most wasted effort. These arrive as pasted text, as a screenshot of a table, or as a line inside a chat channel where someone shared a find. The identifier may survive the trip, the address usually does not: it gets shortened, wrapped again, broken across two lines, or replaced by the words look it up, and what lands in your hands is a description of a link. Nothing about the forward is dishonest; the damage happens in transit.
What is left is still worth something. A title, a rough price, a colour or size note and the identifier are enough to search the source marketplace and find the listing again, if the identifier is present and correct. Where it is missing, the row has to be identified by its title, and titles are the least stable field in the whole system: sellers rename listings, and near-identical items share almost the same words. Where two candidates look identical, price and variant are usually the only tie-breakers available.
Rebuilding cannot rescue a row that never carried an address. This site will not guess at source markers it has not observed, and in this period's sample every wrapper carried the same one, so there is no basis for inventing others. The honest move with sheet C is to treat the row as a lead rather than as a record: find the listing, confirm the identifier, and only then write the row into a table you intend to rely on. A lead promoted without that step is how wrong identifiers spread.
A practical sequence turns sheet C into something usable in a few minutes. Search the source marketplace for the title, compare the images with whatever the forward included, copy the identifier from the listing you actually opened, and paste the address exactly as the marketplace shows it. Then delete the forwarded text from your working table, or keep it in a notes column clearly marked as unverified. Five minutes of that beats an hour of guessing which of two similar items was meant.
What the three agree on
They agree on the identifier and on nothing else. Sheet A and sheet B disagree about whether the item is reachable; sheet A and sheet C disagree about what the address even looked like; sheet B and sheet C disagree about whether there is an address at all. Underneath all of that, one numeric string in all three points at the same listing, and it is the only field a stranger could use to test any of the claims on your behalf. Everything else can differ without either document being wrong.
The platform ledger's status words are deliberately narrow for this reason. A record marked resolves means the rebuilt source address answered during that period; it is not a stock notice, an authenticity check or a promise about next week. In 2026-W39 the count came out at ninety-three resolves with nothing moved, nothing gone, nothing shielded and nothing unrecorded — a quiet window that says more about the form of the addresses than about the sellers. A quiet window is not evidence that the next one will be quiet.
The rebuild step is what turns agreement into evidence. Take the wrapped address from sheet A, pull the identifier out of it, and rebuild the source address; the legacy link resolver does exactly that without an account. Then check the result and write down the day. Three sheets, one rebuild, one date, one identifier — from that point the row stands on its own and no longer depends on which document it came out of. Write the result down even when it is boring, because boring results are the ones nobody records.
The practical rule that falls out of the case is short. Store the identifier, the address as you found it, the rebuilt address, and the date you checked, in four columns that never get edited. Titles, prices, batch labels and forwarded notes can live beside them and be wrong without costing you anything. The four columns are what the three sheets share, and they are the only part worth trusting before you have looked. Anything added beyond them is welcome as long as it never overwrites them.