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 intend to index the contents of a deposited record, which means we do not intend to 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.
• No preservation certification claim. There are audit frameworks for trustworthy repositories. We hold none of them. If we ever pursue one we will say which, and what the assessment found, including the parts it did not pass.

Loss during migration is real, and mostly unquantified

Moving a spreadsheet into an archival form loses live formulae, and moving a formatted document loses layout fidelity somewhere. The interesting question is which losses matter for the purpose the record is being kept for, and that is a judgement about significant properties rather than a technical setting. We expect to be arguing about this for years, and to be wrong about it in public more than once.

Structured data is worse than documents

A document at least carries its own meaning on its face. A table of forty columns of integers carries none. Preserving a database export without its schema, its code lists, its constraints and the business meaning of its fields produces something that looks preserved and is not. This is where most of the specification effort has gone.

The economics are unproven

The work described here is largely careful and manual at the moment of deposit, and largely automatic afterwards. Whether the deposit side can be made cheap enough to be worth buying, rather than being a consulting engagement with a storage bill attached, is genuinely unknown to us. If it cannot, the company does not have a product, and we would rather find that out early than construct a story around it.

We might simply be wrong about the demand

It is possible that most organisations are content to keep an unreadable copy and to deal with the consequences if a request ever arrives, because the consequences usually land on somebody who has since left. That is not a market you can talk anybody out of. It is a real risk to the premise and it belongs on this page rather than in a footnote.

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

Everything else you might reasonably want to know about a supplier that proposes to hold your records for fifteen years is currently absent. There is no operating history, no audited financial position, no insurance we are willing to describe on a marketing page, and no independent assessment of anything.

The obvious objection

A company registered this year is a strange party to trust with a fifteen year commitment, and the objection is correct. 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.