Skip to main content
Records Vault is not Recovery Vault. They share a word and nothing else. Recovery Vault protects your keys (threshold key recovery — “what if I lose the key?”). Records Vault preserves your records as evidence (timestamping, access logging, legal holds — “can I prove when this existed, who read it, and freeze it for litigation?”). See the side-by-side below — most teams run both.

​
What it is

Records Vault is the regulated-records preservation layer for health and legal — one product, both verticals, sold as a single on-prem bundle. It takes the Verifiable Archive (post-quantum, tamper-evident, offline-verifiable document evidence) and adds the three things a true records-preservation system needs beyond write-integrity:
  • Independent proof of when — RFC-3161 trusted timestamps from a third-party authority.
  • Proof of who read it — a signed, tamper-evident read-access audit log.
  • Defensible preservation — legal / e-discovery holds that override routine disposal.
Like the Archive it builds on, it is not a document-management system — no folders, search, sharing, or workflow. It is the evidence layer: integrity, provenance, access accountability, and verifiable retention for records that must stand up to a regulator, an auditor, or opposing counsel years later. Every new artifact is its own append-only, Falcon-1024-signed, hash-linked chain — so all of it verifies offline, from the public key alone, exactly like the base archive.

RFC-3161 trusted timestamps

Bind each record’s hash to an independent authority’s clock, so you can prove it existed no later than that instant — without trusting your own server’s time. Air-gapped? The same flow records the message imprint in a signed chain with no external call.

Read-access audit log

Every retrieval is sealed as a signed granted / denied access event — who, which record, why — in a tamper-evident chain. Closes the “no read log” gap that write-integrity alone leaves open (HIPAA §164.312(b)).

Legal & e-discovery holds

Place a litigation hold on a matter — by subject, date range, or content type — and held records cannot be disposed of even after their retention window elapses. Release is itself blocked until the preservation window passes.

Offline-verifiable, post-quantum

Timestamps, access log, and holds are each a Falcon-1024-signed, SHA-256-linked chain over ML-KEM-1024-sealed records. One published public key verifies the archive and every evidence stream — no service, no secret.

​
What you get

  • Proof of existence-by-a-date you don’t have to vouch for. An RFC-3161 token from a third-party Time-Stamping Authority binds the record’s hash to that authority’s time. The token is stored verbatim for independent verification; the vault additionally proves, offline, that the token’s message imprint is exactly this record’s hash.
  • A read trail regulators ask for. Write-integrity proves a record wasn’t altered; it says nothing about who read it. Records Vault logs every retrieve — principal, record, granted or denied, reason — as signed evidence, exportable as JSON-lines for your SIEM / GRC (a HIPAA access report).
  • Holds that actually hold. A matter hold overrides the retention schedule: a held record is never disposable, and the hold can’t be released until its preservation floor elapses — the litigation-hold pattern, recorded as tamper-evident evidence rather than a database flag.
  • Air-gap preserved. Timestamping degrades to a signed air-gap record with no external call; the vault works fully offline. The TSA is optional, exactly as S3/Object-Lock is on the base archive.
  • One bundle, two verticals. Health and legal buy the same code, differing only in config presets (retention tables, consent terms). No fork.

​
The three preservation features

FeatureWhat it provesRegulatory anchor
Trusted timestamping (RFC-3161)This record existed no later than an independent authority’s clock — not just your server’s.eIDAS qualified timestamps; long-horizon proof-of-existence
Read-access audit logExactly who retrieved which record, when, and whether it was allowed — tamper-evidently.HIPAA §164.312(b) audit controls
Legal / e-discovery holdThese records are frozen for a matter and cannot be disposed of, with a provable set/release trail.Litigation-hold / spoliation duties; overrides GDPR Art 5(1)(e) routine erasure
All three are independent signed chains stored beside the archive. Tamper with any entry — flip a denied access to granted, forge a hold release, edit a timestamp — and chain verification breaks at that entry. Tampering is detectable, not deniable.

​
How it works

StepWhat happens
NotarizeArchive the record (encrypted, signed) as usual — then timestamp the receipt: a TSA token (or air-gap record) lands in the parallel tsa/ chain.
RetrieveReading a record appends a signed access event to the access/ chain before the bytes are returned (or the denial is sealed and re-raised).
HoldA matter hold is appended to the holds/ chain; is_held() then overrides retention so held records survive disposal sweeps.
VerifyRe-run signature + hash-link checks over the archive and all three evidence chains — offline, from the public key, with no service running.

​
Verify it yourself

Don’t take our word for it. A Records Vault deployment emits a self-contained evidence pack — the signed chains, the public key, and a standalone verifier — that a sceptical third party (your security team, an auditor, opposing counsel) can check offline, with no AlgoVoi software. The entire trust base is two public libraries.
1

Install the two public dependencies

pip install pqcrypto rfc8785
That is the whole trust base — Falcon-1024 verification and RFC 8785 (JCS) canonicalization. No AlgoVoi code takes part in verification.
2

Run the bundled verifier against the pack

