A device can be accurate about what it observes while the system built around it is wrong about what the business did. In our hospital-linen service, a doorway reader produced 3,600 events for 2,400 distinct tags in a reviewed sample. The additional 1,200 were repeat observations. The integration had treated each read as another wash cycle. Nothing in the fact that the reader saw a tag again established that the article had completed another laundering process. The digital history was accumulating a meaning that the source observation did not contain.
The issue reached an operating discussion through a ₹18 lakh replacement proposal. Colleagues wanted to understand whether the proposed replacement need reflected physical use or the way the software counted messages. That was the right question. It would have been possible to defend the reader's accuracy, the completeness of the message log or the arithmetic used to update the counter. All could be true while the resulting usage interpretation remained unsupported. I asked the team to separate the raw observation from the process event before trying to improve the report based on it.
Name the observation before using it as an event
A reader message tells us something within the scope of the device and its configuration. It may establish that a tag was observed at a location and time. It does not automatically establish every business event associated with that location. An article can remain in range, move back through the doorway or be observed repeatedly during one movement. The operating model must decide which evidence supports a completed process. That decision requires people who understand the physical route, rather than an assumption that one message is a convenient unit of use because the software receives messages one at a time.
The sample arithmetic was simple: 3,600 events, 2,400 distinct tags and 1,200 repeat observations. The repeats were not 1,200 missing articles, nor did the distinct-tag count itself prove that 2,400 washes had been completed. It identified the population observed in that sample. I wanted the team to resist replacing one unsupported interpretation with another. Removing duplicate reads can improve the event stream while leaving the actual process definition unresolved. A clean set of tag observations still needs to be connected with the evidence and conditions that the business uses to recognise a completed operation.
That is why an arbitrary time window was not enough as the full answer. Suppressing repeated messages received close together might be technically useful, but it would not by itself establish when one wash ended and another began. The correct model depends on the operating sequence and the available evidence. We worked with process owners to define that relationship. IT could implement and test it, explain the limits and retain the raw observations needed for investigation. It could not simply choose a convenient interval and thereby acquire authority to define the physical work for the people responsible for it.
A correction does not decide the article's remaining life
We withdrew the ₹18 lakh replacement proposal pending a valid usage basis and spent ₹29 lakh on integration redesign. Those figures should remain separate. The withdrawn proposal was not cash recovered, and it was not proof that replacement would never be needed. Correcting an inflated usage count changed the evidence available to the decision. It did not establish the physical condition of every article or its remaining suitability. Qualified process and operating colleagues still had to make those assessments. The CIO's correction should not be inflated into a claim that the linen could now remain in service without further review.
I also declined to present the two amounts as a simple net benefit. The ₹29 lakh was technology work actually undertaken; the ₹18 lakh was a proposal withdrawn until its basis could be established. They described different things and different stages of commitment. Combining them into one attractive result would repeat the same kind of meaning error that the integration had made. A leadership case needs to retain whether a number is spent, proposed, deferred or still subject to another judgement. The arithmetic between two amounts does not make their commercial status interchangeable.
The reader itself remained useful. The answer was not to discard device observations because one application of them had been wrong. We needed to give those observations a more accurate place in our information environment. They could support movement analysis or help reconstruct an event when combined with other evidence. Their value depended on describing what they established, rather than asking them to prove more. That distinction matters when an organisation has invested in technology and feels pressure to turn every available data stream into a direct performance or replacement decision.
Give the operating owner a place in our event model
The case changed how I involved operating colleagues in integration design. Their role was not merely to confirm that a screen displayed the expected fields after the system was built. They needed to help define the event those fields represented. A system specification should make room for the physical conditions and exceptions that determine whether an observation supports a business conclusion. Where that definition remains uncertain, the uncertainty should be visible before the counter becomes authoritative. It is easier to discuss a missing event definition during design than to explain later why several management decisions relied on a history the device never actually established.
For directors, the useful oversight question is how management knows that its digital evidence represents the business event being claimed. The board does not need to design reader filters or inspect individual messages. It can ask whether usage, completion and availability measures have an operating definition, whether the appropriate owners were involved and how exceptions are handled. It can also ask what decisions will change when an interpretation is corrected. Those questions connect technology expenditure with the enterprise's obligations without turning the board into another systems-development committee.
My conclusion is modest but consequential. In this sample, the reader observed 2,400 distinct tags through 3,600 events. The integration had made those events mean more washes than the observation supported. We withdrew an inadequately supported proposal, paid for redesign and returned the process definition to a joint technical and operating discussion. The profile does not claim that every later usage record became perfect. It shows the leadership work of recognising a boundary between observation and conclusion, then making that boundary explicit enough for the business to use its technology with better judgement.