Platform checks · skeleton ⑱

The Kakobuy spreadsheet in Google Sheets: copying it, and when a copy goes stale

Year on year the copies got tidier and the refresh problem stayed exactly where it was.

Written Last substantive change 1228 wordsTarget: kakobuy spreadsheet google sheets

Last year against now: tidier files, same blind spot

The copies circulating a year ago were rougher and easier to distrust. Colour coding was inconsistent, column names changed halfway down, and two people often maintained two files that disagreed. Nobody mistook those files for live data, which was their accidental safety feature.

The current generation is much better made. Consistent columns, frozen header rows, filters, notes attached to cells. A well-made copy looks like a database, and looking like a database is exactly what removes the caution the rough version used to trigger. The polish went up and the refresh interval stayed the same, which is the whole story of this version change.

  • Layout and column naming: considerably more consistent than a year ago.
  • Filters and pivots: now common, which makes sorting feel like analysis.
  • Update dates: still absent from most rows in most copies.
  • Ownership labels: still rare, and still the first thing to look for.

So the version difference is real but narrow. Copies became easier to read, not easier to date, and freshness is what decides whether a row is usable. If you read only one part of this archive, read the check in [the platform checks topic](/table/legitimacy/), which is unchanged by any of the cosmetic work.

The change checklist: what moved and what did not

The checklist below is the version comparison in its shortest form. Each line is a thing you can check in a copy you already have open, and each one has a verdict attached rather than a description.

Version comparison between a rough older copy and a polished current one
ElementA year agoNowVerdict
ColumnsInconsistent namesStable names, frozen headersImproved
Row countOften under 100Commonly 150 to 400Improved
Update datesOccasional notesStill mostly missingUnchanged
Owner namedSometimes in a cellStill rareUnchanged
Sharing modelLink in a postLink plus a copy buttonWorse, easier to fork

The last line is the one to notice. Making a copy is now a single click, so there are more copies in circulation than there were, and each copy freezes at its own moment. The number of copies went up while the number of maintained sources stayed roughly the same.

Why copies fork so easily in a browser-based spreadsheet

A copy separates from its source the moment it is made, and nothing in a spreadsheet tells you that afterwards. There is no watermark on a row saying it was pasted three weeks ago. A copy of a copy keeps the same visual quality, so the third generation looks exactly as convincing as the first.

Three habits follow from that. Check the oldest update date in the file, not the newest, because the newest one may be the only row anybody touched. Check the file save date, which is often much more recent than the content inside it. Then check the row count against the source, because copies grow and never shrink.

  • Oldest update date inside the file: the real age of the content.
  • File save date: when somebody last opened and re-saved it.
  • Row count compared with the source: whether the copy was trimmed.
  • Column names compared with the source: whether the copy was merged with another file.
Formulas do not help here

A function that fetches a value from a web page cannot fetch a login-gated order record, and a pasted value never updates itself. Freshness in a copy depends on a person re-checking rows, not on a formula.

Why the blind spot survives every redesign

Adding an update date column costs one click per row and nobody enjoys it. Filling in status words is the visible, satisfying part of maintaining a sheet, and dating each row is the invisible part, so the invisible part loses. This is not laziness; it is the ordinary behaviour of unpaid maintenance.

The consequence is measurable. In a copy where only 12 of 180 rows carry an update date, the undated share is 168 divided by 180, which is about 93 percent. On a file like that, freshness cannot be scored row by row at all, and any claim about how current it is becomes a claim about the file as a whole rather than about what you are reading.

There is also an incentive problem. Undated rows cannot be wrong, because there is nothing to compare them against. The moment rows carry dates, a maintainer can be seen to be behind, and being seen to be behind is exactly what makes people stop dating rows.

None of that is an argument against sharing a list. It is an argument for deciding in advance what a list can be used for, which is the same test that applies to [choosing an agent](/steps/pick-agent/): read what the record supports, and re-check anything that has a deadline attached.

What these changes actually mean for a buyer reading a copy today

Practical effects come in three sizes. The smallest is cosmetic: filters and tidy columns save you a few minutes of scrolling. The middle one is behavioural: a better-looking file gets trusted faster, so more people act on it without re-checking. The largest one concerns duplication: more copies means more chance that the file you found came from a file that was already old.

  1. Treat a polished copy as a lead, not as a record.
  2. Before using any row, ask when that row was last true.
  3. Before trusting the file, ask when its oldest row was last true.
  4. Before acting on either, open the live record for the single item you care about.

If you keep your own version, the repair is small and worth doing once. Add three columns: the item reference, the date you copied the row, and the stage it was in. Every row you cannot fill in is a row you should not act on later, and that rule alone removes most of the risk of reading somebody else file.

Copying it properly: a five-minute routine that keeps a copy usable

Copy the content, then stamp the copy in the same session. A copy that gets stamped three days later is a copy with an unknown age, which is the problem you were trying to avoid.

  • Add a first column called copied on, and fill it with one date for the whole paste.
  • Delete every row that has no item reference, because you cannot re-check it.
  • Write the source location at the top: which file, which sheet, which owner if known.
  • Re-paste rather than editing, so the column structure stays comparable between versions.

Two habits keep the file honest over months. Re-paste from the source on a fixed day, and delete the rows for items that have already left the warehouse. A copy is a working list, not an archive, and a short accurate list beats a long one whose top half describes last month. If the source itself has not changed since your last paste, note that too: an unchanged source says something about the maintenance behind it, and it usually means the updates stopped rather than paused.

What stays constant no matter how the spreadsheet is built

Four things do not depend on the format at all. The live order record is the only place where eligibility is decided. The destination country is the only place where duty and tax are set. Intake measurements are the only weight figures that come from a scale rather than from a listing. And any written exchange with dates attached is the only material a later claim can be built on.

A spreadsheet copy can help you organise all four, and it cannot substitute for any of them. That is a comfortable place to end up, because it means the file you found is useful at exactly the job it can do.

Keep the four together in one place: the record, the destination rules, the measured figures, and the dated messages. Questions that do not resolve into those four categories are usually the ones worth filing under [open doubts](/doubts/) and revisiting next month, when the answers may have moved again.

Original data in this note

Worked example: in a copy where only 12 of 180 rows carry an update date, the undated share is 168 divided by 180, which is about 93 percent, so date coverage has to be measured before freshness can be scored at all. (stated basis: Worked example)

Open the live Kabosheet list

This note explains the mechanics; the list is where the items are.