Fifteen years is a long time for software and no time at all for a record

An Australian company keeps its financial records for seven years under section 286 of the Corporations Act 2001 (Cth). Employee records run to seven years under the Fair Work Regulations. A health service provider in New South Wales keeps an adult patient record for seven years after the last occasion of service, and a child's record until that child turns 25. Records that touch a long tail liability, a warranty, a defect, an injury, or a piece of land, sit around for longer still, and the clock frequently starts at an event that has not happened yet.

Set that against the replacement cycle for the systems that hold the records. A practice management system, a payroll platform, a case management tool or a line of business database gets replaced every four to seven years. Over a single seven year retention period most organisations will change the system at least once, and the migration that happens at that moment is scoped around what the new system needs, not around what the obligation requires.

The gap is not a technology problem in any interesting sense. It is a sequencing problem. The cheap moment to preserve a record is while the system that made it is still running, and that is precisely the moment when preserving it has no visible benefit to anybody.

• Not a backup product. We will not compete on recovery time, we will not offer point in time restore into a live system, and we will not describe anything we build as protecting you from ransomware. Those are real products, they are sold by people who are good at them, and an archive is not one of them.
• Not disaster recovery. Nothing here keeps a service running. If the objective is that the business can operate tomorrow morning, this is the wrong shelf.
• No content search. We do not index the contents of a deposited record, which is another way of saying we do not read it. Search over content is a document management feature and it drags in exactly the access to customer material that an archive is better off not having.
• No retention advice. We will not tell an organisation how long to keep something. We will hold what it tells us to hold, until the date it tells us, and record who gave the instruction.
• No emulation. Running a 2011 application inside a preserved environment is a legitimate strategy and some national institutions do it well. It is not the one we are pursuing, and pretending otherwise would widen the market and narrow the honesty.

Loss during migration is decided, not discovered

Moving a spreadsheet into an archival form loses live formulae. Moving a formatted document loses layout fidelity somewhere. Which of those losses matters depends entirely on the purpose the record is kept for, and that is a judgement about significant properties rather than a technical setting. So it is made deliberately, at deposit, before anything is converted: what will be preserved, what will be given up, and why. It goes into the index in those words, and the depositor gets to argue with it while arguing is still cheap.

Structured data is harder than a document

A document carries its meaning on its face. Forty columns of integers carry none. A database export held without its schema, its code lists, its constraints and the business meaning of its fields is something that looks preserved and is not. This is where the specification is most detailed, and where the questions asked at deposit take the longest to answer.

The cost lands at deposit, not at rest

Nearly all of the careful work happens once, on the way in: interrogating the source system, capturing field definitions while somebody still knows them, choosing formats, settling what may be lost. Everything afterwards runs on a schedule with no judgement in it, which is why fixity checks and disposal dates cost almost nothing to maintain across a decade. That shape is the whole economic argument for doing this early. Left until the request arrives, the cost is not a larger bill; it is a question nobody can answer.

An index is written, not generated

No tool can work out that ACT_DT holds the date of the second assessment rather than the first. That fact lives in a person, and the only route from there to the index is somebody asking them while they are still there to be asked. This is the part that does not automate and is not worth pretending away. A finding aid is written by a person for a person, and the window for writing it closes when the team that understood the system disperses.

ARCVAULT AI PTY LTD is an Australian proprietary company registered in New South Wales, with ACN 696 486 987 and ABN 11 696 486 987, and it is registered for GST. Those facts are on public registers and can be checked without asking us.

Designed so that our failure is survivable

Any serious version of this service has to be designed so that the company failing is survivable for the customer. That means records held in formats the customer can read without us, an index that is meaningful without our software, a copy the customer holds directly, and an exit that is a file transfer rather than a negotiation. We would rather state that as a design constraint now than be asked about it later.

The company facts above are repeated in the register on the home page, and the routes for correspondence are set out on the contact page.