Key takeaway
A relationship key can make records useful without routine customer identifiers. It can also make them more linkable. Review both consequences before releasing it.
Choose the relationship before choosing a token
Ask what the evaluator needs to connect. A repair question may need a job, its visits and its outcome. It may not need the customer’s name, email, street address or every job that customer ever commissioned. Drawing that relationship first can avoid exporting a persistent customer identifier merely because it is convenient in the source system.
NIST’s government dataset guidance explains that pseudonyms can support repeated-observation matching while leaving identification risks. It also warns that linked observations can reveal more than isolated records. This is technical guidance, not a determination that a private package meets a particular jurisdiction’s anonymity test. The proposed design below requires a separate privacy and authority review.
W3C’s PROV overview treats provenance as information about what produced data. That suggests preserving an internal record of how join keys were assigned and which relationship they represent. A documented token does not establish permission to disclose the linked records.
A proposed job-level package
This illustrative package supports evaluation of repeat visits within a single job. The owner assigns a random package-specific job token, and each visit refers to it. A separate outcome table also refers to that job token. The internal mapping to the source job identifier remains with the owner; it is not placed in the shared package or its manifest.
The rows are invented to demonstrate structure. They contain no actual customer records. Random-looking keys are not sufficient protection: an unusual combination of dates, location, equipment and narrative may still identify a person or organization.
| Artifact | Example fields | Relationship boundary |
|---|---|---|
| Jobs | job_token J7; equipment class; issue category | One job within this package |
| Visits | visit_token V2; job_token J7; action category | Multiple visits can refer to J7 |
| Outcomes | job_token J7; observation window; result label | Outcome attaches to this job |
| Owner-held mapping | J7 → source job identifier | Restricted internal record; excluded from delivery |
| Excluded customer table | Name, email, address, global customer identifier | Not needed for the stated evaluation |
Test utility without enlarging the scope
Check that every retained visit joins to an included job, that duplicated tokens do not merge unrelated jobs, and that an outcome is not attached to the wrong attempt. Declare whether a job can have several assets or whether one asset can appear under multiple jobs. A row count alone cannot reveal those relationship mistakes.
In a hypothetical package with three jobs and five visits, one visit refers to a job excluded during review. The owner can exclude that orphan visit or include a permitted, minimal parent description after review. Replacing the missing job key with the customer’s email would solve the join technically while expanding disclosure beyond the approved purpose.
Consider whether an unlinked package would answer the first evaluation question. A buyer reviewing terminology may need only isolated descriptions, while a buyer studying recurrence needs temporal relationships. Offer the minimum useful structure for that stage rather than assuming all future uses need the broadest linkage.
Review what can still identify a subject
Build a risk agenda around the actual package: persistent keys across releases, precise event times, rare equipment, free-text names, locations and the recipient’s other information. These are questions for the owner’s engineering and privacy reviewers, not a checklist that automatically certifies anonymity. Review the combined package and previous disclosures as well as each field in isolation.
NIST specifically discusses protection of lookup information and risks associated with transforming direct identifiers. A plain hash of a predictable identifier should not be treated as equivalent to a carefully designed, reviewed token system. Even a restricted mapping does not remove risks that come from other attributes or repeated linkable releases.
If new releases need continuity, document why stable linkage is necessary, who can use it and when its scope expires. If continuity is unnecessary, package-specific keys may reduce avoidable matching opportunities, but changing keys alone does not establish that matching is impossible.
Record a decision that another reviewer can inspect
The handoff should identify the purpose, join graph, excluded identifiers, owner of the internal mapping, tested relationship rules and unresolved linkage risks. Record whether the decision permits only a description, a bounded evaluation sample or a specified license. A recipient name and an approved use matter more than a general statement that the data are clean.
Proceed when the permitted structure answers the stated question and the responsible reviewers have addressed the residual risks. Narrow or pause if usefulness depends on unnecessary person-level linkage or if the owner cannot establish authority for the included fields. VOID does not receive raw records or certify an export as anonymous; it can coordinate a scoped introduction with the owner’s permission.