> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Audit Chain
> End-to-end audit chain — how every AI call, data access, and PHI event is logged and verifiable.
Every AI call, data access, and PHI event on HASP is written to a tamper-resistant audit chain. The chain is **tamper-resistant at the database layer**, **tamper-evident at the cryptographic layer**, and **externally anchored** to a third-party timestamping authority — and you can verify all of it independently, without trusting HASP's application.
## How the chain is built
Each audit entry is linked into a per-org hash chain. Three mechanisms harden it:
| Layer | Mechanism | What it defends against |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Hash chain** | Each sealed entry carries a SHA-256 hash linking it to the previous entry. | Tampering with, or deleting, any entry breaks the chain and is detectable. |
| **Per-entry signature** | Each sealed entry is signed at write time with your organization's own Ed25519 key (held only in wrapped form, never in plaintext). | Forgery and coordinated rewrites — altering a record means re-signing it with a private key HASP does not hold. |
| **Database immutability** | `BEFORE UPDATE` and `BEFORE DELETE` triggers block mutation of integrity-sealed rows at the storage layer. | Application-level or direct-ORM tampering — the trigger fires regardless of how the SQL is issued. |
| **External anchoring** | A daily job submits the latest chain hash for each org to an RFC 3161 Timestamping Authority. | A superuser who rewrites the database — the anchored timestamp proves the chain's prior state existed. |
Writes are serialized per org (advisory lock + transaction) so concurrent writes cannot fork the chain, and verification streams the chain in bounded memory so it scales to 7+ years of activity.
## Signed, independently verifiable exports
An audit export is a self-describing `audit-export.json` envelope, signed end-to-end with **per-tenant Ed25519** keys for non-repudiation. It contains:
| Field | Purpose |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `entries[]` | Each audit record with its canonical fields, `prev_hash`, `hash` (the record's integrity hash), and a per-record Ed25519 `signature`. |
| `verification.public_key_pem` / `key_id` | Your organization's published Ed25519 key — the same key served at the well-known endpoint below. |
| `verification.chain_head_hash` | The head of the exported chain. |
| `verification.tsa_anchor_chain[]` | The raw RFC 3161 timestamp token(s), so the third-party timestamp travels with the export and verifies offline. |
Verification is self-contained and needs no HASP software: confirm the embedded key matches the independently-published key, recompute each record's hash and confirm the chain links, verify every per-record signature under the published key, and validate the RFC 3161 timestamp over the chain head.
Your organization's audit public keys are published at `/.well-known/audit-keys.json` and `/trust/keys/{org_id}` so a verifier can confirm the embedded key against a source HASP does not control.
## Verify it yourself with `@usehasp/verify`
HASP publishes an open-source verifier that checks a signed export end-to-end — hash chain continuity, Ed25519 signatures, and the RFC 3161 TSA timestamps — entirely on your machine:
```bash npm theme={null}
npx @usehasp/verify export.json
```
The package is on [npm](https://www.npmjs.com/package/@usehasp/verify) and the source is on [GitHub](https://github.com/UseHasp/verify). Because verification is independent, you do not have to trust the same system that produced the data — the proof travels with the export.
HASP also exposes server-side verification surfaces: a public-key endpoint, a verify-export endpoint, and a live chain-health check on the compliance settings page.
## Applies to every org — including Free Evaluation
The full chain applies to every organization, paid and Free Evaluation alike. A prospective customer who registers an agent, watches it execute through the policy gate, and downloads a cryptographically signed export *during their evaluation* has seen the substrate doing its job — not a feature tour.
| Dimension | Paid org | Free Evaluation org |
| ------------------------------ | ---------------------------------------- | -------------------------------------- |
| Integrity-chained audit | Full | Full |
| Database immutability triggers | All sealed rows | All sealed rows |
| Ed25519-signed exports | Available | Available |
| Public verification endpoints | Available | Available |
| RFC 3161 daily anchoring | Anchored | Anchored |
| Retention | Tier-packaged (minimum 7 years for paid) | 30 days; carries forward on conversion |
When a Free Evaluation org converts to paid, the chain continues uninterrupted — no reset, no new genesis hash.
**IP-address logging is a compliance floor, not a tier feature** — it is included on every paid tier because HIPAA §164.312(b) requires access logs to capture enough context to reconstruct who accessed what from where. Device-metadata logging (user-agent, OS, device fingerprint) is distinct and remains an Enterprise-optional surface.
## What PHI events look like in the chain
PHI events (`gateway.phi_detected`, `gateway.phi_redacted`, and every subsequent step) are recorded — but the **original PHI is never persisted**. Rows carry the redacted form plus entity-class metadata only. See [BAA Structure](/platform/baa-structure) for how PHI handling feeds the chain.