Prove what happened. Without ever storing what was said.
Every run on the Vault AI appliance leaves behind an append-only record of how the work was done — which local engine handled each step, how many indexed documents it was grounded against, how long it took, and that execution never left the box. The record is fully defensible because it contains no client content at all.
What a matter's audit trail actually looks like
Pick a matter to inspect its on-box execution record. These are the exact fields written for every run — no more, no less.
| Step | Task | Local engine | Docs | Execution | Latency | On-box |
|---|---|---|---|---|---|---|
| n1 | extract_parties | vault-slm-8b (local) | 4 | parallel | 820 ms | |
| n2 | extract_dates | vault-slm-8b (local) | 2 | parallel | 764 ms | |
| n3 | classify_change_of_control | vault-slm-8b (local) | 3 | parallel | 1943 ms | |
| n4 | assess_indemnity_exposure | vault-slm-8b (local) | 3 | parallel | 2211 ms | |
| n5 | synthesize_risk_memo | vault-slm-legal (local) | 1 | sequential | 4380 ms |
Note the columns that do not exist: no prompt, no completion, no party names. The record proves the process, not the content.
What is written — and what can never be written
The schema is deliberately narrow. Content-bearing fields are absent by design, not filtered at read time.
Which step ran, and where it sat in the sequence of work for that matter.
The exact local engine build that handled each step, so results stay reproducible.
How many indexed documents the step was grounded against — counts only, never content.
Per-step latency and whether the step ran in a parallel wave or sequentially.
Proof that the step was executed by the appliance with no outbound connection.
A hash tying the record to the run without storing any of the underlying content.
- Prompt text or uploaded document content
- Model completions or generated drafts
- Client names, matter parties, or identifying values
- Any copy of the source documents the step was grounded against
Because these fields have no column in the table, a misconfiguration, a subpoena of the log, or a compromised credential still yields zero privileged content.
Who can read the log, and how long it lives
Audit records are scoped to your firm workspace and isolated at the database layer — no cross-tenant reads are possible, including by us.
Row-level security ties every record to your firm. A query from another workspace returns nothing — the filter is enforced by the database, not the application.
Records are written once at execution time. There is no edit path and no delete path from the product surface, so the trail cannot be quietly revised.
Filter by matter or date range and export CSV or JSON for client security questionnaires, insurer reviews, and internal risk committees.
How the log maps to your obligations
Reasonable efforts to prevent unauthorized disclosure. The log evidences that every step executed on firm-owned hardware with no outbound connection — without itself becoming a disclosure surface.
Because the record contains no client content, producing it in a security review or audit never risks a privilege waiver.
Outside counsel guidelines increasingly require per-request model attribution. Export a matter-scoped log as CSV or JSON to answer those questionnaires directly.
Immutable, append-only records with timestamps satisfy internal governance without giving reviewers access to the underlying matter.