A hash chain over the events
Every event is linked by SHA-256 to the one before it. Editing an event in place breaks the chain, so the store cannot quietly disagree with its own history.
An append-only audit log where every event carries the hash of the one before it, so an edit or a deletion breaks the chain and shows up in verification. Per-subject encryption means a GDPR erasure request destroys a key rather than a row, and the chain still verifies afterwards. Exports SOC 2, HIPAA and EU AI Act reports.
Each event carries the hash of its predecessor. Tampering with one breaks the chain, and the break is detectable.
Per-subject AES-256-GCM encryption. Destroying the key makes the data unrecoverable while the hash chain stays structurally valid.
SOC2, HIPAA, the EU AI Act and custom reports from one call, exported as JSON, CSV, Markdown or HTML.
An audit log that can prove it was not edited, and can still forget a person when the law says it must.
Every event is linked by SHA-256 to the one before it. Editing an event in place breaks the chain, so the store cannot quietly disagree with its own history.
Each subject gets its own AES-256-GCM key. Destroying that key makes the subject unrecoverable while leaving the chain valid, which is the only way I found to satisfy both the auditor and the regulation.
SOC2, HIPAA, the EU AI Act and custom report shapes, exported as JSON, CSV, Markdown or HTML.
Scope middleware writes the App and tenant onto every event, and query isolation follows from that, with no filter for a caller to forget.
Hooks enrich or drop events on the way in, and an alert handler fires in real time when severity or category matches.
Development runs in memory and production runs on Postgres or Bun ORM. A store of your own is about thirty-six methods.
Hash-linked entries; tampering breaks the link.
Deleting the key deletes the content, not the chain.
Who did what to which record, answerable months later.
Chronicle is an immutable audit trail. Every event is linked to the one before it by SHA-256, so editing or deleting an event breaks the chain and shows up in verification.
It does not prevent tampering, since nothing prevents someone with database access from writing to the database. It makes tampering detectable, which is the property auditors are actually asking about.
An append-only hash-linked log and a right to erasure are not compatible in their naive forms. Chronicle resolves it with per-subject AES-256-GCM encryption: personal data in an event is ciphertext under a key belonging to that data subject, and the key lives outside the log.
Destroy the key and the ciphertext stays exactly where it is with its hash unchanged, so the chain still verifies end to end, while the plaintext is unrecoverable.
You delete the key, not the record.
The catch is that key management becomes the whole problem, including backups of the key store, and that a key vault with a thirty-day soft-delete window quietly invalidates the claim.
An audit event has a fixed shape: actor, action, resource, outcome, scope, timestamp. Every request to add a free-form field has been refused. That is why a compliance report is a query rather than a text-mining project.
Shipping something on Chronicle? Nobody is listed here yet. Tell me what you built and you will be the first.
Get listed →