Why Agent Shopping Spreadsheets Rot, and What Slows It Down

A shared agent spreadsheet stays accurate only as long as its fastest-decaying field stays untouched. That is the whole mechanism in one sentence. In the pool this site records, 195 entries carry 2,806 images, 20 brands and 8 categories, all extracted on 2026-09-29 from one source marketplace, and 37 of those rows already sit below the five-image line that the index layer uses. Those 37 rows are not old and were not judged as bad. They show what decay looks like when it is written down as a field value rather than argued about as a quality opinion.

The reason a list decays is that a row is not one fact. It is a bundle of claims, each of which is owned by somebody outside the sheet: the marketplace owns the item identifier, the seller owns the storefront and the photograph set, the agent owns the fee schedule, and the destination authority owns the threshold. A sheet author controls none of them. The accuracy of the row is therefore the minimum across its fields, in the same way that a chain is as strong as its weakest link, and the strongest field cannot compensate for the weakest one.

1. The link field decays when the marketplace rewrites its identifier parameters, or when a sharer re-tags the link with tracking parameters on the way through.
2. The seller field decays when a storefront is renamed, split, or replaced behind the same item identifier.
3. The image field decays when a seller re-shoots a gallery for a new batch, which removes the photographs that a buyer used as evidence.
4. The price field decays with every repricing, and the direction is not fixed: a price can fall as easily as it can rise.
5. The status field decays slowest, because it is derived from the record rather than from the marketplace, which is exactly why it is the field this site can keep.

Link half-life is the interval over which half of a copied set of pointers stops leading to the listing it names. The term is a model here and not a measurement, and the distinction matters. Measuring it would require resolving the links on a schedule and recording which ones failed, which means repeated requests to marketplaces, which this site does not make. The link health instrument refuses to answer the availability question for the same reason, and its boundary line says so on the page.

What can be read without a request is the shape of a link: which host it points at, which parameter carries the item identifier, whether extra parameters were attached by whoever shared it, and whether it is still in the form the platform itself produces. That is a string analysis, it is deterministic, and it produces the same answer for the same input every time. The walkthrough at /field-notes/link-health-checker-walkthrough/ shows the reading step by step on real link forms.

Tracking parameters deserve their own sentence because they decay differently from identifiers. An identifier belongs to the marketplace and changes when the marketplace changes. A tracking parameter belongs to whoever last shared the link, and it accumulates: a sheet copied from a video, into a chat group, and back out into a second sheet can carry three sets of parameters on the same item identifier. The parameters do not usually break the link, which is why nobody removes them, and they quietly change who gets credited for a click that started in a document nobody remembers writing.

The consequence for a reader is that the age of a row is invisible from the row itself. Two links that look identical in a spreadsheet can be a first-generation copy and a fifth-generation re-tag, and only the second one tells you that at least four people have handled the row since it was written. This is the argument for attaching a date to the row rather than to the sheet, which is what the check log at /vault/changelog/ exists to record.

The field that survives a re-share best is the marketplace item identifier, because it belongs to the platform and the platform has an interest in keeping it stable. The seller behind that identifier is a different object with a different lifetime. A storefront can be renamed without changing a single item identifier, and a factory that supplies several storefronts can appear in a pool as several unrelated sellers carrying near-identical goods at near-identical prices.

This pool records 20 brands across 195 entries, which is a wide spread for a small pool and a reminder that a brand field is a transcription rather than an identity. The value came from the listing text on the day of extraction. Nothing in the record follows what happened to the storefront after that date, and nothing in the pool claims to.

The practical effect of seller churn is that a row can be right about the item and wrong about the source at the same time. The item identifier still points at the listing, the listing still shows the same product, and the storefront that made the version a buyer liked has moved to a different identifier. A sheet has no column for that, which is why a row that has been reused across several hauls tends to drift toward whatever storefront is currently cheapest rather than whatever storefront produced the earlier batch.

A photograph set is the field that disappears most completely when it goes. Seller galleries are re-shot for new batches, and a relisted item usually arrives with a fresh gallery rather than the old one. The archived copy in a spreadsheet then becomes the only surviving record of what the listing looked like when the row was written, which is useful right up to the moment somebody compares it to the live listing and finds that neither the lighting nor the stitching matches.

The five-image threshold is worth reading as a decay instrument rather than a quality score. It is a single field comparison, it is applied to every row the same way, and it is published before the count is taken, so anyone with the same pool can reproduce the same 158 and 37. What it detects is thin photographic coverage, which correlates with a seller who did not invest in the listing, but it does not detect a gallery that has been replaced by a different batch of the same item.

Price is the field most often frozen at the moment a sheet is written and most often trusted afterwards. A row copied into a budget carries the price from the day it was copied, and the copy is usually indistinguishable from the original. This pool holds one price per entry, all observed on 2026-09-29, running from $5.17 to $451.10 with a median of $31.76.

