How your data is handled
What it represents
Scoring needs your history, and your history has people in it. Two questions are worth answering plainly: what actually leaves your CRM, and what ax1om keeps once it has it.
What leaves is the fields you select, plus a small fixed set of join keys. Those keys are the record IDs, the email address, and company and country, and they exist for one job · linking a lead to a contact to an account. Fields you did not select are not queried. ax1om does not take a copy of your objects and sort it out later.
What survives ingest is narrower still. Direct identifiers · names, email addresses, phone numbers · are replaced before anything is written to storage. What persists is the derived form: a business domain, a token that tells you two records share an address, and a flag saying whether an address was there at all.
The PII badge in the field picker is the product saying “this column looks like it identifies a person”. It is a signal to you. It is not a lock on the field.
How it’s calculated
The PII badge
The badge comes from two places. ax1om reads the field name and samples the values, so a column named email or phone, or one whose values carry an at sign, gets flagged. You can also mark a field yourself, and the product records that the flag came from you rather than from detection.
Selecting a flagged field does not put its raw values into storage. On a CSV upload the file is de-identified in memory before it is written anywhere: an email column becomes a domain plus a token, name and phone columns become presence flags. On a CRM connection the raw values live only for as long as the assembly is running, and they are stripped out of everything that gets saved · the training snapshot, the stored feature table, the cached scores. A save that would still carry a raw identifier fails instead of writing.
So the badge is not a gate. It is there for a judgement you probably want to make anyway, which is the last section of this article.
An email is treated as two separate things, because the two parts are worth different amounts.
The domain is a business signal. A company domain says something about the account, and a free provider says something quite different, so free and disposable providers are recognised from a maintained list and the domain is dropped rather than stored as a value. That signal is derived wherever an email column is present in the assembled data, whether or not you picked the email field yourself.
The address is not kept. It is replaced by a short fixed-length token derived from it, a truncated keyed HMAC-SHA256, which is enough to tell that two records carry the same address without the address being stored anywhere.
How people match to accounts
Matching runs as a cascade, and it stops at the first tier that answers.
- The link your CRM already holds · the account a contact points at.
- The account a converted lead was converted into.
- A lookup field you nominate yourself.
- Email domain plus country.
- Email domain alone, and only when exactly one account carries that domain.
The first three are recorded as high-confidence matches because your CRM asserted them, not ax1om. The domain tiers are recorded as medium, and they are the last resort rather than the method. Free and disposable domains are excluded from those tiers outright, and a record with no email is treated the same way · excluded, not guessed at. At the domain and country step, where more than one account is still a candidate, the tiebreak is fixed and dated: most recent opportunity, then most recent activity, then most recently created. At the final step there is no tiebreak at all: a domain shared by two or more accounts produces no match, and the record stays unmatched rather than guessed at.
There is no fuzzy matching anywhere in that path. “Acme Corp” and “Acme Corporation” are not merged on the strength of looking alike, and no company name is compared by similarity.
That is a deliberate call, and it costs something. Comparing every person against every account is quadratic work · on a book of 300,000 people against 200,000 accounts that is a lot of compute to buy a guess. The bigger reason is what a wrong merge does. It does not mislabel one record, it teaches the model something false about an entire account and every person attached to it. Exact keys are cheap and they are checkable. The price is that some records a human would match do not match, and those stay unmatched rather than being attached to the wrong account.
What it means for you
Sample data has no real people in it. It is generated: first and last names drawn from fixed lists and combined at random, addresses built onto invented domains like company00042.com, phone numbers that are digits. That is why you can walk the entire product, train a model, and read its output before you have a single conversation with your own security team.
A flagged field is your call. Nothing about the badge stops you selecting it, and selecting it does not put a raw address into storage. What the badge is for is the modelling judgement: a value that is unique to every record has nothing general to teach a model, so an identifier usually earns its keep as a domain or a presence flag rather than as itself. Flagging a column you know is sensitive also makes that intent explicit for whoever reviews the score after you.
Records that do not match stay unmatched. Because the cascade refuses to guess, a person whose account link is empty and whose only address is on a free provider will not be attached to an account. If that describes a large share of your data, the fix is upstream in your CRM · populate the account lookup, or nominate the field you already use for it · rather than a looser match here.
Worked example: you connect Salesforce and select 40 fields. ax1om queries those 40 plus the join keys. Two of your selections carry a PII badge · Email and Phone. You keep them. Training assembles the data, links contacts to accounts through their existing account lookup, falls back to domain matching for the leads that have none, and drops the ones on free providers instead of attaching them somewhere plausible. When the run finishes, the stored training data holds a business domain, a token, and a phone-present flag. The addresses and numbers themselves were never written down.