ATTENTION, PEOPLE WITH A FILE CALLED FINAL_FINAL_USE_THIS_ONE.xlsx!
PEOPLE WHOSE PHOTO LIBRARY EXISTS ON A LAPTOP THAT SOUNDS LIKE A TINY CEMENT MIXER! PEOPLE WHO HAVE CREATED A FOLDER CALLED OLD AND THEN PUT THE CURRENT THING IN IT!
Are you tired of not discovering, at the worst possible moment, that you have four versions and no idea which one anybody used?
Have you ever found the file instantly — and still had no way to tell whether it was the file, the right file, a complete file, or a file capable of surviving the laptop’s dramatic exit from the chat?
Then congratulations.
For the next several minutes you are eligible to receive the Five Number One Rules of Data You Can Find and Trust, a complete system containing not one, not two, but FIVE NUMBER ONE RULES.
It includes storage! Naming! Checking! Recovery! A tiny paper trail!
It does not include a cloud-shaped talisman that makes all future mistakes illegal.
“Wait,” you’re shouting at the screen, “they can’t all be Number One!”
That’s exactly what Big Numbering wants: one heroic backup drive, wearing a cape, asked to solve everything from a typo to a flood to the question of why this month’s total changed.
Data failures are specialists.
Three copies won’t identify the right version.
A dated filename won’t prove a join didn’t multiply your rows.
Valid values won’t prove a backup restores.
And a successful restore won’t tell you which raw file, which formula, and which cleanup produced the chart.
Five different accusations. Five different answers.
So here they are.
Five rules.
Five Number Ones.
No substitutions. No “the cloud has it.” No declaring victory because a progress bar reached one hundred percent and looked emotionally persuasive.
RULE #1: KEEP COPIES THAT FAIL DIFFERENTLY
Introducing THREE-OF-A-KIND TURBO™ — the astonishing storage plan in which copy one is a laptop, copy two is a USB drive sitting beside the laptop, and copy three is a very detailed memory of where the laptop was.
Start with 3-2-1. Three copies, two media, one elsewhere.
The first is the working copy — the live document, database, photo library, or hand-tuned configuration you actually use. It isn’t a backup. It’s the thing requiring one.
The second lives locally on a different medium. External drive, NAS, second internal disk.
And “different” is doing real work in that sentence. Two SSDs from the same batch are one medium for this purpose. They share a failure mechanism, and the fact that their cases are different colours will not help you.
The third goes offsite. Cloud storage, a drive rotated to another building, a safe-deposit box. This is the copy that survives the fire, the flood, or the theft that takes everything on the premises.
Automate it, then glance at the last-successful-run timestamp once a month. Manual backup has an unfortunate tendency to become an annual museum exhibit titled I Meant To.
Where ransomware is a realistic threat, extend to 3-2-1-1-0: add an immutable copy that your daily-work credentials cannot modify or delete. Object lock, versioning, or simply a drive physically disconnected after each job.
That extra copy isn’t a bigger number pretending to solve everything. It answers one specific failure — the live account deleting the backup along with the live files, cheerfully, on your behalf.
A copy is protection only when it does not share the loss it is meant to survive.
Three folders on one sinking ship are still one voyage.
RULE #1: MAKE THE RIGHT VERSION FINDABLE
From the makers of SAVE-AS-AND-PRAY™ comes FINAL_FINAL_USE_THIS_ONE: DIRECTOR’S CUT — all the warmth of a familiar filename, with none of the uncomfortable question what changed?
Preserve the raw input exactly as received. Before cleaning. Before editing. Kept separate from anything you work on.
Every edit happens on a copy.
The common failure here isn’t advanced sabotage. It’s opening the original, “just tidying it up,” hitting save, and quietly erasing the before picture with the after picture. It takes four seconds and it is completely irreversible.
Then name and date every output as it appears. Use ISO 8601 in the filename so chronological order is visible, rather than inferred from an archaeological dig through modified timestamps.
Don’t overwrite last month’s result in place. A dated copy costs storage. An overwritten copy costs you the ability to answer what changed between the old number and the new one — which is, reliably, the only question anybody asks.
Keep a changelog. One text file, dated entries, newest first, saying what changed, why, and who did it.
Record a transformation as a step, not an outcome. “Removed 12 duplicate rows by customer ID, 2026-07-14” can be examined and undone. “Tidied the data” is a fog machine with a keyboard.
Git is excellent when a team can use it. It is not a membership card for responsible work. For a non-engineer, raw inputs, dated outputs, recorded steps and a changelog are the manual form of exactly the same discipline — protected sources, commits, tagged releases, a commit log.
The principle survives the change of software.
A version is not the latest file. It is the file whose identity and changes can be stated.
If two files are both called final, neither one is final. They’re contestants.
RULE #1: CHECK THE DATA BEFORE IT EARNS A CONCLUSION
BEHOLD ANALYZE-NOW, REGRET-LATER 4000™: feed it a spreadsheet, press the chart button, and receive a graph so polished it could conceal a missing county, a doubled customer list, or a birth year from the future.
Validation asks whether the data is what it claims to be. Analysis asks what it means. Do those in that order, or the second one will confidently describe the first one’s mistakes.
Start with range and plausibility. A percentage of 340. A birth year of 2098. A negative value in a counting field. One conditional rule — or honestly, a sort and a skim — catches that whole category without any statistical training.
Then, before trusting an import, merge or join, compare the resulting row count against what the inputs should have produced. And confirm the field that’s supposed to be a unique identifier actually contains no duplicates.
That pair catches the ordinary silent catastrophe: an operation that drops rows or multiplies them without producing an error. Nothing turns red. Nothing complains. A neat-looking output is not a receipt.
For files from a vendor, contractor, or download, compare a cryptographic hash when both ends can compute one. A matching SHA-256 confirms the file arrived exactly as sent.
Note carefully what that does and doesn’t buy you. It confirms transit integrity. It says nothing whatsoever about whether the spreadsheet contains the right values. A fingerprint proves the envelope survived the mail. It can’t prove the letter was sensible.
Finally, spot-check a genuinely random handful of rows against the invoice, the intake form, or the upstream system.
Automated rules catch impossible values. A source check catches plausible-looking wrong ones. Those are separate checks because they’re separate errors, and the second kind is the one that reaches a board meeting.
Data that passes no check has not become trustworthy merely by becoming colourful.
The chart is not an alibi for the rows.
RULE #1: TEST A RESTORE, NOT A GREEN CHECKMARK
NOW AVAILABLE: BACKUP-SUCCESS-O-VISION™ — a soothing green badge that answers the question “did the software finish copying?” and then sprints away from the question anybody actually has.
A backup job’s success log says copying finished without an error.
It does not say the copy can be turned back into working data.
Those have felt like the same statement to a great many people, exactly once each.
The only way to know is a test restore, performed before an emergency makes the first attempt matter.
Pick a real file. Not a one-line text file that could survive a stiff breeze. Restore a multi-gigabyte database or a large photo library — something big enough to expose a size limit, a format incompatibility, or a partial transfer.
Restore it somewhere separate. Open it. Look at the last-edited content. For a spreadsheet, check the row count against what you expect.
“Restore complete” is where verification begins.
Quarterly is a reasonable convention for a personal or small-business setup. Anything a business genuinely runs on needs testing more often than that. The schedule follows the cost of finding out too late — it isn’t a universal guarantee.
And keep a dated log of restore attempts separate from the automated job’s own log. Two records, because the job only ever reports on itself, and it grades its own homework.
There’s a transferable habit from code review here, though the numbers don’t transfer: reviews lose effectiveness past roughly 500 lines an hour and after about 60 continuous minutes. Smaller reviewable units, checked often, beat one enormous heroic session.
Don’t save every unknown until the emergency turns it into an all-night review.
A backup is a claim. A successful restore is the evidence.
Green is a colour, not a recovery plan.
RULE #1: MAKE THE PATH TO THE RESULT REVIEWABLE
AND NOW, IT-MADE-SENSE-AT-THE-TIME PRO MAX™ — the analysis process in which every decisive click happened at 4:47 on a Tuesday afternoon and is now stored exclusively inside one person’s recollection.
For each result, keep three things: the untouched raw input, the recorded transformation steps (or better, a saved script or formula sequence), and the changelog.
A one-line note beats memory. A rerunnable script beats a note, because it can be run again by somebody who wasn’t there.
Then run the audit that actually tests this.
Hand those materials — raw input, steps, changelog — to somebody uninvolved. Ask them to regenerate the output.
This is much stricter than explaining the result in a meeting, and that’s the point. When you narrate your own work, your memory silently fills every gap. An outsider has no such equipment, which is precisely what makes them useful.
The audit either reproduces the number, or it points straight at the broken habit: an unrecorded manual transformation, an original edited in place, an output with no stated parent.
Formal research shows the general mechanism at scale. One 2011 review found 65% of medical studies inconsistent on retest and only 6% completely reproducible. A 2018 survey found only 14.4% of public-health researchers shared the data or code behind published statistics.
Those are research settings, not office spreadsheets. But the danger is identical and entirely familiar: a crucial step that lives only inside somebody’s head.
Keep the reviewable unit small. Continuous integration works because the batch is small and the check returns before the next mystery accumulates — the automated suite is meant to run in about ten minutes, not overnight.
Nobody is asking you to turn a workbook into a deployment pipeline. Just to make the feedback arrive while you still remember what you did.
A result is reproducible when its inputs, transformations, and outputs can meet someone who was not there.
If the result needs a séance, it needs a record.
BUT WAIT, THERE’S MORE!
“What about a photo library?”
Same rules. Local copy, offsite copy, identity for the edits that matter, a restore that actually gets opened, and enough record of the cataloguing to repeat it.
“What about payroll, health records, or anything with a retention rule?”
Same rules — but retention periods can be regulated and jurisdiction-specific. The longest tier follows the applicable requirement, not a convenient empty drive.
“What about a tiny team with no Git and no data engineer?”
Same rules. Preserve raw input, edit copies, record transformations, date outputs, and let one other person try the reproduction path.
“What about an excellent cloud service?”
Same rules. It can supply the offsite copy and versioning. It cannot identify the right version, validate your values, prove a restore, or narrate how a result appeared.
The details change.
The architecture doesn’t.
THE FIVE, WITHOUT THE GREEN CHECKMARK
Keep three copies across two media with one elsewhere — and an immutable fourth where ransomware is realistic.
Preserve raw input, date every output, and record each change in a changelog.
Check plausibility, row counts, identifier uniqueness, and a random sample against the source — before analysis, not after.
Restore a real file to a separate location, open it, and log the outcome. The job’s own success message is not the test.
Keep inputs, transformations and outputs reviewable enough that somebody else can regenerate the result.
DO THIS TONIGHT, BEFORE FINAL_FINAL GETS A SEQUEL
Find one working folder and identify what genuinely cannot be recovered from anywhere else. That list is shorter than you fear and more important than you think.
Confirm the working copy. Locate or make the local copy on a different medium. Locate or make the offsite one. If it runs automatically, go look at the last-successful-run timestamp — actually look, don’t assume.
Then pick one active spreadsheet. Move the received original into a raw-input folder. Make your working copy from it. Give the next output an ISO date in its name.
Start the changelog tonight, with one line. One line is infinitely more than none.
Before the next analysis, compare row counts, check identifier uniqueness, and eyeball the fields for values that couldn’t possibly be true.
Then do the thing that converts comfort into evidence: restore a real backup somewhere separate, open it, and look inside. Write down the date and what you found.
Finally, hand the raw input, the steps and the changelog to somebody else and ask if they can recreate the result.
That isn’t bureaucracy. That’s the moment your data becomes something another human being can find, inspect and trust.
For the low, low price of doing the boring parts while nothing is on fire, the complete Five Number One system is yours.
No subscription. No smoke machine. No sacred folder called misc.
And if you act now, we’ll include the only premium feature that has ever mattered:
evidence that the file can come back.
Operators are no longer standing by.
The operator is whoever needs this file in two years.