Erase the Person, Keep the Record

Two obligations point in opposite directions. A person can ask you to erase their personal data, and you have to honour it. An auditor can ask you to produce an unbroken record of who changed a pricing rule eighteen months ago, and you have to honour that too.

Systems that store an email address on every record can only satisfy one of them. Erasing the person either rewrites history or leaves their address sitting in ten thousand rows that were supposed to be immutable. AI Rule Engine no longer has to choose.

Names are resolved, not stored

Records now point at the person rather than carrying a copy of their details. What you see has not changed - the audit log, run history, API key listings, and pipeline screens all show the person’s name exactly as before - but the name is looked up when the screen is drawn rather than frozen into the record when it was written.

That one change is what makes the rest possible.

What erasing an account actually does

When an account is removed, the person’s name and email address are cleared, every way of signing in is unlinked, active sessions are revoked, and they leave every organization they belonged to. It cannot be undone.

What is not removed is the trail. Every entry they were responsible for stays exactly where it was and reads Deleted user from then on. A release they approved is still a release that was approved. A rule they edited still shows an edit, on the date it happened, with the metadata around it intact. The audit trail is kept in full.

That distinction matters more than it sounds. An erasure that quietly turned approvals into blanks would not be privacy - it would be a hole in the record, and the first person to notice would be an auditor asking why a production change appears to have approved itself.

Ownership has to move first

An organization with no owner has nobody who can administer it, so an account cannot be erased while it still owns one. Before anything is removed, you are shown exactly which organizations are in the way.

The fix is a Transfer ownership control on the organization’s settings page. The current owner picks another member, confirms, and ownership moves immediately. The outgoing owner stays on as an Admin, so nothing about their day-to-day access changes - what they give up is the two things only an owner can do: transferring ownership again, and deleting the organization.

Only members who have actually signed in can be offered ownership. An invitation nobody has taken up has no account behind it, and handing an organization to one would leave it owned by someone who does not exist yet.

Invitations you can now see the state of

Because a member row can exist before the person behind it does, the member list marks the difference. Someone who has been invited but has not signed in yet shows as Pending. They hold their role from their first sign-in; until then there is nobody there.

The same distinction shows up in your history. An entry from an invitation nobody has claimed reads Invited rather than pretending to name a person.

And when it was not a person at all

Not every change is made by a human, and the record says so plainly. An action taken by a machine credential shows the kind of credential instead of a name - an API key, an MCP token, a managed host, or the System itself for platform-driven work like a scheduled run. Hovering it confirms this was not a person.

“Who did this?” now has exactly three honest answers: a named person, a specific kind of credential, or somebody who has since been erased. There is no fourth answer where the record simply stops.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team