The spread between categories is large enough to matter to a plan. The median in Headwear is $16.22 and the median in Shoes is $68.68, a factor of roughly four, so a budget built on one category will be wrong in the other direction for the next one. The Accessories row is the clearest warning in the table: a median of $26.77 sitting above a maximum of $451.10 means the category contains both the cheapest entry in the pool and the most expensive one, and a single number cannot represent it.

Drift matters more than the range because two separate lines depend on price. The first is the budget line, which is obvious. The second is the duty line, because assessment thresholds are value-based: a destination that charges tax above a threshold is testing a number that the seller can change without touching the parcel. A row whose price is six months old is therefore not only a budgeting error but a possible assessment error, and the two errors do not point in the same direction. The assumptions note at /field-notes/assumptions-about-spreadsheets/ takes this apart field by field.

Lists rot because checking costs more than leaving them. The cost is not mysterious: it is the number of rows multiplied by the time each row takes, multiplied by how often the check runs, plus the cost of any check that cannot be done from the record alone. A sheet with 195 rows checked properly every week is 195 checks a week, and that is before counting the checks that require opening a live listing, asking a warehouse for another photograph, or waiting for a parcel to arrive.

1. Structural checks read the record itself: image group size, presence of a source link, presence of a brand or category value, and the form of the link string. They are deterministic, they need no request, and they can run on a weekly cadence without an external dependency.
2. Field checks require the live source: whether a listing still exists, what it currently costs, and what its gallery currently contains. These need a request per row, so they scale with the pool and cannot be run on every row at every cadence.
3. Outcome checks sit outside the sheet entirely: whether the parcel arrived, whether the item matched, and whether a dispute was resolved. A spreadsheet cannot host these, which is why a sheet that looks complete can be silent about the only things that actually went wrong.

The check log at /vault/changelog/ is the compromise that falls out of this arithmetic. It does not claim that every row is re-verified every week. It records which rows changed status, which parameters were corrected, and which data gaps opened or closed, with the week attached. The value is not completeness but dating: after a correction is logged, a reader can tell whether a figure was checked in the current week or inherited from a week they cannot see. That is a smaller promise than a live spreadsheet makes and a much easier one to keep.

Cost also explains an asymmetry that readers notice without naming. Structural fields get maintained because they are nearly free to maintain. Price, seller and availability get maintained sporadically because each one needs a request, and requests cannot be batched without a tool that a hobby sheet does not have. The result is a document that is precise about the things that do not change and vague about the things that do, which is the opposite of what a buyer needs at the moment of purchase.

There is a serious case that decay does not matter, and it starts from how these documents are actually used. A row is typically read once, at the moment of copying it into an order, and a sheet is disposable: a haul is planned, ordered, shipped and forgotten. If the interval over which a sheet stays accurate is longer than the interval over which it is used, decay never bites, and worrying about link half-life is a hobby rather than a risk control. Under that reading, the correct amount of maintenance for a personal sheet is approximately none.

The counter-argument holds for a single-use row and fails wherever a row is reused. Reuse is not unusual, and it happens in four specific ways: a sheet is inherited by somebody who did not write it, a row is cited as evidence in a dispute, a row feeds a budget or a threshold decision months later, and a row is read by a stranger who arrived through a search engine and cannot tell when it was written. Each of those cases lengthens the usage interval past the decay interval, and each one converts a stale field from an inconvenience into a wrong answer with consequences attached.

A reading that survives both positions is this: the counter-argument is right about single-use rows and wrong about reused ones, and the only reliable way to tell which one is in front of you is whether a date is attached to the row. A dated row tells a reader how much weight it can carry. An undated row carries whatever weight the reader happens to assign it, which is usually more than it deserves.

Three fields decide whether a row can be reused: the form of the link, the size of the image group, and the date attached to the price. A reader who checks those three is not verifying the row, but is establishing what kind of claim it is. A row with a clean link form, a fourteen-image group and a current price is still not a promise that the item exists, and it is at least honest about which parts of the claim were ever checked.

• One extraction point: every figure on this page comes from 2026-09-29, and no second snapshot of the same fields exists.
• No availability testing: link reading is string analysis without requests, so nothing here reports whether a link resolves.
• No transit data: no parcel in this pool was followed, so no shipping time or delay figure is quoted.
• No seller reliability data: no order outcome is attributed to any seller, so no seller ranking is published.
• The 37 rows below the image threshold are excluded by a published rule, not judged: the rule counts images, and an item with a small gallery is not thereby a bad item.

The rules behind every count on this page are published at /method/, including the status derivation and the index threshold. Status changes and parameter corrections are recorded week by week in the check log at /vault/changelog/. The measurement boundary itself is set out in /field-notes/measuring-a-spreadsheet/, the field-by-field assumption list sits in /field-notes/assumptions-about-spreadsheets/, and the direction this record layer is moving in is argued in /field-notes/where-spreadsheets-are-heading/. A reader who wants to see the link reading applied step by step should open /field-notes/link-health-checker-walkthrough/.