Long term record retention
A record made in 2026, still openable in 2040
Arcvault is for the records that have to outlive the system that produced them. Export while the exporter still runs. Migrate the format before the last reader disappears. Keep an index a person can read without the software that wrote it.
The reader disappears long before the record does
Nothing on the shelf in a fifteen year old archive failed because the bits rotted. The bits are usually fine. What fails is everything around them. The application that wrote the file was retired in a migration nobody documented. The vendor was acquired and the export tool went with it. The licence server that the viewer phoned home to was switched off. The one colleague who knew that column ACT_DT meant the date of the second assessment rather than the first has changed jobs twice since.
By the time anyone asks for the record, the question is no longer whether a copy exists. It is whether the copy can be turned back into information. Those are different questions and only one of them is answered by having a copy.
The point at which this is cheap to fix is the point at which the system is still running and somebody still understands it. That is years before anybody needs the record, which is exactly why it does not get done.
Knowing that the file is still the file
A paper record announces its own damage. Water, mould and fading are all visible from across the room. A digital record gives you nothing. A file that has silently lost a byte in the middle looks exactly like a file that has not, right up until the moment something tries to open it.
The answer is not clever. A cryptographic digest is taken when the record is deposited, recorded next to the record rather than inside it, and recomputed on a fixed schedule for the whole holding. A mismatch is an event that gets investigated rather than a number that gets overwritten. The value of the practice is entirely in the schedule, because a check that happens when somebody remembers is a check that happens after the last good copy has already been overwritten.
This is one of the few parts of the problem where the technique has been settled for decades. What is usually missing is somebody whose job it is to run it.
An index a person can read without the original software
Archivists have a word for the document that makes a holding usable, and it is a good one. A finding aid says what is in the collection, where each part came from, how it is arranged, and what the terms in it mean. It is written for somebody who was not there.
The digital equivalent is the piece most often skipped, because at the moment of export it feels redundant. Everybody involved knows what the system was. Fifteen years later nobody does, and a directory of forty thousand well preserved files with machine generated names is a holding that technically survived and practically did not.
So the index is a first class object here. Plain text, held beside the records rather than in a database that would then need preserving too, carrying the origin system, the export date, the meaning of every field, the units, the code lists, and the name of the role that could answer a question about it. It has to be readable with nothing but a text editor, because a text editor is the only tool we can be confident still exists.
The distinction that matters
01This is not a backup, and it is not disaster recovery
The three get filed together because they all involve a second copy. They fail in different ways, at different times, and a plan that confuses them leaves a gap nobody notices for a decade.
Backup answers the question "the system is broken, how do we get it back". Disaster recovery answers "the site is gone, how do we run somewhere else". Both assume there is something to restore into. Both are measured in hours, and both are tested by restoring.
An archive answers a different question. "The system does not exist any more, the vendor does not exist any more, and somebody has asked for a record from 2026." There is nothing to restore into. The record has to stand up on its own, described well enough that a stranger can use it.
| Practice | Question it answers | Assumes | How it fails | Horizon |
|---|---|---|---|---|
| Backup | How do we undo a loss inside a running system | The same application, the same schema, the same licences | Loudly. The restore fails and somebody finds out that day | Days to months |
| Disaster recovery | How do we keep operating when a site or provider is lost | The application can be stood up somewhere else | Loudly. The failover is exercised and does not come up | Hours to days |
| Archive | How does a record stay readable once its system is gone | Nothing about the original system | Silently, years later, when nobody can open the file or say what it meant | Seven to twenty years |
A flawless backup of a proprietary database dump, verified every night for fifteen years, is a perfect copy of something nobody can read. Every control worked. The record is still lost.
None of this makes backup less important. It makes it a different job. An organisation that has bought a good backup product and believes it has therefore addressed long term retention has bought an answer to a question it was not asking.
The shape of the work
02Export, migration, index
Three activities, in that order, each of them dull, and each of them cheap while the source system is still alive.
The work divides into three pieces rather than into a product surface, because the order they happen in is what decides whether any of it is useful.
Export, while the exporter still runs
Getting the record out of the application, into a format whose specification is published and maintained by somebody other than the vendor, with the field definitions captured at the same moment. The window for this closes when the system is switched off, and it closes quietly. An organisation that plans a decommission around infrastructure cost and not around the export loses the definitions first and the data second.
Migration, before the last reader disappears
A format is a promise that somebody keeps maintaining a reader. When that stops being true the record has to move, and the move has to be recorded. Which transformation ran, on what date, against what version, what was preserved, and what was accepted as lost. The previous version stays. A migration that overwrites its input is a migration you cannot check.
Index, written for a stranger
The finding aid. Provenance, arrangement, field meanings, code lists, units, the retention rule that applies and the date on which it expires. Written on the assumption that the reader has no context, no access to the original system, and no colleague to ask.
| Property | What it requires | How it is checked |
|---|---|---|
| Self contained | The record can be opened without the application that created it, without a licence server and without a network call | Open it on a machine that has never seen the source system |
| Specified format | The format has a published specification and at least two independent readers that are not controlled by the same organisation | Name both readers, in the index, at deposit |
| Fixity | A digest recorded at deposit, held beside the record, recomputed on a schedule for the entire holding | Compare the recomputed digest against the deposit register |
| Described | A plain text index giving origin, export date, arrangement, field meanings, units and code lists | Hand the index to somebody with no context and ask what a named field means |
| Traceable | Every transformation since deposit is recorded, and the pre transformation version is retained | Rebuild the chain from deposit to current state without a gap |
The deposit package
03What a stranger opens in 2040
A deposit is one directory, and a person who has never heard of the source system, the vendor or this company can work out what is in it from the directory alone.
The package is specified rather than left to whatever the source application happens to emit, because the shape of the directory is the part that has to outlive every piece of software involved, this company's included. Five files, each of which earns its place by answering a question a reader in 2040 will actually have.
| Part | What it holds | The question it answers |
|---|---|---|
| The record | The material in a format whose specification is published and maintained by somebody other than the vendor that produced it, with two independent readers named at deposit | Can this be opened at all, on a machine that never saw the source system |
| The index | Plain text. Origin system, export date, arrangement, every field and its meaning, units, code lists, and the role that could answer a question about it | What am I looking at, and what does column ACT_DT mean |
| The manifest | A cryptographic digest per file, taken at deposit, held beside the record rather than inside it | Is this still byte for byte what was deposited |
| The migration log | Every transformation since deposit: which one ran, on what date, against what version, what was preserved and what was accepted as lost | What has been done to this since it arrived, and by whom |
| The sentence | The retention rule that applies, the event the clock started from, the expiry date and the disposal action fixed by the depositor | Am I allowed to still have this, and when does it go |
Every one of those is a text file except the record itself. That is a deliberate constraint rather than an aesthetic one: a text editor is the only tool anybody can be confident still exists in fourteen years, so nothing that explains the record is allowed to depend on anything else.
The shape of it follows work that is not ours: the reference model for an open archival information system, the format registries national libraries maintain, and the published preservation policies of institutions that have been at this for thirty years. None of that is ours and we do not present it as ours.
The register
04Everything here that can be checked against a public register
Company facts belong on a page where they can be verified, not in a badge.
Write to ops@arcvaultai.co.im and a person reads it. There is no form in the way, which means an email leaves you holding your own copy of what you sent and collects nothing beyond what you chose to type. A reply with something in it comes back inside five business days, and the contact page carries the subject line and the timing for every other kind of message.