python verify_evidence_pack.py
It re-derives every Falcon-1024 signature and SHA-256 hash-link itself, using only the published public key — no secret key, no running service, no network.
A clean pack verifies every chain and proves each timestamp binds to the archive receipt it stamps: 
======================================================================
AlgoVoi Records Vault — offline evidence verification
  public key kid: 8bd26d25651adb39  (Falcon-1024, 1793 bytes)
  verifier deps : pqcrypto + rfc8785 only — NO AlgoVoi code, NO secret, NO service
======================================================================
  [PASS] archive_chain.json  archive_entry       1 entries, head=sha256:e04693…
  [PASS] tsa_chain.json      vault_tsa_token     1 entries, head=sha256:1d0685…
  [PASS] access_chain.json   vault_access_event  2 entries, head=sha256:661b86…
  [PASS] holds_chain.json    vault_legal_hold    1 entries, head=sha256:39b3f8…
  [PASS] timestamp binding   every tsa.messageImprint == SHA-256(JCS) of its archive receipt
======================================================================
RESULT: ALL EVIDENCE VERIFIED OFFLINE (public key only)
======================================================================
Change a single byte — here, forging a read decision from denied to granted — and verification fails at exactly that entry: 
  [PASS] archive_chain.json  archive_entry       1 entries, head=sha256:e04693…
  [PASS] tsa_chain.json      vault_tsa_token     1 entries, head=sha256:1d0685…
  [FAIL] access_chain.json   vault_access_event  bad_signature@0
  [PASS] holds_chain.json    vault_legal_hold    1 entries, head=sha256:39b3f8…
RESULT: VERIFICATION FAILED — evidence is altered or inconsistent
The verifier is ~120 lines; its core is simply “signed, sequential, hash-linked”: 
def verify_chain(envelopes, public_key, entry_type, prev_field):
    prev = None
    for i, env in enumerate(envelopes):
        payload, sig, _ = open_envelope(env)                       # decode the signed envelope
        if payload["type"] != entry_type:        return False, f"wrong_type@{i}"
        if not falcon_verify(public_key, jcs(payload), sig): return False, f"bad_signature@{i}"
        if payload["seq"] != i:                   return False, f"seq_mismatch@{i}"
        if payload[prev_field] != prev:           return False, f"chain_break@{i}"
        prev = "sha256:" + sha256(jcs(payload)).hexdigest()        # link to the next entry
    return True, f"{len(envelopes)} entries verified"
The encrypted record is included in the pack but unreadable — its ML-KEM key is never in the pack — so you confirm when a record existed, who read it, and that it is held, without ever exposing its contents. The pack ships with every deployment and is available on request.

​
Records Vault vs Recovery Vault

Both are post-quantum, both build on the Verifiable Archive, both ship as client-deployed appliances — and they solve opposite problems. You’ll often want both.
Records VaultRecovery Vault
ProtectsYour records (the documents/evidence)Your keys (the secrets that sign/decrypt)
Core question”Can I prove when this existed, who read it, and freeze it for a matter?""What if I lose the key that decrypts everything?”
What it addsRFC-3161 timestamps · read-access log · legal holdsShamir k-of-n threshold key split + recovery
Primary buyersHealth & legal records teams, compliance, counselAnyone holding archive/signing keys they can’t lose
Failure it preventsUnprovable dates · unlogged access · spoliation / wrongful disposalPermanent data loss · loss of signing identity
PriceCommercial bundle (perpetual)Free for every Substrate 2 customer
Together: Recovery Vault keeps your archive key recoverable; Records Vault keeps the records under that key timestamped, access-logged, and legally defensible. One protects the lock, the other proves the contents.

​
Honest non-claims

We are specific about what this is and isn’t — it’s an evidence layer, not a compliance certification.
  • Not a DMS. No search, versioned editing, workflow, viewer, or folders.
  • Evidence, not certification. It supports HIPAA / GDPR / eIDAS evidence; certification remains the buyer’s and their counsel’s. No “HIPAA BAA / eIDAS-qualified” claim without a separate legal track.
  • Tamper-evident, not hard-WORM — except where you enable S3 Object-Lock (Compliance mode), in which case we say so.
  • Air-gap preserved. The TSA and S3/Object-Lock stay optional; the vault works fully offline. No managed SaaS, no key escrow beyond the existing opt-in Recovery Vault.

​
Who it’s for

  • Healthcare — long-lived immutable patient records with a provable read-access trail (HIPAA §164.312(b)), retention overrides for active matters, and air-gapped on-prem deployment.
  • Legal, IP & contracts — proof a document existed on a date (RFC-3161), litigation holds by matter, and a chain of evidence opposing counsel can verify independently.
  • Any regulated team that must preserve records and prove the preservation — to an auditor or a court — without trusting the storage vendor or the server clock.

​
Get Records Vault

Records Vault is a commercial on-prem bundle — it includes the Verifiable Archive, the S3 backend, and the Archive Auditor, plus the preservation layer above. One licence token installs the whole stack; runtime licensing is fail-closed per package. Health and legal editions are the same code with different config presets.

Buy Records Vault — $18,000 perpetual

Perpetual, self-hosted, paid in USDC. One token installs Verifiable Archive + S3 + Archive Auditor
  • the preservation layer (RFC-3161 timestamping, read-access log, legal holds). The store issues your licence key + install command; set ALGOVOI_LICENSE_KEY to run. Enterprise / OEM: email us.