Why Write-Once Archive Copies Matter in Construction and Survey Work

The project closed two years ago. The invoices were paid, the crew moved on, and the folder full of field data has not been opened since. Then a letter arrives: a warranty claim, a boundary challenge, an insurer asking for the documentation behind a number. Suddenly the only thing that settles the question is the exact file a crew produced on a specific day, proven to be that file and not a later edit. This is the moment a firm finds out whether it actually kept a record, or only thought it did.

Most firms discover, at exactly the wrong time, that they never had an archive at all. What they had was a working folder someone hoped nobody had cleaned out. The files were reorganized when a new project manager took over, a drive was migrated, a subcontractor kept a slightly different copy, and the “original” is now whichever version happened to survive. A real archive is a different thing entirely, and building one is the whole purpose of keeping a sealed copy of every packet. It is the difference between producing the file and reconstructing a guess about the file.

A working folder is not an archive

The trouble with treating a working folder as your record is that a working folder is supposed to change. That is what it is for. People move files into cleaner structures, rename them to match a new convention, delete duplicates to save space, and overwrite an old export with a corrected one. Every one of those actions is reasonable day-to-day housekeeping, and every one of them quietly erodes the evidence you would need later. The same qualities that make working storage usable make it useless as proof.

Consider a survey crew's raw GNSS observations. The office downloads the raw file, processes it, exports a corrected version, and files the deliverable. A year later the folder holds the deliverable and maybe a processed intermediate, but the original raw observation, the one that would show what the instrument actually recorded, was tidied away in a cleanup nobody remembers. There is no bad actor in this story. There is just a storage system doing the ordinary work of storage, on files that needed to be preserved untouched.

Two jobs that should never share a copy

The fix is to stop asking one copy to do two incompatible jobs. Live working files and the permanent record have opposite requirements. Live files should be easy to move, rename, process, and delete, because that is how work gets done and how storage stays affordable. The record should be impossible to move, rename, or delete, because that is what makes it a record. Trying to satisfy both with a single folder is why so many firms end up with neither: a working area too cluttered to use and a record too mutable to trust.

Write-once storage, sometimes called WORM (write once, read many), resolves the conflict by making a second copy whose defining property is that it cannot change. The moment a packet is submitted, every file in it is copied to an archive that is sealed on write. From then on the two copies live separate lives. The working copy gets used and eventually cleaned up. The archive copy sits sealed, exempt from the retention rules that keep working storage lean, waiting for a question that may never come and holding up if it does.

Sealed at submit, before anyone can touch it

Timing is the part firms usually get wrong when they try to build an archive by hand. If you archive a file after the office has processed it, you are preserving a version that has already passed through several sets of hands. Any question about what the crew originally produced is now unanswerable, because your “original” is a downstream copy. The only copy worth calling an archive is the one taken at the earliest possible moment, before anyone works on it.

That is why the archive copy is made at submit, at the same instant the packet is verified and issued its receipt. Each file is fingerprinted with a checksum on the device, checked against that fingerprint on the server, and only then does the packet count as submitted. The sealed copy is tied to that verified fingerprint. There is no window in which a file could be quietly altered between arriving and being preserved, because preservation and arrival are the same event.

Why the checksum is what makes it proof

A sealed copy answers “do we still have the file.” The checksum answers the harder question a dispute actually turns on: “can you prove this is the file, unchanged.” A SHA-256 checksum is a short fingerprint computed from the bytes of a file. Change a single byte and the fingerprint changes completely. Because the archive keeps the checksum that was recorded at submit, anyone can recompute it against the stored file years later and see that the two still match.

That is what turns a stored file into evidence. You are not asking a judge, an adjuster, or an auditor to take your word that the file was never touched. You are handing them the file, the fingerprint recorded the day it arrived, and a check that confirms they agree. This is also why the archive pairs so naturally with the audit trail that records every event against each packet: the trail says who did what and when, and the sealed copy is the concrete thing all of that history points back to.

What a real archive copy has to do

A working folder can fail any of these and nobody notices until the day it matters. An archive copy has to satisfy all of them at once, or it is not really an archive:

• Written once, at the source. The copy is taken at submit, before the office processes anything, so it reflects what the crew actually delivered.
• Sealed against change. It cannot be renamed, overwritten, or deleted by any user or administrator. Corrections are new packets, so the original always remains.
• Exempt from retention. When working files age out to keep storage lean, the archive stays. Housekeeping and the record are deliberately different systems.
• Verifiable, not just stored. Each file keeps its checksum, so the copy can be proven identical to the original for the life of the record.
• Held where you can reach it. A record you cannot produce on demand is not much of a record. It has to be retrievable years later without a scramble.

Keeping your own copy on-premises

Some firms are not comfortable with the permanent record living only in a vendor's cloud, and that is a fair instinct for something you may need to produce a decade from now. An archive that can sync to storage you control answers it. The sealed copies can replicate nightly to an office NAS or a SharePoint library, so the company always physically holds the record itself, not just a login to someone else's service. If you ever change providers, the archive does not walk out the door with the subscription.

This matters most in trades where the raw data has a long tail of second-guessing. In land surveying, for example, preserving the raw observations and point clouds a crew collected can decide a boundary dispute years after the stakes went in the ground, and the party who can produce the untouched original tends to be the party who prevails. Construction warranty claims, geotechnical findings, and engineering deliverables all carry the same long fuse. The cost of keeping a sealed copy is trivial next to the cost of the one time you cannot produce it.

The point of a write-once copy

A write-once archive is not a premium feature bolted onto file transfer. It is the reason to track the transfer at all. Everything else, the receipt, the named owner, the trail of events, exists to describe a thing that has to actually still exist when someone asks. Separate the two jobs: let the working files be tidied, moved, and deleted as freely as the office needs, and let the record sit sealed and untouched beside them. Do that once, automatically, at submit, and the dispute that lands two years later stops being a scramble through old drives. It becomes a file you can hand over, and a fingerprint that proves it is the one.