Records Vault

Records Vault is a self-hosted regulated-records preservation layer: RFC-3161 trusted timestamps that prove when a record existed, a tamper-evident read-access log, and legal and e-discovery holds, each a Falcon-1024-signed, hash-linked chain that any auditor verifies offline from a published public key. Last updated: 20 August 2026.

Included in the Verifiable Compliance Suite. One commercial licence installs this component together with the whole compliance estate, self-hosted and air-gap capable. It ships inside the suite, not as a standalone product.

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.

Bring your own keys (HSM / KMS / Vault)

Optional BYO-key custody — hold the Falcon-1024 signing and ML-KEM keys in your own HSM, AWS KMS, or HashiCorp Vault; AlgoVoi never sees a private key. Included in the bundle, and the signed output is unchanged so verification stays identical.

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 preservation features

Eight controls, each an independent Falcon-1024-signed, hash-linked chain stored beside the archive. Three launch-core controls cover the universal preservation needs; five health & legal depth features add the consent, custody, and erasure evidence regulated buyers ask for.

Launch core

Feature	What it proves	Regulatory 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 log	Exactly who retrieved which record, when, and whether it was allowed — tamper-evidently.	HIPAA §164.312(b) audit controls
Legal / e-discovery hold	These 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

Health & legal depth

Feature	What it proves	Regulatory anchor
Consent receipts	A person consented — to exactly which terms (a pinned `terms_hash`) and uses, and whether it is still valid. Revocation is recorded as a new linked entry, so both the grant and a later withdrawal are provable; consent history is never rewritten.	HIPAA authorization; GDPR lawful basis (Art 6 / Art 7)
Chain-of-custody manifests	Who held the records, unbroken, from creation to court. Each custodian handoff names the prior custodian, so the chain is a multi-decade, offline-provable record with no gap a spoliation argument can exploit.	Legal chain of custody; evidence admissibility
Key-rotation proof	Every signing key was legitimately succeeded across decades. Each rotation is dual-signed — the old key authorises the successor, the new key counter-signs — so a holder of only the original published key can walk the chain forward and trust every later key, with no third party.	Long-horizon / post-quantum verifiability
Fine-grained access control	Not just “is this a valid caller?” but “may this principal do this action on this record or matter?” Signed `(principal, resource, actions)` grants, append-only, so who could do what, when is itself tamper-evident evidence — and a denial is logged against the read-access log.	HIPAA minimum-necessary; least-privilege
Redaction & crypto-shred	Disclose less than you hold — a signed redacted derivation is emitted as a new record while the original stays ML-KEM-sealed and unchanged. And erase a field without destroying the record: each sensitive field is sealed under its own AES-256-GCM key, so dropping that key makes the field unrecoverable while a signed proof it once existed survives.	GDPR Art 17 right-to-erasure; minimum-necessary

All eight 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, rewrite a consent withdrawal — and chain verification breaks at that entry. Tampering is detectable, not deniable. And the live decisions fail closed. An access, consent, or hold check verifies the signed chain before it answers and refuses outright if any entry was altered or reordered — a tampered chain can never quietly return a benign allow or not-held. Time-bound rules fail closed the same way: an unreadable consent expiry counts as expired, an undated record stays held, and a corrupt preservation floor blocks release — never a silent bypass.

How it works

Step	What happens
Notarize	Archive the record (encrypted, signed) as usual — then timestamp the receipt: a TSA token (or air-gap record) lands in the parallel `tsa/` chain.
Retrieve	Reading a record appends a signed access event to the `access/` chain before the bytes are returned (or the denial is sealed and re-raised).
Hold	A matter hold is appended to the `holds/` chain; `is_held()` then overrides retention so held records survive disposal sweeps.
Verify	Re-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.

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.

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.

Canonical form verified across 8 independent implementations

The bytes a Records Vault signature covers are produced by RFC 8785 (JCS) canonicalization — the same discipline AlgoVoi publishes in its open conformance corpus. A real Records Vault archive receipt was canonicalized by eight independent JCS implementations — Python, Node.js, Ruby, PHP, Go, Rust, Java, and .NET — and all eight produced byte-identical canonical bytes. So the exact preimage your receipt’s signature is checked against is reproducible in your own stack and language, with no dependency on AlgoVoi. The Falcon-1024 signature itself is verified with the published Python reference; the eight-language guarantee is the canonical form — the bytes that get signed.

Portable evidence export (add-on)

