Privacy by architecture

“How can something immutable ever be GDPR-friendly?” is the first question a careful data protection officer asks about an append-only evidence chain. The answer is architectural, not contractual: the chain never knows the person.

The cut

The system is split into two components with opposite properties:

	The chain	The actor register
Contents	Pseudonymous actor UUIDs, hashes, timestamps, references	Identities: git identity, display name
Mutability	Append-only, enforced in the database layer	A normal table — deletable row by row
Who needs it	Verification, export, reports, courts	Only the dashboard, to show names

Every event in the chain refers to its actor by a randomly generated UUID — assigned on first appearance, with no mathematical link to any identity. No usernames, no emails, no display names, and free-text fields are shape-validated at ingest so identity-looking content is rejected by the contract, not by convention.

The mapping from UUID to person lives exclusively in the actor register, scoped to your organization.

Erasure is one operation

When a person exercises their right to erasure, their register row(s) are deleted — one operation. From that moment:

• the chain’s UUIDs stop being referable to the person (the link is destroyed — the same effect crypto-shredding has on encrypted data);
• every verification, export and report keeps working, because evidence reconstruction never reads the register;
• dashboards show deleted user (a7f3…) where a name used to be;
• the deletion itself is recorded in the chain as an event — carrying only the pseudonym, never the erased identity.

Nothing is rewritten, nothing breaks, and nothing about the person remains. If the same person is onboarded again later, they simply get a new UUID — which is correct behavior for an erasure, not a limitation.

One honest nuance, because backups exist everywhere data does: the register row also lives in database backups until those expire, and we keep backups for at most 35 days. Deletion is immediate in the live system, and complete once the last backup generation holding the row has aged out. A restored backup cannot quietly resurrect anyone — the deletion event sits in the chain, so restores replay deletions deterministically. We say this plainly rather than promise an instant that no backup-keeping system can deliver.

What this means for roles

The register is the only personal-data-holding component in the system. Your organization is the data controller for the identities in it; OLOBOLO processes them on your behalf — which keeps the data processing agreement short, and keeps the chain itself out of personal-data scope by construction rather than by promise.

Verification is register-independent by design: the exported chain, the public verifier and the RFC 3161 timestamps work — and prove integrity — without any identity existing anywhere.