## An accurate field can still be unavailable
The completion code was a real field in the operational record. It was not invented, corrupted or carelessly entered. The problem was when it became available. Our proposed model was intended to assist a decision at booking time, while the code was created after the journey. Including it in a retrospective dataset allowed the model to use knowledge that the booking process could not yet possess. A strong-looking result therefore answered a different question from the one behind the proposed rollout. In 2022 I stopped that rollout and withdrew the performance claim.
The mistake is easy to misunderstand if data quality is discussed only as correctness. A field can be correct in the historical record and unsuitable as an input to a decision made earlier. The completed record contains the whole sequence as it is known later. A booking-time process has only the portion available then. If an evaluation ignores that difference, it can describe a capability the real process would never have. The problem is not resolved by pointing to the accuracy of the stored value or the apparent strength of the model result.
The project team proposed removing the completion code and keeping the planned launch date. That response addressed the most visible defect, but left another question unanswered: how did the revised model perform using only evidence available at booking? We did not yet have a valid answer. Deleting a field changes the model's evidence and may change its usefulness. It cannot preserve the authority of a performance claim produced with that field included. I wanted a fresh evaluation before a revised claim, even though that meant giving up the immediate rollout.
We had already spent ₹44 lakh. I retained that cost in the account rather than portray the discovery as a recovered investment. The project might still yield useful learning or support later work, but neither possibility made the earlier expenditure disappear. Nor did identifying the problem prove that a future model would create a benefit larger than the cost. The immediate outcome was narrower: an unsupported performance claim was withdrawn and an operational deployment was stopped while its basis was reconsidered.
## The intended decision belongs inside the evaluation
I found it helpful to describe the intended decision without beginning with the model. What would the booking colleague know at that moment? Which records would exist, and which would be added later? What was the proposed output supposed to help them decide? These questions made the timing problem visible to people who did not need to inspect the modelling method themselves. They also kept the discussion connected to the practical use rather than treating a retrospective score as an achievement detached from the service process.
This was operational forecasting within planned non-emergency transport. It was not a model for clinical suitability, diagnosis or treatment. That boundary matters because the setting can encourage a reader to infer a medical purpose from an analytical project. Qualified care teams retained decisions about whether a passenger could appropriately use the service. My data function could examine operational evidence without acquiring that professional authority. A model's intended use must be bounded both in time and in the kind of decision it is allowed to support.
The revised review made availability explicit for each proposed input. A column name alone could not settle the question. The team needed to understand how and when the field entered the process, including whether later updates changed what appeared in a historical extract. This was not an argument for discarding all completed records. Those records remained useful for understanding past activity. It was an argument for reconstructing the evidence appropriate to the earlier decision before using a retrospective result to justify a prospective claim.
I also needed to avoid overcorrecting the conclusion. The faulty evaluation did not prove that operational prediction was impossible or that every part of the dataset was unusable. It showed that this particular performance claim could not support this proposed use. A narrower conclusion kept the team able to learn without defending the indefensible. It also prevented the organisation from moving from excessive confidence to an equally unsupported rejection of all future work. The next version would earn its standing through evidence of its own.
## Withdrawal leaves expenditure and uncertainty visible
The leadership trade-off was between a clear launch commitment and an unresolved evaluation. Delaying a project can appear to be indecision when a schedule has become the most concrete object in the room. But continuing would not have resolved the missing evidence; it would have carried the uncertainty into operations while retaining a claim that no longer held. I preferred to make the uncertainty visible at the point of decision. The operating team deserved to know what had been established before being asked to depend on the output.
There was a communication task as well. A withdrawn claim should not remain in a presentation as an informal indication of what the revised model might achieve. Once the evaluation changed, the old result could describe the earlier flawed exercise, but not lend authority to the next one. That distinction is especially important when colleagues remember the strongest number and forget the conditions attached to it. I wanted the record of the project to preserve the reason for withdrawal so that optimism could not quietly restore the unsupported claim later.
For directors considering an analytical investment, the useful question is whether the evidence reproduces the circumstances of the intended decision closely enough to support the claim. They do not need to choose every modelling technique to ask that question. Management and the relevant specialists should be able to explain the input timing, the decision boundary and what remains uncertain. A confident description of technical sophistication cannot replace that account. Oversight becomes more useful when it connects the analytical result with the responsibility the enterprise is being asked to accept.
The evaluation also needed an owner for explaining changes. When an input is removed, the operating sponsor should hear what has become uncertain, not merely receive a revised version number. That conversation connects the analytical repair with the decision to proceed, pause or reconsider the use. It gives colleagues a reason to update their expectations instead of assuming that an invisible technical adjustment leaves the original promise intact. In our case, keeping that connection clear was part of withdrawing the claim responsibly.
I now treat the time of knowledge as part of the evidence itself. A field does not carry the same decision value at every point in a process simply because it exists in the final database. The completion code taught us that lesson at a cost and with a missed rollout. The response was to withdraw a claim, examine the intended use and start the revised evaluation honestly. A later model might prove worthwhile, but its value would have to be demonstrated using what could actually be known when the decision was made.