What the table actually is, and what it was never meant to do
A CNFans spreadsheet is a hand-kept list of store links with working notes attached, and the useful question is never what it is but what it can be asked to prove.
The table as a hand-kept list rather than a shop
A CNFans spreadsheet starts life as a list of store links that somebody decided were worth keeping, and nearly everything else in a row was added by hand afterwards. The link came out of a marketplace. The size note, the weight remark, the packing request and the date the line was last touched did not come from anywhere except a person who was paying attention.
That origin explains most of what surprises a newcomer. No marketplace generates the list, so nothing in it changes when a listing changes. A row is a snapshot with an author rather than an interface with a server, which is why two readers can look at the same line and reach opposite conclusions about whether it is still worth anything.
The honest description is a working document doing four jobs at once: it points at an item, it records a measurement, it carries a request, and it keeps a result. A column that is doing none of those four jobs is decoration, and decoration is what most often gets mistaken for authority.
- Condition: the row can be traced to a person or a date. Pass standard: you can say when anyone last opened the link. Re-check: open it in a fresh tab and compare the item itself, not the page that loads.
- Condition: the row states a figure with a unit attached. Pass standard: millimetres, grams, days, not words like good or big. Re-check: measure one item from that row yourself and write your number beside theirs.
- Condition: the row separates what the marketplace claimed from what the warehouse observed. Pass standard: the two statements can be told apart at a glance. Re-check: ask for the item to be photographed on the scale with the slip visible.
- Condition: the row can be falsified by something you are able to do this week. Pass standard: there is one action that would prove the line wrong. Re-check: write that action down before you pay rather than after.
Rows that carry a store link and rows that carry a decision
Two kinds of row sit inside the same table and they want to be read differently. A link row exists to get you to a listing, and its only real value is that it still resolves. A decision row exists to answer a question you already have, and its value is that the answer carries a date.
A link row goes stale quietly. The listing is withdrawn, the variant disappears, the store changes hands, and the table keeps showing a tidy line because nobody edits a row they stopped using. A decision row goes stale loudly, because a date that is two years old announces itself as a date that is two years old.
The working rule is to treat a link as a search term and a decision as a hypothesis. When you paste a link you are asking what the seller has today, and that is a question no shared document can answer on your behalf.
- Link rows: check resolution first and contents second. A page that loads without a variant selector has already failed the first test.
- Decision rows: check the date first and the sample count second. A figure with no sample behind it is a rumour with punctuation.
- Mixed rows: split them in your head. A line carrying both a link and a measurement is two claims with two different expiry dates.
- Orphan rows: keep them but move them. A row nobody has opened in a year belongs in an appendix, not in the middle of a working list.
Columns that exist because a question kept being asked
Every column in a maintained table is the fossil of a question that somebody once got wrong. The weight column exists because a quote came back higher than the buyer expected. The packing column exists because a parcel arrived crushed and nobody had asked for the box to be stuffed. The size column exists because a labelled size turned out to describe a different foot.
This matters when a table looks thin to you. A short table is not automatically worse than a long one; it may belong to somebody who has not yet been surprised in that particular way. What decides the value of a column is whether it serves a decision you are about to make, not how many columns there are.
So read the headings before the rows, and name the decision each heading serves. If three headings serve no decision in front of you, you are reading somebody else bookkeeping, which can still be pleasant but is not evidence.
What a maintained row can promise, and what it cannot
A maintained row can promise three things. Somebody handled this item, they recorded what they saw in a form you can check, and the record has not been contradicted since. Those are real promises, and they are worth more than a seller-written page, because the person had nothing to gain from the note.
What no row can promise is continuity. It cannot promise that the seller still holds the item, that the warehouse will pack it the way the note describes, or that a border will treat the parcel the way the last one was treated. Those are three separate questions with three separate kinds of evidence, and a table is only one of them.
The transit figures on this desk show the shape of the problem in numbers. Thirteen lanes are published, each with an arrival count between 29 and 214 reports, and four of the thirteen sit under 45 reports, where the window is labelled indicative rather than dependable. A window with a sample behind it is a claim you can weigh. A window without one is atmosphere.
| # | Column family | What it records | How to re-check it | What it leaves open |
|---|---|---|---|---|
| 01 | Store link | The listing the row points at | Open it in a fresh tab and compare the item, not the page | Whether the seller will ship to the warehouse this week |
| 02 | Measured size | Insole length and widest point, three pairs per model | Measure your own pair at the same two points | Whether your pair came from the same production run |
| 03 | Packing note | A request that was actually sent to the warehouse | Ask for the sealed carton to be weighed on the scale | Whether the request moved the chargeable figure |
| 04 | Transit line | An arrival count with a stated sample size | Read the sample count printed beside the window | What any single future parcel will do |
| ∑ | Every column above is a claim. A claim becomes evidence only when it carries a date, a sample and a method you can repeat. |
Column names differ between tables. What matters is which of the four jobs a column is doing for the decision in front of you.
The parts of an order a table never touches
Four things happen to an order that no link table can see. A seller decides whether to dispatch and how quickly. A warehouse decides how to pack. A line decides when to build the parcel. A border decides what to assess. Each of those decisions belongs to somebody who has never read the table you are reading.
None of this is secret and none of it is in the list, because the list ends where the paste begins. Readers who expect a table to cover the whole journey end up annoyed at the table instead of at the process, and annoyance is a poor diagnostic tool.
The habit worth building is to write the stage beside each row as you wait. Most confusion in a first order is not missing information at all; it is a missing label for the stage the order is actually in.
- Seller stage: the open question is dispatch, and the evidence is a store tracking number rather than a warehouse one.
- Warehouse stage: the open question is receipt, and the evidence is a slip with a weight printed on it.
- Line stage: the open question is the build, and the evidence is a handover scan rather than a stated intention.
- Border stage: the open question is assessment, and the evidence is the notice that usually arrives after the parcel does.
The strongest case against using a table at all
The best argument against a shared link table is not that it is inaccurate. It is that a shared document teaches you to trust whoever wrote it, and that trust does not travel. A row that was dependable for one buyer, in one country, in one season, on one line, is a rumour for you until you re-check the part that decides your outcome.
The second half of the argument is maintenance. Keeping a table honest takes hours, and those hours are donated by somebody who may stop donating them. A table maintained for a year and abandoned in the second year is more dangerous than one that never existed, because the rows still look exactly the way they looked when they worked.
Both objections are correct and neither is decisive. What they argue for is a reading discipline rather than a boycott: let the table narrow the search, and let your own measurements close it. That is the whole method, and it is repeatable on any table, including the ones this desk publishes.
It is also worth stating plainly what this desk does with the question of whether a given platform is still taking orders. It does not publish a verdict. It publishes the checks by which you can reach your own, dates every figure it repeats, and leaves the conclusion where it belongs, which is with the person holding the order.
Where this desk stops: the boundary around every table claim
Three boundaries are worth stating before you rely on anything from a table, including this one. A claim is only as good as its sample, so windows carry arrival counts and thin samples are marked rather than buried. A figure is only as good as its date, so the destination bands on this desk were re-dated on one day rather than left standing from an earlier pass. A method is only as good as its repeatability, so every check here is written as something you can run again next month.
Read the sample before the window, the date before the band, and the method before the conclusion. That order will not make a bad table good, but it will stop a good table from being used for something it never claimed.
- Check the sample count before you quote a transit window to anyone.
- Check the date before you compare two figures that were collected a year apart.
- Check the repeat count before you treat one measurement as a property of a model.
- Check the method before you send a message that depends on the answer.
What this note comes down to
- 01A CNFans spreadsheet is a hand-kept working document, so each row is a snapshot with an author rather than a live interface with a seller.
- 02Separate link rows from decision rows: a link has to resolve, a decision figure has to carry a date and a sample count.
- 03A maintained row can promise that somebody looked and recorded; it cannot promise that the seller, the warehouse, the line or the border will behave as before.
- 04The desk repeats transit windows with their arrival counts, and four of thirteen lanes sit under 45 reports, where the window is marked indicative.
The data point behind this note
Own window count, KB-2026-06: the thirteen lanes the desk publishes each carry an arrival-report count, running from 29 to 214 reports; four of the thirteen sit under 45 reports and are labelled indicative rather than dependable. Counts are re-read on each pass, not averaged into a single figure.
KB-2026-11· 2026-09-30 Batch ledger · Challenge a figure
Notes in the same cluster
| # | Note | What it argues | Words |
|---|---|---|---|
| 01 | Reading a row in ninety seconds | Ninety seconds is enough to read one table row properly, provided you spend them on four fields in a fixed order instead of on the whole line at once. | 1425 |
| 02 | A first order, walked through step by step | A first order moves through six checkpoints, and each checkpoint has one question, one piece of evidence and one thing you should write down before moving on. | 1695 |
| 03 | Every status code, explained without jargon | Status words differ from desk to desk, but the seven phases behind them do not, and learning the phases is what makes any status line readable. | 1635 |
Related entries and gauges
- What is a CNFans spreadsheet, exactly?
- How is the link table laid out, column by column?
- Transit window bench
Reported arrival windows with the sample count attached.