Chief Data Officer / India
What we refused to simplify away
- Records and data work
- 26 years
- Career begins July 2000
- Data colleagues
- 38
- Three functional heads
- Annual operating budget
- ₹9.2 crore
- Separate ₹2.6 crore platform programme
Decisions & consequences
01Correcting reading order without declaring the collection perfect
A 24,000-page collection had passed its file-completeness checks, but reviewers found search extracts that combined text from the wrong parts of a page. I asked the team to inspect a deliberately mixed set of 520 pages, including complex layouts and more straightforward examples. Fifty-two showed reading-order problems. The selection was designed to expose different conditions, not to estimate a representative error rate for all 24,000 pages. That distinction shaped both the response and the language used to report it.
I authorised ₹46 lakh for four weeks of correction and review work within the agreed programme. The team adjusted the affected transformation paths and retained the scan as the reference source. Collection specialists examined the corrected examples and the explanation given to users. We did not overwrite the original material with a cleaned text version or imply that the source itself had changed because the searchable representation was improved.
The commercial team wanted a single quality figure for the completed collection. I declined to infer one from the selected review. We could explain the fifty-two observed problems, the corrections applied and the further review needed for other conditions. That account was less convenient than an overall percentage, but it gave the client a more useful basis for deciding how the searchable text should be used and where the source image remained essential.
The immediate result was a corrected set of known paths and a clearer source-to-text account, not a declaration that every page was free of error. I learned to establish the purpose of a quality sample before the results reach a delivery summary. A diagnostic selection can reveal important faults without supporting an estimate of their prevalence. Keeping those uses distinct helps the company act on the finding without inventing confidence that the review was never designed to provide.
Keeping 590 similar pairs distinct
A similarity process examined 27,000 collection descriptions and produced eight hundred candidate pairs for review. An early efficiency proposal assumed that most could be merged automatically. I asked the collection specialists to assess the relationships first. They accepted 210 pairs as duplicates and retained 590 as distinct, including descriptions whose similar wording reflected different copies, related items or repeated forms. The candidate count was a queue for judgement, not a count of redundant records.
We allocated ₹54 lakh to the review workflow and provenance-preserving links. The accepted relationships were represented as linked groups while original identifiers and descriptive history remained accessible. We did not erase records simply to make the catalogue smaller. Nor did we equate 210 accepted pairs with 210 removed items: pair relationships can overlap, and the approved action concerned linkage rather than destruction.
I worked with product and collection teams to make the decision and its responsible reviewer visible. A later correction needed to be possible without reconstructing a history that the system had discarded. Some colleagues saw this as extra complexity in a feature intended to simplify search. I argued that simplification should help a reader navigate the collection, not remove the evidence needed to understand why two descriptions had been associated.
The outcome was a reviewed set of relationships and a product route that preserved provenance. We did not claim that the exercise identified every duplicate in the collection or established a universal matching accuracy. My lesson was to separate the machine's useful suggestion from the collection owner's authority. A good data product can reduce the effort of finding a question worth asking while still leaving the consequential decision with someone able to interpret the material and account for the result.
Leaving 3,100 years without invented days
During a migration review we examined eight thousand records with date information. The sources supported exact dates for 2,400, years alone for 3,100 and ranges for 2,500. The destination's initial model expected a full date. A proposed conversion filled missing day and month values with the first day of January, which would have made the import technically straightforward while creating a precision the source did not contain. I stopped that mapping before it became the published record.
The revised programme cost ₹83 lakh and retained the source expression alongside structured values that distinguished exact, year-only and ranged information. Product colleagues adjusted filtering and display behaviour so users could see what was known. Collection specialists reviewed how the interpretation related to the original description. We did not decide that a range should be represented by its midpoint or that an unknown day should silently become a convenient sorting value.
The change required more work than a uniform date column, including discussion of how records intersect a search period. I supported that cost because the simpler model would have encouraged readers to treat a technical default as historical evidence. The client collection owner approved the interpretation rules; my team was responsible for making the software carry them consistently and for preserving a route back to the source expression.
The resulting migration kept all three precision categories visible. It did not resolve dates the source could not establish, and we did not describe uncertainty as a defect that the software had eliminated. This case changed how I review completeness claims. A populated field can be less informative than a qualified one if its content is invented. I now ask whether a proposed data-quality improvement adds knowledge, corrects a transcription or merely conceals a limit that a user needs to understand.
Withholding an answer feature after ten unsupported claims
We tested an experimental search-answer feature on 120 questions prepared with collection specialists. Eighty-eight responses were supported by the cited material, twenty-two declined to answer and ten contained claims the cited passage did not substantiate. The fluent wording of those ten responses made the failure especially important. A user might have accepted the answer precisely because it appeared more complete than the source allowed. I recommended withholding the feature from client release.
We committed ₹33 lakh to a twelve-week improvement programme covering passage selection, support review and the conditions for declining a question. The original test results remained in the record. We did not train on client collections beyond the permissions for the agreed experiment or treat access for testing as a right to reuse the material elsewhere. Product and collection colleagues defined the next review, with the client retaining its authority over the collection and its intended use.
The commercial cost was a delayed feature that had attracted interest in demonstrations. I explained that a successful demonstration and an adequate release basis answered different questions. The twenty-two abstentions were not automatically failures; some represented an appropriate response to insufficient evidence. Equally, the eighty-eight supported responses did not cancel the significance of the ten unsupported claims or establish performance outside the recorded question set.
At the time of this profile, the feature remains withheld and the improvement programme is underway. I make no claim that the problem has been solved or that the planned work will make every answer reliable. The decision I can account for is the pause, its reason and the funded next examination. For me, the case shows that a CDO's contribution sometimes consists of keeping an attractive capability out of a product until the company can explain the evidence behind the promise it would make to users.