← All insights
ResearchNovember 2026

A Match Is Not an Identity: Why We Revisited Linkage Risk in PAMOLA

Removing names from a dataset is straightforward. Knowing whether the remaining information can lead back to a person is not. While refining CVPL for PAMOLA.CORE 1.0, we discovered that one familiar-looking risk score was answering the wrong question.

Imagine a hospital sharing records for research. Names and patient numbers have been removed. But age, location, treatment history, and other details remain, because without them the dataset may be of little use.

Could someone combine those details with information from elsewhere and identify a patient? That sounds like one question. It is actually at least three.

What CVPL is. CVPL - Cluster-Vector-Projection Linkage - is PAMOLA’s method for checking whether a protected dataset can still be linked back to the people in the original data. It compares the original and protected versions of a dataset, starting from what an attacker is assumed to know: it narrows the records to plausible candidates, turns them into comparable numeric form, and measures how close each candidate is. The result is not a pass/fail verdict but a risk estimate tied to a declared attack scenario. The method was first described in a research paper published in February 2026.

A plausible match is not a successful identification

Suppose a record has five plausible matches in another dataset. A similarity test may say that a link is possible. But it has not established which, if any, of those five people is the right one.

For privacy decisions, these distinctions matter:

  • Possible linkage: Does at least one candidate satisfy the declared matching rules?
  • Correct identification: If a particular strategy selects a candidate, how often does it select the true person?
  • Closest-match success: When the strategy takes the most similar candidate, how often is that choice correct?

The first measure can be high even when the other two are low. Treating all three as one probability of re-identification can mislead the people deciding whether data may be released.

A link is not an identification

Source record

age 40-49
area 1xx · nurse

Released rows that fit what the attacker knows

five plausible matches - none of them is the real person

1 · Does a plausible link exist?

YES

an existence-only measure reports maximum risk

2 · Picks the right person?

NO

the true match is not among the candidates

3 · Closest = the right one?

NO

similarity is not same-person linkage

CVPL reports the three answers separately, never as one blended score

One source record, five plausible matches in the release - and three different answers. CVPL reports them separately, never as one blended score.

That was the problem we found while reviewing CVPL. Over successive integrations, parts of the original research model had been reduced to a similarity-based proxy. A score intended to describe the existence of plausible links was being interpreted too broadly.

Rather than polish the score and keep its ambiguity, we decided to restore the distinctions in the method itself.

The engineering problem behind a simple-looking number

A credible linkage evaluation needs more than a distance between two rows. It has to state what information an attacker is assumed to know, which records qualify as candidates, how different data types and generalized values are compared, and how a proposed match is judged. In the rebuilt CVPL, those decisions are explicit.

First, the attacker has a defined view. A postcode, an age band, or another quasi-identifier can narrow the candidate pool. Different combinations represent different levels of background knowledge. CVPL can evaluate a declared sequence of these combinations rather than assuming every attacker sees the same information.

Second, similarity and identity are measured separately. When trusted ground truth is available - a protected reference showing which records really belong to the same person - the evaluator can test whether a candidate-selection strategy makes a correct identification. Without that reference, it can still measure plausible linkage, but it cannot honestly report a measured probability of correct identification.

Third, uncertainty stays visible. Some comparisons become ambiguous after generalization or numerical projection. For example, an exact age of 21 may legitimately match an age band of 20-29; a numerical projection can also become unstable. CVPL handles these cases explicitly and, where a definitive result is impossible, reports bounds or a measurement limitation rather than quietly substituting zero risk.

Finally, comparisons must be reproducible. If several protected versions of the same source are assessed, changes in the mathematical representation must not masquerade as changes in privacy. CVPL therefore distinguishes its original joint representation from a fixed representation suitable for comparing releases.

None of this makes the answer magically certain. It makes clear what was tested, what the result means, and where its limits lie.

A consistent method, from the library to the platform

The review uncovered another problem: different implementations of the same research method had gradually drifted apart. Similar-looking metrics did not always mean the same thing. That is a serious weakness when their results inform decisions about sharing sensitive data.

We rebuilt CVPL around a single, openly documented calculation in PAMOLA.CORE 1.0 and use that calculation in PAMOLA’s privacy evaluation workflows. The method can be tested independently, while the platform applies it as part of a wider assessment of a dataset’s privacy risk.

The implementation retains the essential linkage model: declared candidate sets, multiple attacker profiles, separate measures of correct identification when trusted ground truth exists, and explicit treatment of uncertainty. It does not pretend to model every possible attacker or replace a complete privacy assessment.

CVPL is included as an experimental metric in PAMOLA.CORE 1.0. That designation invites scrutiny and real-world evaluation of the method; it does not make its results a universal probability of re-identification.

Better evidence, not an automatic verdict

CVPL evaluates a declared set of attacker profiles under an auditor’s stronger, white-box view of the data. Its reported maximum is the worst observed among those profiles and strategies - not proof that no more capable attacker exists.

CVPL: a white-box, worst-case evaluation

The auditor has access to the ground truth

Source data
Protected release
True correspondenceused only to score

Declared attackers

Profile Aknows exact age and area
random pickclosest match
Profile Bknows age band only
random pickclosest match
Profile Clooser matching
random pickclosest match

× fixed strategies: random pick · closest match

Worst measured outcomeacross declared scenarios

Not an average over attacks · not a match probability · not a bound for any attacker

Uncertain cases are reported as lower-upper bounds · unstable projections are flagged

The auditor sees the source, the release, and the true correspondence. CVPL reports the worst outcome across the declared attacker profiles and strategies - not an average, not a match probability, and not a bound for any attacker.

Nor does CVPL decide on its own whether a dataset is safe to publish. A release decision still depends on the intended use, applicable policy, other privacy tests, and the evidence available.

That separation is the point. A governance decision can be only as dependable as the meaning of the measurements beneath it. A polished dashboard cannot repair a metric that confuses someone might match with someone was correctly identified.

For us, rebuilding CVPL reflects a larger commitment: privacy engineering should produce evidence that can be examined, challenged, and reproduced - not just a reassuring number.

Go deeper: read the CVPL research paper, the CVPL documentation in PAMOLA.CORE, or the PAMOLA.CORE 1.0 release article.