Consistent pseudonyms across years of history

Most discussions of pseudonymization focus on space: the same person should get the same token in chat, email and the ticket tracker. Time is the harder dimension. Over several years, people change names, email addresses, roles and usernames, and companies change tools. If the pseudonyms do not follow those changes, a five-year history quietly turns into a collection of strangers.

A company's records were never designed to be read as one continuous story. Each tool identifies people in its own way, and those identifiers drift.

Imagine a hypothetical 80-person services firm with six years of history. Over that period:

• An engineer changes her surname, and her email address changes with it.
• The company rebrands and moves everyone to a new email domain.
• A contractor becomes a full-time employee and gets a new account in every system.
• An account manager leaves and, two years later, rejoins under a new username.
• Two different people share the same first name and surname.
• A key customer is acquired and starts writing from its parent company's domain.
• The team moves from one ticket tracker to another midway through, and only some old tickets are imported.

None of this is unusual. Any multi-year archive contains versions of it. Each change creates a point where a naive tokenizer, mapping one identifier to one token, either gives a new pseudonym to someone who already has one or merges two people into a single token.

When one person splits into several tokens, the history fragments. The engineer who designed a system in year two appears unrelated to the engineer who maintained it in year five. A customer relationship that spans the rebrand looks like two separate accounts. Long-running projects, some of the most useful material for training agents, lose their continuity.

When two people collapse into one token, the opposite happens. A single pseudonym seems to hold two roles, appear in two places at once and contradict itself. That is harder to spot and arguably worse, because it creates patterns that never existed.

Both errors reduce what the data can teach. A model learning how teams coordinate needs to know who is speaking to whom, and whether the person reviewing the pull request is the one who wrote the ticket. We explain the cross-tool version of this problem in why the same person must get the same token everywhere.

The answer is to tokenize identities, not identifiers. Instead of mapping each email address or username to its own token, the anonymization process builds a single identity map for the company. Each real person, company, address and account is one entry in that map, and every identifier that refers to it, whether an old email, a new email, a chat handle, a commit author name or a ticket assignee, points to the same entry.

Building that map means resolving the drift described above. Name changes, domain changes, account migrations and returning employees are linked to existing entries rather than given new ones. People who share a name but not an identity are kept apart. Customers and partner companies get the same treatment, so an acquired customer remains one company token before and after the acquisition.

Once the map exists, it is applied the same way to every tool and every year. PERSON_014 in a chat message from year one is PERSON_014 in an email from year six. The map that links tokens back to real names is never part of what a buyer receives.

Other protections apply regardless of time. Credentials, API keys, card numbers and government IDs are removed outright. Faces, logos and signatures are blacked out in images and PDFs. HR, payroll, medical and legally privileged folders are excluded by default, and direct messages are excluded unless the company includes them and has the right to. The full approach is described on our trust page.

Consistency over time makes data more useful, and it also deserves respect from a privacy point of view. A long, coherent pseudonymous history carries more context than a short one. That is a reason for care, not a reason to break the data.

The safeguards work together. The seller sets scope and exclusions, which are annexed to the contract before any data moves. The seller reviews an anonymized sample before delivery and can check that tokens hold across the period and that nothing identifying slipped through. The licence restricts use to training and evaluation and prohibits any attempt to market to, profile, contact or re-identify anyone in the data. No third party touches the raw data, and the raw archive is deleted within 30 days of sign-off as a contract obligation, with a deletion certificate. Re-identification risk and how to reduce it goes further into the trade-offs.

If you are reviewing an anonymized sample from a multi-year archive, a few checks are worth making. You know your company's history better than anyone, which makes you well placed to spot a break.

• Pick someone who changed their name or email and confirm they keep one token throughout.
• Pick a project that spanned a tool migration and confirm the people involved carry the same tokens on both sides.
• Look for two colleagues with similar names and confirm they have different tokens.
• Confirm that a long-standing customer keeps one company token across any rebrand or acquisition.
• Read a thread from your first year and one from your last, and check that nobody's real name, email or phone number appears in either.

If you are considering licensing your company's history and want to see how this works on your own records, book a 15-minute intro call.