> ## Documentation Index > Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt > Use this file to discover all available pages before exploring further. # Records Vault > Regulated records preservation for health and legal: RFC 3161 trusted timestamping, a tamper evident read access log, and legal and e-discovery holds. 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](/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](/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](#records-vault-vs-recovery-vault) 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](/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. 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. 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)). 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. 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. Optional [BYO-key custody](/bring-your-own-keys) — 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. ```bash theme={null} 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. ```bash theme={null} 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: ```text theme={null} ====================================================================== 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: ```text theme={null} [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": ```python theme={null} 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](/conformance-vectors). 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](/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](/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](/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. ### Does Records Vault help with HIPAA, GDPR, eIDAS, MiCA or DORA evidence? 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](/mica-dora-evidence) retention window. Certification stays with you and your counsel; the vault supplies the evidence certification rests on. ## See also * [Verifiable Compliance Suite](/verifiable-compliance-suite) -- the estate this component ships in. * [Verifiable Audit Log](/audit-log) -- the tamper-evident event chain Records Vault preserves alongside documents. * [Regulated-records self-hosting guide](/regulated-records-self-hosting-guide) -- what a compliant self-hosted preservation estate requires. * [MiCA and DORA evidence](/mica-dora-evidence) and [EU AI Act record-keeping](/eu-ai-act-recordkeeping) -- the regulatory mappings. * [.epi Evidence Export](/epi-evidence-export) -- hand an auditor a portable, offline-verifiable evidence set. ## Get Records Vault Records Vault is not sold standalone. It ships inside the [Verifiable Compliance Suite](/verifiable-compliance-suite). One commercial licence installs the whole compliance estate, including the [Verifiable Archive](/verifiable-archive), the [S3 backend](/verifiable-archive), the [Archive Auditor](/verifiable-archive), 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](/verifiable-compliance-suite) for licensing, or [email us](mailto:hello@algovoi.co.uk) for Enterprise / OEM.