# De-identified workflow data utility | SourceX

Canonical: https://refer.sourcex.si/guides/deidentified-workflow-data-utility
Last updated: 2026-10-20

De-identification can keep a workflow intact by replacing each identifier with a consistent token, so the ticket, the work order, the notes and the invoice still point to the same case without naming the customer. Dates can be shifted by a fixed offset that preserves intervals, and free text can be masked in place. None of this makes data anonymous: linked tokens and remaining details still carry re-identification risk, which is managed through context, contracts and review rather than promised away.

## How can de-identification preserve useful workflow links without guaranteeing anonymity?

By transforming identifiers consistently rather than deleting them, and by treating the result as risk-reduced data that still needs controls. The links survive because the same real value always maps to the same token; the risk survives for the same reason.

Workflow data is valuable because of its chain: a request, the steps taken, the decisions, the outcome. The [primer on workflow data](/proof/what-is-workflow-data) covers why. Delete every identifier and the chain falls apart into unrelated fragments. Replace identifiers with stable tokens and the chain holds.

NIST SP 800-188 lists the main techniques: removing identifiers, transforming quasi-identifiers (details such as location or dates that identify in combination) and generating synthetic data. The same publication warns about the trade-off at the heart of this page: although pseudonymous records are usually re-identified only by consulting a protected key, the existence of pseudonym identifiers frequently increases the risk of re-identification through other means.

## The before and after record chain

Illustrative only. A 400-person field service company handles a repair request across five systems. The table shows how each field might be treated during preparation; the actual method for any license is set during SourceX's review of the specific data.

| Record | Field | As held by the company | As prepared | Workflow link kept? |
|---|---|---|---|---|
| Helpdesk ticket | Customer | Full name and phone number | CUST-4821, the same token in every system | Yes |
| Helpdesk ticket | Ticket number | Native helpdesk ID | TKT-0193, mapped consistently | Yes |
| Dispatch work order | Site address | Street address | Service zone only | Partly: region kept, address removed |
| Dispatch work order | Technician | Employee name | TECH-17 | Yes |
| Technician notes | Free text | Mentions the customer's name and a gate code | Text kept; name and code replaced with typed placeholders | Yes: steps and reasoning survive |
| Parts order | Timestamps | Calendar dates and times | Shifted by one fixed offset per case | Yes: durations and order preserved |
| Invoice and credit | Amount | Exact amount | Kept or banded, depending on the dataset | Depends on the dataset |

What a model can still learn from the prepared chain: that this kind of fault was escalated after a failed first visit, that a part was ordered on day two, that the credit was issued after a follow-up call, and how long each step took. That is the workflow. What it cannot learn: who the customer was or where they live.

## Why tokens reduce risk but do not remove it

Three things keep identifiability above zero even after careful preparation.

1. **The key exists.** Whoever holds the token map can reverse it. The ICO's guidance is direct: if people can still be identified using additional information held separately, the data is pseudonymized rather than anonymized, and the ICO's transfer guidance confirms that pseudonymized information still counts as personal data.
2. **Links accumulate detail.** A token that appears across many records gathers quasi-identifiers: a service zone, a rare piece of equipment, an unusual sequence of dates. Combined, they can single someone out. This is NIST's warning about pseudonyms in practice, and the [quasi-identifier guide](/guides/quasi-identifiers-re-identification-risk) walks through how the combination works.
3. **Risk depends on the recipient.** HHS guidance on HIPAA's Expert Determination method says there is no explicit numerical level of identification risk that universally counts as "very small", and that a risk determined for one dataset in one environment may not be appropriate in another.

So the honest claim is not "this data is anonymous". It is: identifiers were transformed by a stated method, residual risk was assessed for a stated recipient and use, and contractual and technical controls cover the rest. NIST describes governance tools for that assessment, including Disclosure Review Boards and re-identification studies. For the legal distinction in more depth, see [pseudonymisation vs anonymisation under GDPR](/compare/pseudonymisation-vs-anonymisation-gdpr); for a single system, see [anonymizing support tickets](/guides/anonymize-support-tickets).

## A utility check a company can ask for

Before agreeing on a preparation method, a company can ask whether the prepared sample passes four tests:

- **Chain test:** can a reviewer reconstruct each case end to end from tokens alone?
- **Interval test:** are the durations between steps the same before and after?
- **Text test:** do masked notes still show the reasoning, with placeholders typed (customer, code, address) rather than blanked?
- **Leakage test:** does any free-text field, attachment name or file path still carry a raw identifier?

An example pack, such as the [software workflow example pack](/resources/software-workflow-example-pack), shows the kind of linked chain described here, and [why enterprise AI needs enterprise data](/proof/why-enterprise-ai-needs-enterprise-data) explains the demand side.

## Does the company qualify, and what does the partner touch?

The partner touches nothing: discovery stays at metadata level. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English.

The company also needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license its records and an authorized contact. A partner can usefully note which systems hold the workflow, how many years it spans, and whether customer terms say anything about reuse. De-identification is a preparation step, not a permission: the difference is set out in [de-identification vs permission to license](/guides/how-to-distinguish-de-identification-from-permission-to-license). What stays unknown until SourceX reviews the opportunity: dataset demand, the rights review result, the preparation method and any offer.

## The company's payout and the reward

The company is paid its Actual Supplier Payout under its own agreement, and SourceX funds any reward separately. Illustrative only: an Actual Supplier Payout of $250,000 would mean a reward of $62,500, and $800,000 would still mean $100,000 because of the per-company cap.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If you know a company whose workflow records span several systems and whose owner is open to a licensing conversation, [register as a partner](/register), check the basics against [who qualifies](/who-qualifies), and read the [program terms](/terms) before you make the introduction. Related reading is in the [guides hub](/guides).

## Sources

- https://refer.sourcex.si/terms
- https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html
- https://csrc.nist.gov/pubs/sp/800/188/final
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-188.pdf
- https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/introduction-to-anonymisation/
- https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/a-guide-to-international-transfers/are-we-making-a-restricted-transfer/