The missing response left the outcome uncertain
In 2018 I approved a purchasing integration that tried again when it did not receive the response to an earlier request. That sounds like a reasonable way to make a process more dependable. It was incomplete. The receiving process treated the repeated submission as a new purchase order, and seventeen duplicates were created. Their combined face value was ₹34 lakh. They were cancelled before goods were supplied against them, while repair and reconciliation cost ₹13 lakh. Those figures describe different consequences and should remain separate.
My mistake was to accept a technical account of persistence without asking enough about the action being persisted. A request could have reached its destination and produced an order even if the response did not reach the caller. From the caller's position, the outcome was uncertain. Uncertainty was not evidence that nothing had happened. When the next attempt arrived, the receiving process needed to understand whether it represented the same intended purchase or a different commercial instruction.
The buyer's intention did not become another intention simply because communication was repeated. Yet the enterprise had allowed that interpretation to become a commitment visible to purchasing and suppliers. The problem crossed the boundary between software behaviour and commercial authority. It was therefore not enough for IT to say that the communication mechanism had behaved as configured. I had approved a design whose business meaning was wrong under a condition it was supposed to handle.
We stopped the affected flow and worked with purchasing to establish which orders reflected intended demand and which had been created by repetition. Purchasing owned the cancellation and supplier communication. My team owned the systems investigation and correction. That division mattered because a technical explanation did not authorise IT to settle every commercial consequence. The people responsible for the commitments needed a record they could examine and act upon.
Similarity cannot decide what the buyer meant
A tempting response would be to reject every request that looked like an earlier one. That would replace one assumption with another. A buyer may legitimately order the same goods twice, for separate needs or under separate approvals. Similar contents do not establish identical intent. Conversely, a repeated attempt to communicate one decision may arrive under conditions that make it appear different to a superficial comparison. The enterprise needs a deliberate account of the action, not a guess based only on its appearance.
That account must be understandable to the process owner. Technical identifiers can help preserve the identity of an intended operation, but their meaning and treatment need to fit the business process. What happens when a caller repeats an uncertain request? How is the earlier disposition found? When does the enterprise regard a new instruction as a new commitment? The implementation may vary. The leadership requirement is that these questions are answered coherently and tested under the conditions that matter.
The review also needs to preserve uncertainty rather than force every event into an immediate success or failure label. A person may need to investigate the disposition before making another commitment. That can feel less convenient than a system that always moves forward. But movement is not automatically progress when it creates another obligation. A clear unresolved state, with responsibility for resolving it, can be more useful than a confident screen whose business meaning is wrong.
I would not ask a board to select an identifier format or prescribe a retry algorithm. I would expect management to explain how a material automated process preserves authority and intent when its normal communication path is interrupted. The board's question concerns the enterprise commitment and the evidence behind its treatment. Qualified technical colleagues should be able to explain the mechanism without implying that the mechanism alone settles the commercial policy.
Review the commitment rather than the message count
The financial account of our incident needed the same discipline. The ₹34 lakh was the face value of duplicate orders cancelled before supply. It was not a realised loss, and cancellation was not a saving of that amount. The ₹13 lakh repair cost was incurred expenditure. Combining those figures into a dramatic success or loss narrative would have made the account less accurate. Directors and colleagues needed to know what had been committed, what had been prevented and what the correction had cost.
I also needed to retain my own approval. It would have been easy to make the story about an integration defect discovered by an attentive team. That would have removed the leadership decision that allowed the defect into use. I had accepted an incomplete assurance. The useful change was not only a corrected process but a different review question: what business action does another attempt represent, and how does the enterprise know whether that action has already occurred?
Testing should make the answer visible. A demonstration in which every response arrives promptly may show the ordinary path while leaving the important uncertainty untouched. The process owner needs to see how the proposed behaviour handles a missing response, an ambiguous disposition and a genuinely new instruction that resembles an earlier one. These are examples of questions to examine, not a complete technical test plan or a universal prescription for every purchasing system.
The correction did not establish that all later integrations would be sound. Each process has its own commitments, authority and consequences. A transfer between records, a stock reservation and a purchase order may share technical patterns without sharing the same business meaning. I want teams to carry the habit of examining intent into the next design, not to assume that one successful repair supplies an answer for every future automation.
There is also a human cost to an unclear automated action. Purchasing colleagues may have to contact suppliers, explain reversals and reconstruct what was intended while normal work continues. Those efforts should not disappear because the duplicate goods were never delivered. A more useful executive account recognises the correction work without inventing an unmeasured reputational loss or claiming that every relationship emerged stronger. The evidence should remain proportionate to what actually happened.
I now judge a dependable transaction process partly by how well it explains uncertainty to the people responsible for the decision. The system should help them distinguish an intended commitment from another attempt to communicate it. It should not create an obligation merely to make a technical sequence look complete. Our seventeen duplicate orders taught me that a successful message can still be the wrong business event, and that the CIO must be prepared to examine the meaning of success before approving more of it.