A company archive's identity links should follow the buyer's task

An issue-resolution archive has a reason to preserve who did what. Someone reports a fault, another person investigates it, and the original reporter confirms whether the fix worked. If those appearances are disconnected during preparation, the buyer can lose the distinction between an engineer declaring success and the affected person confirming it.

Rightmark's company-data research explains the value of linked records while warning that a stable code replacing a name can still leave personal data. The archive Clean Room pilot makes the design concrete: it describes keeping one person's token consistent across email, chat and CRM. Archive Check is available in early access; the jobs after it remain a pilot build. The useful design choice is continuity across systems, rather than treating each exported file as an isolated source.

But a system boundary and a task boundary are different things. A support issue might span email and a ticketing tool. A renewal negotiation might also use email and CRM. Including both systems does not establish that the buyer needs to connect the same person across both activities.

Consider this invented example; the company, people, event, records and identifiers are fictional. The buyer wants examples of how software issues progress from report to resolution. Assume its permitted collection includes the issue records described here. It has no task-related reason to receive the separate renewal conversation.

The proposed export contains these two fragments:

ISSUE-17, reporter PERSON-42: I was presenting the only session called “Retrying failed jobs” at the North Pier Developer Forum yesterday, so I could not check the fix until this morning. The retry now succeeds.

RENEWAL-09, contact PERSON-42: I objected to the proposed renewal and asked for different terms.

Assume the recipient has the public event program, which identifies one named speaker for that session and date. Assume the match is correct. Those are conditions of this example, not a measured finding about how often identification succeeds.

The first fragment supplies a route from an event to a person. The shared PERSON-42 then supplies a route from that person to the unrelated renewal objection. The recipient never needed the owner's private token-to-name key. It used a contextual clue to identify one appearance and the equal token to connect another.

There are two separate preparation decisions here. The event detail needs attention inside the issue thread. The renewal record needs a reason to be in the delivery at all. Changing the label on the renewal might remove the explicit token connection, but it would leave the irrelevant record in a collection intended to teach issue resolution. Omitting that record addresses the scope problem directly.

This is also why a clean list of name and address fields is an incomplete description of the prepared view. In the fictional issue, the revealing information is ordinary prose about a presentation. A review of the output needs to consider the retained meaning as well as the substitutions made by the cleaning process.

The UK's Information Commissioner's Office asks whether identification is reasonably likely using the information a recipient possesses or can obtain. Its guidance also rejects a test based on every theoretical possibility. The relevant question is therefore which connection is plausible in the actual release context. The ICO's anonymization guidance is UK-specific and marked under review following the Data (Use and Access) Act, as checked on November 14, 2026.

In this example the additional information is specified. In a real review, the person assessing the archive would need evidence for that assumption. Recognizing a possible connection tells the team what to investigate; it does not supply a probability or a legal conclusion about the collection.

After removing the unrelated renewal, there is still a choice about the issue records themselves. Should the same reporter have one identifier across every issue, or a consistent identifier within each independent issue?

Continue the invented example, now with ISSUE-17 and ISSUE-18. Assume both are permitted for the corpus, each contains a complete report-to-resolution sequence, and neither depends on or refers to the other. The buyer's task is to reconstruct each issue's handoffs and outcome. The table holds the records constant and changes only how far the reporter's identifier persists.

The middle column encodes an additional fact: the reporter in ISSUE-17 is the reporter in ISSUE-18. The next column does not encode that equality. It still lets the buyer follow each reporter from complaint to confirmation. Under the stated task, the buyer can read both sequences without being given that extra person-level connection.

This does not make the third column an anonymization result. The records retain their wording and other context, including the event clue unless it is separately changed. A reader might still connect them through those details. The comparison demonstrates one information difference: whether the identifiers themselves declare that the appearances belong to the same person.

Nor should every actor inside an issue collapse into a generic PERSON. The investigator needs a different identifier from the reporter, and that investigator's identity must remain consistent wherever the handoff depends on it. If one engineer escalates the issue to another, preserving two distinct actors is part of preserving the work. A transformation that makes everyone look like the same participant has removed a relationship the task requires.

The practical unit is therefore the workflow, which may span several systems. Giving each file an independent set of labels could disconnect the reporter's email from the same person's ticket confirmation. A proposed specification should say which appearances must match, rather than merely asking for new identifiers in every export.

The ICO's pseudonymization guidance connects identifiability to purpose and recognizes that pseudonymization can preserve utility. It supplies a useful question for this design choice: how much identity continuity does the purpose need? It does not prescribe the issue-scoped scheme shown here. That scheme is a proposed specification choice for the fictional task, rather than a claim about a current Rightmark feature.

For an owner, defining that choice early puts a substantive requirement into the preparation discussion. The team can ask whether the proposed output preserves the agreed relationships and whether the preparation method can produce it. For a buyer, it creates a chance to explain why an apparently unrelated link is necessary before that link is removed.

There is real work in drawing these boundaries. Someone must determine whether issues are actually independent, preserve references across systems and check that the output still represents the same sequence. A global identifier is simpler to describe and may be simpler to maintain. That is a credible engineering advantage. It does not, by itself, show that the recipient needs every connection the simpler design supplies.

The deciding question is concrete: what would the buyer be unable to answer if these two workflows no longer shared a person identifier? An answer that names a missing dependency can justify the link. A preference to keep every possible future option needs a broader scope discussion with the owner.

