Why the same person must get the same token everywhere

Anonymizing a company's data is not just about removing names. It is about replacing them in a way that keeps the story intact. If the engineer who opened a ticket in Jira is PERSON_014, she has to be PERSON_014 in the Slack thread, the pull request and the email to the customer too, or the dataset stops making sense.

A token is a stand-in label. Instead of "Maria Alvarez" the data says PERSON_014. Instead of "Northwind Freight" it says COMPANY_087. The same approach applies to addresses, email addresses, phone numbers and account identifiers. Each real value maps to one token, and that token is used every time the value appears.

This is different from redaction, where a name is simply blacked out or replaced with a generic placeholder like [NAME]. Redaction protects identity but throws away structure. You can no longer tell whether two messages were written by the same person, or whether the customer in one email is the same customer in a support ticket. We compare the two approaches in Anonymization 101: tokenization vs. redaction.

Imagine a 60-person software company. A customer reports a bug by email. A support rep files a ticket, pings an engineer in Slack, and the engineer opens a pull request that a second engineer reviews. Two days later the support rep emails the customer to say it is fixed.

Now imagine each tool was anonymized on its own. The support rep is PERSON_003 in email, PERSON_118 in the ticketing system and PERSON_041 in Slack. The engineer has three different tokens too. The customer is COMPANY_009 in email and COMPANY_212 in the ticket.

The text is still there, but the thread is gone. A model trained on this sees five unrelated people and two unrelated companies. It cannot learn that the person who took the customer's call was the same one who chased the engineer and closed the loop. That chain of responsibility is the whole point of licensing workplace data, and inconsistent tokens cut it into pieces.

Getting consistency right is mostly an identity problem. Real people do not appear the same way everywhere. A single employee might show up as:

• a full name in the HR-adjacent directory and a first name in Slack
• a work email, an old email from before a domain change, and a personal address they used once
• a GitHub handle that looks nothing like their name
• a nickname in casual chat ("ask Mo, he knows")
• an initial in a meeting note ("MA to follow up")
• a display name that changed when they got married or switched teams

Each of those has to resolve to the same token. The same is true in reverse: two different people named Chris on different teams must not collapse into one token just because they share a first name.

External parties raise the same issue. A customer contact who emails sales, appears in the CRM, files support tickets and is mentioned in Slack should be one token. Their company should be one company token, whether it is written as the full legal name, a short form or an internal code name.

Tokens also have to hold across years, not just across tools. People join, leave and sometimes come back. Teams reorganize. Tools are replaced: the company that ran on one ticketing system for three years and another for two still has one continuous history, and the people in it should not be split at the migration date.

Long time spans are where much of the value sits, because they show how projects evolve, how decisions get revisited and how a team handles the same problem the second time. A dataset where someone's token resets every year loses that.

A fair question from sellers is whether consistent tokens make it easier to work out who someone is. The honest answer is that consistency gives a model more context, and more context is exactly why the rest of the safeguards matter.

So the token is only one layer. Credentials, API keys, card numbers and government IDs are removed outright. Faces, logos and signatures in images and PDFs are blacked out. HR, payroll, medical and legally privileged folders are excluded by default, and DMs are excluded unless the company includes them and has the right to. The company can exclude specific clients, channels or folders, and those exclusions are annexed to the contract before any data moves.

The delivered data carries tokens, not the mapping back to real identities. 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. The licence is for training and evaluation only, and buyers may never market to, profile, contact or re-identify anyone in the data.

Before anything is delivered, the seller reviews an anonymized sample. When you do, look for consistency directly. Pick one person you know well and follow them through a few tools. Check that their token is the same in chat, email and tickets. Check that a key customer has one company token, not several. And check that nicknames, initials and email signatures did not leak through.

If you want to see how this would apply to your own company's records, book a 15-minute call. Our full anonymization approach is on the trust page.