Anamika VeqzariChief Data Officer · Essays & perspective

Chief Data Officer India

What the evidence allowed us to claim

Wind-service enterprise
420 staff
₹184 crore FY26 company revenue
Evidence and analytics
47 data staff
Four heads; ₹9.3 crore FY27 function expense
Reliability and data leadership
27 years
July 1999 entry; CDO since January 2022

Decisions & consequences

01

Withdrawing a prediction score built with later repair knowledge

In 2022 I endorsed a proposed predictive-maintenance validation based on 1,200 labelled component episodes. Nine hundred records were used for development and three hundred for testing. The reported test score was 91%, and the programme sponsor wanted to use it to support a ₹2.8 crore rollout proposal. I had checked that the groups were separate. I had not checked whether every input would have existed when the proposed warning was supposed to be issued.

Ritu Nezvethi questioned repair-closure fields in the analytical extract. Those fields were completed after the event being predicted. Their presence made the historical records convenient to analyse but supplied knowledge a future operating system would not have had. The sponsor argued that the model had still been tested on separate episodes and that we could remove the obvious closure fields during implementation. I accepted that the work might contain a useful idea. I rejected treating its existing score as evidence for the revised task. Removing an input changes what is being evaluated; it does not retrospectively validate the earlier result.

I withdrew my endorsement and authorised ₹67 lakh of reconstruction. We specified the intended prediction cutoff, traced the availability of each proposed input and retained unresolved timing questions explicitly. Evaluation would need appropriate separation of histories and a genuinely later assessment before a rollout recommendation returned. We did not publish an invented replacement score or claim that a particular split alone solved every form of leakage. Engineering, safety and service owners remained responsible for the consequences of any eventual use. The company held the ₹2.8 crore proposal rather than convert a corrected data specification into operating approval.

The ₹67 lakh was an incurred cost, and the proposed rollout remained an unapproved commitment rather than money recovered. My mistake was approving a performance interpretation before examining the temporal meaning of its inputs. I would require that examination at the design stage in another programme, with the actual decision moment written down before a score is produced. The result here was a withdrawn claim and a better-defined evaluation task. It was not proof that the underlying method could never work, nor evidence that the company had already reduced failures by correcting the study.

02

Retaining components whose failure time had not been observed

A 2023 reliability review brought together 360 component histories. Fifty-four had a recorded first failure under the study definition. Another 246 remained under observation without that event at the common cutoff, and sixty had left the service record earlier for documented reasons. A proposed management summary averaged the fifty-four observed failure times and described the result as the fleet's expected life. The completed events were available and easy to explain, but they did not represent all the histories we had assembled.

The service-planning sponsor wanted a single lifetime assumption for a commercial discussion. I understood the need to plan resources, yet the proposed calculation discarded the exposure of components that had not failed during observation. Treating the other 306 as permanently failure-free would have been equally unsupported. The sixty earlier departures also required attention: a contract ending and a unit withdrawn because of condition could have different implications for whether censoring assumptions were credible. A neat status code could not settle that question by itself.

We spent ₹49 lakh reconstructing observation starts, last-seen dates, event definitions and reasons for departure. The review preserved all three populations and asked qualified reliability colleagues to determine which analyses the resulting histories could support. We did not supply a new fleet-life number in this case. The scope of their eventual method would need to match the actual follow-up and its limitations, including whether departure was related to the risk under study. Commercial and engineering owners retained decisions about pricing, maintenance and physical condition.

The consequence was a delayed single-number presentation and a more complete evidence account. No additional component life was created by keeping a censored record, and the review did not establish a change in failure frequency. The fifty-four failures remained real events to investigate; retaining the other histories did not dilute their operational importance. I would agree the observation design before commissioning the next study, so that data collection follows the question rather than forcing the question to fit whichever records happen to be complete. A responsible summary should explain how much of a component's history was actually seen before it suggests how long such components will last.

03

Rebuilding component history when a location label stayed unchanged

In 2024 we reviewed 240 recorded component changes across a defined set of customer turbine positions. One inherited analytical table used the position identifier as though it described a continuous physical component. After a replacement, older events could therefore appear beside the newly installed unit without a clear boundary. The position was the same, but the object occupying it was different. A component moved to another position could create the opposite problem: one physical history appeared to become two unrelated records.

The first review found 186 changes with clear serial and date evidence and fifty-four with ambiguous attribution. Field-service colleagues wanted the full site history to remain visible, including records that could not yet be matched precisely. The analytical delivery lead wanted a completed component table for the next comparison. Ritu supported preserving both needs without pretending they were identical. We could retain an event at its known site while withholding an unsupported assertion about which physical component it belonged to.

I funded ₹73 lakh of reconstruction using installation records, serial evidence and dated work orders. Forty-one of the fifty-four ambiguous changes were resolved; thirteen remained unresolved for component-specific comparison. We separated the stable position record from component identities and retained their dated relationships. The thirteen cases did not disappear from the site account. Their limited attribution was visible, and they were excluded from comparisons that required a reliable component history. Engineering and service owners retained inspection and return-to-service authority; a corrected identity link was not a certificate of physical condition.

The result was 227 changes with supported attribution and thirteen explicitly unfinished cases. That count described this reviewed population, not universal catalogue accuracy or a reduction in equipment failures. We accepted continuing work and a less complete analytical comparison instead of inserting a convenient match. I would specify identity and replacement-history requirements when a service dataset first enters the company. The case changed the question I ask of a stable identifier: does it follow the location, the assembly or the particular component whose behaviour we want to understand? Until that is clear, a continuous-looking line of events can tell a misleading story about the equipment.

04

Putting the false-alert queue beside the accuracy claim

A separate 2025 retrospective evaluation examined 10,000 nonoverlapping component assessment episodes, each with the same defined future observation window and a reviewed outcome. One hundred episodes contained the specified event and 9,900 did not. The candidate produced 600 alerts: eighty corresponded to confirmed events and 520 did not. Of 9,400 episodes without an alert, twenty contained events and 9,380 did not. The resulting overall accuracy was 94.6%, but that headline did not explain the work the proposed system would create.

The programme sponsor wanted to present the high percentage as evidence that a broad release was ready. Service colleagues asked who would investigate the 520 false alerts and how the twenty missed events would be treated. The alert precision was eighty out of six hundred, approximately 13.3%, while recall was eighty out of one hundred, or 80%. Those figures described this reviewed set. They did not establish performance at other sites, future operating conditions or a different event prevalence. Even an always-no-alert rule would have achieved 99% accuracy here while missing every event, which showed why accuracy alone could not decide the matter.

We spent ₹56 lakh on the evaluation and its review. I recommended keeping the candidate in a bounded shadow study while engineering and service owners examined follow-up capacity, the event definition, missed-event consequences and the design of a prospective assessment. The shadow output did not issue automatic maintenance instructions or replace existing inspection and safety arrangements. We also retained the limits of retrospective outcome confirmation; a classification table is only as credible as the way its episodes and outcomes were established.

The outcome was a more explicit evaluation question and no broad operating release on the strength of one metric. We did not claim avoided downtime, fewer failures or a positive financial return. The cost had been incurred even though the release argument changed. Next time I would ask the service owners to help define the decision criteria before the first performance presentation. A data leader should make both the alert burden and the misses discussable, rather than allow the large number of correctly unflagged episodes to stand in for an operational case that has not yet been made.

Discuss a leadership challenge