The strongest case for a common identifier is that a person can be the thread connecting work that was never neatly organized as one case. A later request may make sense only in light of an earlier promise, failed fix or workaround. If preparation cuts that connection, the dataset can lose the reason the buyer wanted the history.

Change the fictional task deliberately. The buyer now wants an agent to find which workaround a requester was previously given before answering a later support request. Assume the permitted scope includes those earlier interactions. The later record has no explicit reference to the earlier case, and the task requires identifying the earlier advice given to this same requester. These are invented records and assumptions, not a customer example.

Earlier interaction, PERSON-42: The engineer recommends disabling automatic retries while a patch is prepared. The requester confirms that they have applied the workaround.

Later interaction, PERSON-42: The requester reports that failed jobs are no longer retrying and asks what to change.

Question the agent must answer: Which earlier instruction explains this requester's current configuration?

A common person identifier gives the buyer an explicit way to gather that requester's relevant interactions. Separate identities for each support case would omit that connection. The buyer would need another reliable link or would have to infer that two appearances refer to the same person. Under these assumptions, the broader identifier is the better choice.

This is a different task from reconstructing two independent issue histories. It would be inconsistent to accept the new task while insisting on the old identity boundary. The scope should change because the required relationship changed, with the owner and buyer considering the relevant history together.

Simson Garfinkel, then a computer scientist at NIST, expressed the competing requirement at the May 24, 2016 NCVHS hearing: “What we need is procedures for evaluating the effectiveness of de-identification and evaluating the usefulness of the data that remain.” His point makes the wider-history case worth taking seriously. An output can lose the relationship needed for its intended use as identifiers are changed.

The same reasoning limits how far to extend the identifier. Finding an earlier workaround gives a reason to include that interaction and its requester link. It supplies no reason to attach the unrelated renewal conversation from the first example. The buyer should be able to explain the relevant history, rather than treating one necessary cross-case link as an argument for receiving every record about the person.

A different record structure could change the decision again. Suppose the later request already contains a reliable, permitted reference to the earlier case. Following that case reference might retrieve the workaround without a person-wide index. The useful relationship would then be case-to-case. The preparation specification can preserve it directly, provided that doing so answers the task.

This is why a blanket instruction to minimize linkage can be as unhelpful as a blanket instruction to preserve it. The owner and buyer need to identify which relationship carries the answer. Privacy review still applies to the proposed view, but the utility argument has to be tested against the actual question the buyer wants to answer. Counting how many identifiers were changed would not show whether that question remains answerable.

An agreement about identity scope becomes useful when it is attached to a particular prepared copy. Without that connection, one person may review the issue-only view while another exports the issue history plus renewal records. Both may believe they are discussing the cleaned archive.

A short decision record can keep the discussion specific. Use it for the actual view under consideration, with the people responsible for the real decisions. The filled example below continues the fictional independent-issue task; the company, people, records and proposed decisions are invented.

The last row deliberately records an unresolved decision. It is not a fictional privacy approval. For a real collection, record who is responsible, what they decided and the evidence they used, or identify the question they still need answered.

Take the event description in ISSUE-17. If the training task only needs to explain why the reporter checked the fix the next morning, the proposed text could be: “I was unavailable yesterday, so I could not check the fix until this morning.” That keeps the sequence and delay without retaining the named event or session. It is a proposed revision within the invented example. The changed view still needs assessment for its remaining content and connections.

Now apply the same record to the longitudinal workaround task. The task field would name the need to retrieve the requester's earlier instruction. The scope field would include that relevant interaction, and the identity field would retain the common requester reference. The reason for the broader link would be visible to the people preparing and reviewing the copy. A reviewer could assess that decision without confusing it with permission to include unrelated company history.

Access conditions also belong in this discussion. The NIST publication De-Identifying Government Datasets: Techniques and Governance distinguishes public release from controlled ways of sharing data. That choice matters alongside transformations to the records. A known recipient with bounded access and an unrestricted public release expose the copy in different circumstances. The ICO likewise treats access conditions and the possibility of inappropriate sharing as part of the assessment. Neither a recipient's identity nor a technical control makes the retained content irrelevant.

A package fingerprint helps everyone refer to the same bytes. Rightmark's Clean Room pilot describes signed manifests and an offline receipt check for that purpose. A matching fingerprint cannot say whether a contextual clue is acceptable or whether the retained history is necessary. Keep the technical identity of the package and the judgment about its contents connected in the record, without treating them as the same finding.

Rightmark's separately offered de-identification service describes owner review of before-and-after samples and further checks after preparation of the full set. It leaves the legal judgment about anonymity to the owner's counsel with test results in hand. That division gives the owner a concrete review point: what survived preparation, what remains useful, and what evidence supports releasing this copy?

Revisit the decision when the facts it relies on change. Adding a new history source may create connections absent from the reviewed view. A different recipient may have different relevant information or access. Conversely, an unchanged copy under unchanged conditions does not need a newly invented scope decision merely because someone asks for the same file again. Record which earlier reasoning still applies and which change needs examination.

The archive's usefulness sits in its relationships. For an independent-issue task, preserving every person link across the company gives the recipient more than the task requires. For a longitudinal task, cutting the requester link can remove the answer. The stronger specification names the relationship that matters, preserves it in the prepared view and asks for a reason before carrying the rest along.

To discuss the archive you plan to license, start with the buyer's task and the systems that contain the relevant workflow.