Product notes
Where personal information lives
This design began with an uncomfortable moment in everyday operations: investigating a failed login and seeing information you did not need to see.
Investigation puts identity on your screen
Run an identity platform and this arrives regularly: "one of our users can't sign in." To diagnose it, you enter the customer's environment and find the account.
What you need is narrow. Is it locked. When did the last attempt fail, and where. Which route did they come through. Is the passkey registration still valid.
None of that involves who the person is. Open the account anyway and their name is there. Their email. Their phone number. Their linked account handles, all on the same screen. You needed state. You got a person.
"Please don't look" is not a control
while it is rendered on the page.
And nothing here went wrong. The customer asked. You followed procedure. You did the work. You still saw it. The structure put it in front of you.
Solve that with policy and training and you have built a control that depends on an engineer's memory and conscience. Depend on that long enough and it becomes an incident. Separating personal data into its own database started as an attempt to solve this one thing structurally.
Two databases, drawn from the start
Identifying data sits in a physically separate database. Not retrofitted — the repository layer is split at the source.
Split this way, the opening problem dissolves. Lock state, failed attempts, device information — all of it is on the left. You can grant the access an investigation needs without granting the right side. Nobody has to remember to look away.
The same structure answers audit questions as a side effect. "Where do names and email addresses live" has a one-line answer, and deletion scope can be shown as a range. Solving the operational problem produced the explainability — in that order.
This does not mean PII DB is the only personal data
Worth stating bluntly, because the misreading is dangerous. This split is not a legal boundary between personal and non-personal data.
Core DB holds IP addresses, device information, session history, authentication events, credential metadata and stable internal user IDs. Depending on context, those are personal data too. Individually they may not identify anyone; combined with other information, they can.
What Authrim actually separates is directly identifying data from operational identity data. The goal is that an investigation can run on the second without touching the first — not that the second needs no protection.
So never say "personal data only exists in the PII DB." Say: "directly identifying data such as names and email addresses is isolated in the PII DB, and investigation access can be granted without reaching it."
Deleting is the easy half
"Delete my account" is trivial to execute. The two requests that follow are not.
One is proving the deletion — when, by whom, and why, recoverable later. The other is blocking re-registration for a retention window, which is a common business rule.
Which is a contradiction. Both need you to recognise a person you supposedly erased. Keep anything that identifies them and you did not erase them.
The implementation states its own reasoning: store no PII, keep only the fingerprint needed to prevent duplicates, expire after the retention window, and record who deleted, when, and why.
What "not recoverable" depends on
One note for engineers. Email addresses are low-entropy. Fingerprint them with a plain hash and a dictionary attack recovers the original. "Not recoverable" is not unconditional.
Authrim uses an HMAC-SHA256 blind index with a secret key, carrying a key-generation number so keys can be rotated. Without the key, brute-forcing the fingerprint is not available.
Which means key isolation is the precondition for the guarantee. Store the key beside the fingerprints and the guarantee is gone. Do not drop that condition when describing this externally.
Give an investigation only what it needs
Return to the failed-login report. The investigator needs to find where authentication stopped. They usually do not need to open a name or phone number.
Authrim separates directly identifying information so that troubleshooting access can be granted without access to that store. When an investigation does need personal information, someone with the appropriate additional permissions handles it.
Encryption and access control protect the data; audit logs record its use. Alongside those measures, an investigator should be able to finish routine work without opening personal information they do not need. Separating storage makes that the starting point for everyday operations.
Implementation. Complete — storage split and access boundary both in effect
Validation. Covered by automated tests in this repository
Operational maturity. Hardening in progress. Authrim is pre-1.0.
This design makes deletion workflows easier to run. It is not itself a statement of legal compliance. Actual conformance depends on your procedures and contracts. Keep that distinction in external material.