A fine line between data cleansing and data laundering

The principle of faithful exhibit capture – and why correcting the input is the wrong answer

Originally written November 2024 · Published here 2 August 2026

The PhD photograph used in a previous post to explain the concepts of exhibit, occurrence, and entity illustrates another principle equally well.

The photo contains a painting on the wall in the background. Its subject's face might be incorrectly recognised as a fifth person by face-recognition software. Would the job of the domain responsible for matching and clustering faces get easier if we erased the painting from the photo before handing it to them?

The answer is yes – but it is the wrong question to ask. It is forbidden to tamper with the evidence. Exhibits that have been tampered with are no longer admissible.

Data cleansing vs. data laundering

Many misspellings of place names appear in the affiliations submitted with scientific articles. New technology makes correcting them easier than ever. It is tempting to normalise "Massachsetts" to "Massachusetts" in the incoming record. But our job is to record it with the precise spelling error – and then match and cluster correctly regardless. Correcting the input data changes data cleansing into data laundering.

Similarly: Burma was renamed Myanmar in 1989. It is tempting to update the name in every old article. But an article written when it was still called Burma will always be written in Burma. Our job is to record it faithfully and map it to Myanmar correctly – but not by changing the input.

Where to fix things

Creating a clear wall between what happens on input (the exhibit store) and on output (the context views) is one of the pillars of the data strategy.

Consider the "Massachusetts" example. Is it a better customer experience to see the name spelled correctly on an article page? No, actually, it is not. Customers trust the data because we make it clear what came from the original publisher. Any time we interfere with the data in an opaque way we create room for mistrust, because the user does not know where else we might be interfering.

What is good is to link the affiliation to the correct target regardless – and even to make it visually clear that according to us the situation is different from what the publisher stated. We provide provenance clues: we state that the painting is being ignored, rather than simply removing it from the photograph.

In the same way, Myanmar should get all the attribution it deserves – including all articles written in Burma. But that attribution must be applied in the output data product, not by altering the input. The person responsible for the Country/Region entity must ensure that articles attributed to Burma map correctly to Myanmar today.

Why this principle is hard to maintain

The problem is that data laundering ostensibly eliminates the problem: the data now appears correct. This means there is no burning platform for the downstream people to act correctly. It also means that input data product owners are put in a difficult position: they do not want to be seen as going against the customer.

On top of this, even if downstream teams would want to act correctly, prioritisation processes may not guarantee that the right fix makes the cut.

The "don't remove the painting" strategy is not something for the distant future. It is the data strategy valid today. Only by holding on to it, and by fixing things at the right place, can a data platform remain trustworthy over the long term.