Security, Audit & Compliance

Event sourcing and privacy law look, at first, like they cannot coexist. The event log is meant to be an immutable record of everything that happened. GDPR says a person can demand their personal data be erased. You cannot both keep every event forever and delete someone's data on request. Chronicler's answer to that contradiction is the most interesting decision in this area.

Erase the key, not the history

Personal data tagged as sensitive is encrypted per subject at the boundary of the event store, each subject with their own key. Erasing a person, the right to be forgotten, does not rewrite history. It destroys that person's key. The events stay exactly where they are, but the encrypted fields inside them become permanently unreadable. This is crypto-shredding, and it lets an append-only log honour a deletion request without violating its own append-only nature.

One rule makes it safe in practice: on shred, the system anonymises and never fails. A value whose key is gone degrades to an anonymous placeholder rather than throwing an error, so a rebuild after an erasure still runs cleanly.

One registration serves both rights

GDPR grants two rights over personal data: erasure and access. Chronicler serves both from a single registration, the PII custodian. Erasure works by reprojecting a shredded subject's rows. Access works by asking each custodian what it holds about a subject. The same set of registrations doubles as a static inventory of where personal data lives and a per-subject map of what is held where, so compliance questions have a real answer instead of a manual audit.

Two logs for two questions

There is a security audit log, and there is a user-facing history of changes, and they are deliberately not the same thing. The audit log is a dedicated, fully event-sourced, reprojectable record for security and compliance. The change history is what a worldbuilder sees about their own edits. They answer different questions for different people, so merging them would serve neither well.

The captured audit log is exposed through three read surfaces, a chronicle log, a workspace log, and an unfiltered platform-operator log, each behind its own permission and enriched with resolved identities so a row reads as names rather than ids.

Where this connects

The encryption sits on the Foundations event boundary, and the audit read surfaces are scoped by the model in Authorization.