> ## 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. **Also in the on-prem suite.** This product is included in the [AlgoVoi Compliance and Payments On-Prem Suite](/substrate-2), one commercial licence that unlocks and runs the complete self-hosted platform. **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** | Commercial bundle — perpetual or annual ([store](https://api.algovoi.co.uk/suite-store)) | **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. ## Get Records Vault Records Vault is a commercial **on-prem bundle** — it includes the [Verifiable Archive](/verifiable-archive), the [S3 backend](/verifiable-archive), and the [Archive Auditor](/verifiable-archive), 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. Available **perpetual (one-time) or annual subscription**, self-hosted, paid in **USDC**; the [store](https://api.algovoi.co.uk/suite-store) shows current pricing for both. 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](mailto:hello@algovoi.co.uk).