A precise calculation can still make the wrong decision

## Ask what the arithmetic is authorised to represent

When a calculation produces an unexpected result, engineers reasonably examine precision, data types and input quality. Those are necessary questions. They are not the only questions. The operation can be implemented precisely and still apply the wrong sequence for the business instruction. Rounding each line before addition and rounding the total afterwards are different rules. The fact that one is easier to implement in a shared component does not give a software supplier authority to choose it for every client. The missing conversation is often about ownership rather than arithmetic.

Our fictional review made that visible with three synthetic line amounts of 12.345. Under the stated half-up convention at two decimal places, rounding each line first gives three amounts of 12.35 and a total of 37.05. Adding first gives 37.035, which becomes 37.04 under the same convention. Neither result requires a floating-point error to explain it. The difference comes from the stage at which the instruction is applied. A demonstration that checks only the final display can miss the decision already made earlier in the sequence.

I had approved a shared component without asking enough about that stage. Thirty-seven of 500 synthetic fixtures disagreed with the approved result map. It would have been tempting to call the difference immaterial because the illustrative discrepancy was small. That would have introduced another decision we were not authorised to make. The appropriate client owners needed to confirm the required rule and its significance. Engineering needed to show how the implementation followed it. The small example was valuable precisely because it made the hidden choice easy to inspect without a large technical explanation.

This distinction matters in leadership communication. A CTO can explain a calculation without presenting herself as the owner of insurance pricing or accounting policy. The board should hear who approves the rule, how it becomes an implementation and how a disagreement returns to the responsible person. It should not have to infer those relationships from the name of a library or a claim about accuracy. A precise account of authority is part of the technical account because it determines what the software is supposed to do.

## Keep useful reuse without erasing a required difference

Shared components have real value. They reduce repeated work, concentrate maintenance and make a correction available across several implementations. The answer to one missing distinction is not automatically to create a separate codebase for every client. That could make future changes harder to review and increase the number of places in which a rule might drift. The design question is which differences belong in the contract of the component and how those differences are approved, represented and tested. Reuse should simplify implementation while preserving the meaning that requires variation.

We spent ₹54 lakh on the fictional correction and accepted ₹12 lakh of continuing annual support expense. Part of that cost came from making the supported variations explicit. A single path would have been easier to describe. The revised component needed a clear account of the sequence, retained intermediate values and examples for each approved arrangement. Those are operating commitments as well as design choices. Someone must know which configuration applies, how an amendment is authorised and how an older result can be explained after a rule changes.

The commercial discussion should include that continuing work. A proposal that counts only the initial development can make explicit variation look unnecessarily expensive compared with an abstraction that silently assumes all clients mean the same thing. The comparison is incomplete. The cheaper design has omitted a responsibility rather than demonstrated that the responsibility has no cost. Directors do not need to inspect every calculation path, but they should be able to ask whether the shared service has a credible way to preserve differences it is contractually expected to support.

There is also a discipline in saying what the component does not decide. It can execute an approved sequence and produce evidence about the result. It does not independently establish that the approved business rule is suitable in every legal, actuarial or commercial context. Those judgements belong to qualified and authorised client owners. Keeping that boundary visible does not diminish engineering responsibility. It makes the engineering promise specific enough to test and prevents an implementation choice from becoming an unacknowledged professional judgement by the supplier.

## Describe acceptance at the level the evidence supports

After the correction, all 500 synthetic fixtures matched the specified result map. That is a useful result, but its language matters. The fixtures were constructed examples. They did not establish that actual policyholders had been charged incorrectly, that a particular refund was due or that every calculation in every client system had been examined. Expanding the conclusion beyond the test population would make the account sound more consequential while making it less defensible. Leadership should resist that temptation even when the narrower result requires another sentence to explain.

An acceptance record should retain the original disagreement as well as the final pass. Otherwise the programme can become a story about a successful upgrade and lose the reason the upgrade was necessary. In our case, the 37 disagreements showed that the original abstraction had removed a required distinction. The later pass showed that the specified map was implemented for the tested fixtures. Together they explain both the decision and the boundary of the evidence. Neither should be used as a substitute for a client owner's approval of the underlying rule.

For a board, I would translate this into three practical lines of enquiry. Which business distinctions has the proposed common service assumed away? Who has authority to accept those assumptions? What evidence would expose a disagreement before the result is relied upon? These questions can be asked without prescribing the programming language or reviewing individual formulas. They connect the investment to the service promise. They also make it easier to understand why a small numerical example can justify a material engineering correction without becoming a claim about an unobserved customer loss.

The lasting change in my own practice is to ask for an example where two apparently reasonable implementations differ. A proposal is often most revealing at that boundary. If the team can explain which answer is authorised and why, it is more likely to have understood the business instruction rather than merely reproduced its most familiar case. Precision remains necessary, but precision alone cannot establish that the operation was the one we were asked to perform. A credible supplier knows the difference and makes it visible before presenting the result as complete.