Time appears to be one of the simplest things for two systems to exchange. A record has a date and an hour, and another application uses them to find the corresponding event. The apparent simplicity can hide the reference that makes the value meaningful. In a 2024 review of our linen-service systems, one source used UTC while the receiving interpretation assumed local Indian time. The difference affected how observations were associated with process runs. The clocks had not changed the physical work; the integration had changed which record appeared to describe it.
We reviewed 64 runs. Fifty-eight were correctly linked and six required manual reconstruction. I wanted the six treated as an information problem still needing resolution, rather than absorbed into a reassuring percentage. David Qervuli's process-assurance team needed evidence attached to the right run before judging what it supported. A technical correction could help restore that association. It could not establish a satisfactory process result by itself, and the fact that most of the reviewed links were correct did not settle the remaining six or every other period outside the sample.
A timestamp needs its reference to remain meaningful
The source value and the receiving assumption had to be examined together. A time recorded in UTC and one interpreted as Indian local time differ by five and a half hours. If the receiving system silently assumes the wrong reference, it can choose the wrong neighbouring event even though the stored characters look valid. Basic format checks will not necessarily detect the meaning error. The integration needs to know what the value represents and preserve that context through the association it creates. A field called time is not enough information if the two systems attach different conventions to it.
The practical consequence depends on how the value is used. A report displaying an hour incorrectly has one kind of problem; a process that uses that hour to attach evidence to a run has another. In our case, the linkage mattered. I asked the team to explain the path from source timestamp to associated run, including where the reference was assumed. That explanation made the repair more precise. We were not merely adjusting a clock label. We were examining a decision already made by software about which observations belonged together and which historical associations needed to be reconstructed.
I did not ask process-assurance colleagues to accept the corrected display as proof that their underlying evidence was complete. Their concern was whether the right records could now be examined for the right run. IT could help recover and organise that information, but the professional judgement remained theirs. That separation prevented the programme from declaring a broad form of completion simply because the technical cause had been identified. Finding the cause is an important step; repairing the affected associations and assessing their meaning are further steps with different owners and evidence requirements.
Repair the association, not only the screen
The initial technical suggestion was to correct the displayed times and close the issue. That would address what a user saw going forward, but it would leave the six historical links insufficiently examined. I asked the team to retain the source records and reconstruct the associations for the reviewed runs. We funded ₹42 lakh of clock-context integration work and made the time reference explicit. The six reconstructed links were then referred to David's team. The case does not state their subsequent process disposition, because the technical record alone does not support that conclusion.
This distinction can be frustrating during a project review. The team has found a clear technical cause, implemented a change and wants to report that the incident is resolved. Another owner still has work to do with the corrected evidence. I want the report to recognise the technical achievement without using it to close someone else's responsibility. A precise completion statement can say which mapping was corrected, which associations were reconstructed and which review remains pending. That gives senior colleagues a usable account of progress without requiring the technology team to claim authority it does not possess.
The ₹42 lakh also belongs with the scope of the work. It was integration expenditure to preserve clock context and address the identified association problem. It was not a price for certifying hygienic suitability or a calculation of avoided clinical harm. Those interpretations would go beyond the case. The business can still decide that the work was necessary and worthwhile without attaching an invented downstream benefit. A CIO should be able to explain why an information defect matters to a decision and what was spent to correct it, while retaining uncertainty about outcomes that were not measured or do not belong to the technical function.
State which completion belongs to IT
I use this example to distinguish several statements that can otherwise become one green status on a programme slide. The integration rule has been corrected. The reviewed historical associations have been reconstructed. The process owner has received the evidence. The process owner has reached a disposition. Those statements are related but not interchangeable. In this case, the first three are described and the last is not asserted. Keeping that boundary makes the status more informative, even if it prevents the team from presenting a simpler account of the overall result.
The same discipline applies to the 58 correctly linked runs. Their place in the reviewed sample is relevant, but it should not be used to imply that all links outside the sample are correct or that all process outcomes were satisfactory. A technical association and a professional assessment answer different questions. When an executive report retains the sample scope and the kind of correctness being claimed, another reader can understand what further evidence might be needed. When it says only that the system passed, the reader has to guess which of several possible meanings management intended.
For a board, the useful question is whether management's completion account identifies the remaining responsibility. Directors should not reconstruct individual timestamps or make process-assurance decisions. They can ask how the integration preserves context, which records were affected and who has reviewed the reconstructed evidence. They can also ask whether the cost and schedule reflect the full repair or only the visible software change. Those questions help the board follow the enterprise consequence while leaving the detailed work with the people qualified and authorised to perform it.
The lesson I take from the case is that context must survive the journey between systems. A timestamp without its reference can look precise while making an incorrect association. Repairing the representation is useful, but the work already built on that representation still needs attention. I want my leadership account to preserve that sequence and its ownership: identify the assumption, repair the linkage, give the evidence to the appropriate reviewer and state honestly what has been completed. A system becomes more trustworthy through those specific distinctions, not through a general assertion that the clocks are now aligned.