A matching description is an invitation to look closer

The word duplicate can make a complicated decision sound mechanical. Two descriptions look alike, so one appears unnecessary. In a collection, however, similar language may describe separate copies, related items or repeated forms. Even where two entries do refer to the same item, their identifiers and descriptive histories may remain useful. I treat a match as a proposal to examine a relationship. That approach allows software to reduce the effort of finding relevant questions without giving it an authority that belongs to the collection owner and the specialists who understand the material.

In one Nerzhavi exercise, a similarity process examined 27,000 descriptions and produced eight hundred candidate pairs. Specialists accepted 210 as duplicates and retained 590 as distinct. We funded ₹54 lakh of review workflow and provenance-preserving linkage. The accepted relationships became linked groups, with original identifiers and history still accessible. We did not report 210 deleted records or claim that every duplicate had been found. The result was a set of examined relationships and a way for users to navigate them without losing the account of how the collection had been described.

## Define the relationship before counting the result

A candidate pair is a unit of review, not automatically a pair of interchangeable records. The first question is what relationship the process is proposing and what evidence would support it. A shared title or similar wording can be useful, but the collection may require context about the item, its copy, its origin or its place in a series. I want the review criteria stated before the team celebrates the number of matches. Otherwise a high match count can reward a broad suggestion process whose output still needs substantial interpretation, while being presented as completed consolidation work.

Our specialists retained 590 pairs as distinct for reasons that mattered to the collection. Those decisions were not simply failures of the tool. A useful suggestion process may deliberately favour finding possible relationships, provided the business understands the review work that follows. The problem is to market that suggestion stage as an automatic decision. I would rather know how the process helps a specialist examine the material than assign it a success percentage detached from its purpose. The review account should explain what was accepted, what was rejected and what remained outside the exercise, using units that do not change halfway through the report.

Pair counts also need care. If several descriptions are related, individual pairs can overlap. Accepting 210 pairs does not establish that 210 distinct records can be removed. In our case, deletion was not the approved action at all. The programme created linked groups while retaining the originals. I made that explicit because a numerical summary could otherwise imply a stronger result than the workflow produced. A data leader should be willing to explain the arithmetic in plain language, especially when a seemingly small ambiguity changes the claimed outcome from reviewed relationships into destroyed or consolidated records.

## Preserve the path back to the original record

Provenance is useful when a later reader needs to understand where a description came from and how it changed. A link can make related entries easier to navigate while leaving that history available. If the system instead removes one side, a later correction may become difficult or impossible without a separate reconstruction. I wanted the product to preserve identifiers, descriptive history and the responsible review decision. That did not mean displaying every detail on the first search screen. It meant retaining a reliable route from a simplified presentation to the evidence and judgement behind it.

The collection owner remained responsible for the relationship decision. Product colleagues made the workflow usable, and the data team helped ensure that the representation carried the approved meaning. This division was important when reviewers disagreed or found a case the initial criteria had not anticipated. The software needed a way to leave a relationship unresolved rather than force a binary answer for the convenience of a completion report. An unresolved case may require additional research, a different category or simply acceptance that the available evidence does not support the proposed connection. The system should make that state understandable rather than conceal it as unfinished administration.

Reversibility also deserves attention. A later specialist may discover that two entries were linked too confidently or that a relationship has a more specific meaning. The process should allow a correction with its history intact. I do not regard that as an admission that the original review was careless; collections can acquire new evidence. The relevant question is whether the original decision was reasonable on the material then available and whether the product can accommodate a better account later. Preserving provenance supports that learning, while irreversible simplification can turn an ordinary correction into a dispute about missing evidence.

## Measure the work the method actually performs

The programme's immediate output was not a smaller catalogue. It was a reviewed relationship set and a product route that preserved the original records. A later evaluation could examine whether users navigated the collection more effectively and how much specialist effort the suggestion process saved or added. Those outcomes would need their own evidence. I did not infer them from the candidate count. A tool can produce many suggestions and still make the review harder if the reasons are opaque or the workflow is awkward. Conversely, a modest set of well-explained candidates may be valuable even when many are correctly rejected.

We retained the scope of the 27,000-description exercise rather than generalise to every future collection. A different catalogue may use language differently, include other item types or have a different history of duplication. The method and review criteria may need adaptation. That is not a reason to discard what the team learned. It is a reason to preserve the conditions under which it was useful, so the next project can decide which parts transfer. I want the product story to make those conditions inspectable instead of suggesting that the software has learned a universal definition of sameness.

For directors overseeing a material data programme, the useful questions concern authority, consequence and the truth of the reported outcome. What is being suggested, who decides, and what happens to the original record? Can the company reverse a mistake, and does the benefit claim use the same unit as the work completed? Directors need not adjudicate individual catalogue pairs. They should ensure that management has not allowed an apparently technical clean-up to make a consequential decision without the required expertise, or reported a volume measure as though it demonstrated an improvement that nobody has yet examined.

The lesson I carry forward is to be precise about what matching does. It can help people discover a relationship worth reviewing. It can support a navigable collection when the reviewed decision is represented carefully. It cannot make the original history irrelevant merely because two descriptions resemble one another. In our case, keeping 590 pairs distinct was as much part of the result as linking the 210 accepted pairs. A useful system respects both outcomes and leaves the next reader able to understand why the collection looks the way it does, including the possibility that a later examination will improve the account.