Long term record retention
A record made in 2026, still openable in 2040
Arcvault is being built 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 company is being built around three pieces of work rather than around 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 |
Status
03What exists today, stated plainly
The company was registered in 2026. Nothing has been released, nobody is using anything, and no record belonging to anyone else has ever been held.
A status section belongs near the top of a website rather than in small type at the bottom of it. This one is deliberately specific, because vagueness at this stage is a choice and it is usually a dishonest one.
What is actually being done
- A written specification for the deposit package, the index format and the migration record. It is being written before any code, because the format is the part that has to outlive the code.
- Format experiments on our own material. Round tripping documents, spreadsheets and structured exports through candidate archival formats and measuring what is lost. Cell formulae, merged cells, embedded objects, character encodings and time zone handling are where the losses show up first.
- Reading other people's work. The reference model for an open archival information system, the format registries maintained by national libraries, and the published preservation policies of institutions that have been doing this for thirty years. None of it is ours and we will 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.
ARCVAULT AI PTY LTD does not hold ISO/IEC 27001 certification, a SOC 2 Type I or Type II report, an IRAP assessment, Essential Eight attestation, or any digital preservation accreditation of any kind, and will not represent otherwise until one is genuinely held. No independent party has audited anything described on this website.
Write to [email protected]. It is the only route into the company and there is no form on this site, because a form either posts nowhere or quietly collects an address that nobody asked you for. Ordinary correspondence gets a substantive reply within 5 business days.