January the first was a software decision, not a historical fact

A date that looks precise can be less truthful than a year on its own. In one migration, a source recorded only the year of an item, while the destination expected a full date. Filling the missing day and month with the first day of January would have satisfied the technical requirement. It would also have made the screen imply something the source had never established. I stopped that mapping because the convenience belonged to the software, while the apparent certainty would be inherited by the reader. The distinction is small in a field definition and large in its consequence.

Our review covered eight thousand records with date information. Of those, 2,400 supported an exact date, 3,100 a year and 2,500 a range. The revised programme cost ₹83 lakh and preserved those categories, with the source expression available alongside the structured interpretation. Collection specialists approved the interpretation rules, and product colleagues changed the filtering and display behaviour. We did not discover the missing days or turn ranges into known points in time. We made the product capable of carrying the knowledge the source actually contained, including its limits.

## Keep the source expression beside the interpretation

A structured value is useful because software can sort, filter and compare it. The source expression is useful because it explains what the value is based on. Removing one in favour of the other can leave either a system that is difficult to use or a result that is difficult to trust. I want the relationship between them retained. A later user should be able to see whether a date was transcribed directly, interpreted from a phrase or qualified by a collection specialist. That account gives a future correction somewhere to begin instead of asking the next team to infer how a clean-looking value appeared.

The interpretation itself may be reasonable without being the only possible reading. A source can be ambiguous, and collection practice may change as more material becomes available. That is a reason to record the basis and responsibility for the interpretation, not a reason to avoid structure altogether. Our software supplier role was to make the approved distinction durable across import, search and display. The client remained responsible for the collection's historical judgement. I would not want a developer's need for a sortable value to become an undocumented decision about the date of an item merely because nobody had named the authority required.

It is tempting to put the qualification in a note and let the main date field remain precise. That may help an attentive reader who opens the full record, but it can still mislead search results, exports and later analysis. The system's behaviour needs to reflect the distinction where it matters. If a year-only record appears in a day-level chart as though it occurred on one day, the note has not preserved the meaning for that use. Product teams should examine the paths through which the value travels, rather than assume that one explanatory sentence repairs every downstream inference.

## Make uncertainty usable in the product

Preserving a range creates practical questions. A search for a period may need to include records whose possible dates overlap it, while making clear that the item is not known to fall on a specific day within that period. A year-only value may need a different display from an exact date. Those behaviours should be designed with the collection's users and specialists. The aim is not to burden every screen with a long methodological explanation. It is to avoid presenting the same visual certainty for values that support materially different conclusions, while still allowing people to find the material they need.

The richer model cost more than the original uniform column. It required changes to migration, product behaviour and review. I supported that expenditure because the cheaper route would have transferred the problem to users who might never know there was a problem to examine. A CDO should be able to explain that commercial choice. We were not paying to make the source more complete; we were paying to avoid misrepresenting it. That is a different outcome, and the programme account should say so rather than claim that uncertainty had been eliminated by a technical improvement.

There are also limits to what the software can resolve. If the source does not establish a date and the collection owner has no further evidence, a more elaborate model will not create knowledge. The product can preserve the uncertainty, explain an interpretation and support a later update. It should not encourage staff to enter an invented value simply because a dashboard rewards filled fields. I want operational measures to distinguish absent work from legitimately incomplete evidence. Otherwise a team may improve its completion rate by making the collection less faithful to the material it is supposed to describe.

## Ask what completeness is actually measuring

A completeness percentage is meaningful only in relation to a defined requirement. Some fields may be essential for a workflow; others may not be knowable for every record. Treating all blanks as equal can obscure both real omissions and honest uncertainty. In our migration, the useful question was whether the available date information had been represented accurately, not whether every record had acquired a day and month. That required a review of meaning as well as a technical validation. The same principle can apply elsewhere, but the required distinctions should come from the particular service and source rather than a generic preference for more fields.

Later reuse makes this especially important. A dataset prepared for discovery may be exported into research, reporting or a different product whose users assume a stronger interpretation. The source expression and precision category help the receiving team understand what it can responsibly infer. They do not remove the need to assess suitability for the new use. I would ask the team to explain which assumptions travel with the data and which need renewed review. A successful transfer is more than a file that loads; it is a transfer that does not quietly turn a qualified statement into an unconditional one.

At board level, the relevant issue is the reliability of the company's service claim. Directors can ask whether a reported data-quality improvement reflects more accurate evidence or merely a convention that makes the system easier to operate. They should understand the consequence of a misleading representation and whether management has assigned the right authority to resolve it. They do not need to choose a date format. Their oversight becomes useful when it connects the technical simplification with the obligation to the user and asks whether the product's apparent confidence is supported by the material behind it.

The correction I value most in this case was conceptual. We stopped treating a year as an unfinished exact date and let it remain the kind of knowledge it was. The product became more useful because it could express that distinction, not because it made every record look alike. I would bring the same question to the next modelling discussion: what will a reader believe when this value appears, and does the source support that belief? If the answer is uncertain, the design should make room for that uncertainty before a convenient default becomes a fact nobody remembers inventing.