Export a Records Vault evidence set as a portable, post-quantum-sealed .epi artifact — then hand it to an auditor, regulator, or counterparty, who verifies it offline with a bundled verifier: no AlgoVoi software, service, or account on their side. Signing is Falcon-1024, so the evidence stays verifiable across the decades-long retention that health and legal records demand. Available as an add-on — see .epi Evidence Export.

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 Vault	Recovery Vault
Protects	Your 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 adds	RFC-3161 timestamps · read-access log · legal holds	Shamir k-of-n threshold key split + recovery
Primary buyers	Health & legal records teams, compliance, counsel	Anyone holding archive/signing keys they can’t lose
Failure it prevents	Unprovable dates · unlogged access · spoliation / wrongful disposal	Permanent data loss · loss of signing identity
Price	Ships in the Verifiable Compliance Suite	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.
8-language canonical-form, not 8-language signature. A real receipt’s JCS canonical bytes reproduce byte-identically across eight implementations; the Falcon-1024 signature is verified with the published Python reference (post-quantum signature libraries are not yet broadly available across languages).

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.

Frequently asked questions

What provides tamper-evident, independently timestamped records for regulated data?

Records Vault. It takes the write-once, post-quantum-signed archive and adds the three things a preservation system needs beyond write-integrity: RFC-3161 trusted timestamps from an independent authority (proof of when), a signed read-access log (proof of who read it), and legal / e-discovery holds (defensible retention). Each is an offline-verifiable Falcon-1024-signed chain, self-hosted and air-gap capable.

How do you prove when a record existed without trusting your own server clock?

An RFC-3161 token from a third-party Time-Stamping Authority binds the record’s hash to that authority’s clock. The token is stored verbatim, and the vault additionally proves offline that the token’s message imprint is exactly this record’s hash. In an air-gapped deployment the same flow degrades to a signed air-gap record with no external call.

Can an auditor or opposing counsel verify the records offline?

Yes. Every deployment emits a self-contained evidence pack — the signed chains, the public key, and a ~120-line standalone verifier — that a sceptical third party checks with two public libraries (pqcrypto, rfc8785), no AlgoVoi software, no account, and no network. Tamper with any entry and verification fails at exactly that entry. It provides the tamper-evident, independently verifiable evidence those regimes rest on: HIPAA §164.312(b) read-access controls, GDPR Article 17 erasure with a surviving proof-of-existence, eIDAS-style qualified timestamps, and the MiCA Article 68(9) and DORA retention window. Certification stays with you and your counsel; the vault supplies the evidence certification rests on.

Get Records Vault

Records Vault is not sold standalone. It ships inside the Verifiable Compliance Suite. One commercial licence installs the whole compliance estate, including the Verifiable Archive, the S3 backend, the Archive Auditor, and the preservation layer above (RFC-3161 timestamping, read-access log, legal holds). One licence token installs the whole stack; runtime licensing is fail-closed per package, and you set ALGOVOI_LICENSE_KEY to run. Health and legal editions are the same code with different config presets. See the Verifiable Compliance Suite for licensing, or email us for Enterprise / OEM.

Get started

Platform

Concepts

Keystone

Substrate 2

Commercial

Open substrate

Payment protocols

Chains

Integrations

Help

Company

What it is

RFC-3161 trusted timestamps

Read-access audit log

Legal & e-discovery holds

Offline-verifiable, post-quantum

Bring your own keys (HSM / KMS / Vault)

What you get

The preservation features

Launch core

Health & legal depth

How it works

Verify it yourself

Canonical form verified across 8 independent implementations

Portable evidence export (add-on)

Records Vault vs Recovery Vault

Honest non-claims

Who it’s for

Frequently asked questions

What provides tamper-evident, independently timestamped records for regulated data?

How do you prove when a record existed without trusting your own server clock?

Can an auditor or opposing counsel verify the records offline?

See also

Get Records Vault

​What it is

RFC-3161 trusted timestamps

Read-access audit log

Legal & e-discovery holds

Offline-verifiable, post-quantum

Bring your own keys (HSM / KMS / Vault)

​What you get

​The preservation features

​Launch core

​Health & legal depth

​How it works

​Verify it yourself

​Canonical form verified across 8 independent implementations

​Portable evidence export (add-on)

​Records Vault vs Recovery Vault

​Honest non-claims

​Who it’s for

​Frequently asked questions

​What provides tamper-evident, independently timestamped records for regulated data?

​How do you prove when a record existed without trusting your own server clock?

​Can an auditor or opposing counsel verify the records offline?

​Does Records Vault help with HIPAA, GDPR, eIDAS, MiCA or DORA evidence?

​See also

​Get Records Vault

What it is

What you get

The preservation features

Launch core

Health & legal depth

How it works

Verify it yourself

Canonical form verified across 8 independent implementations

Portable evidence export (add-on)

Records Vault vs Recovery Vault

Honest non-claims

Who it’s for

Frequently asked questions

What provides tamper-evident, independently timestamped records for regulated data?

How do you prove when a record existed without trusting your own server clock?

Can an auditor or opposing counsel verify the records offline?

Does Records Vault help with HIPAA, GDPR, eIDAS, MiCA or DORA evidence?

See also

Get Records Vault