The decimal was precise; the chosen rule was wrong

Three synthetic line amounts of 12.345 produce 37.05 when each is rounded half-up to two decimal places before addition. Adding first and applying the same rounding to the total produces 37.04. Both calculations can be implemented precisely. Only one matches the rule the authorised client has specified. I had approved a shared calculation component before asking enough about that distinction. The resulting test failure was a reminder that a correct operation is not always the correct business operation.

I am Anjali Zelqethi, CTO of the fictional Qelvazi Insurance Systems in Ranchi, originally from Palakkad. We supply software to 22 insurer clients; we do not underwrite insurance. The company has 260 employees and recorded ₹148 crore revenue for FY ending March 2026. Founders hold 44%, an institutional investor 46% and an employee vehicle 10%. I have no personal holding or statutory seat. My engineering organisation has 57 employees through six leads and eight separately counted contractors, within ₹12.8 crore FY2026–27 operating expense and ₹3.6 crore approved change investment.

Joseph Belzethi leads the company, and Reema Navqeri owns engineering acceptance. Client insurers retain the professional decisions their systems implement. My cases concern the engineering evidence we owe them: a calculation must follow the approved rounding stage, a default must not arrive from another client's configuration, diagnostic traces should not carry unnecessary policy fields, and an older application must be able to interpret records created before a rollback. Each choice has an expense or a limitation that belongs beside the technical result.

Current focus

Keeping shared insurance-software components useful without allowing shared implementation to decide client-specific business rules.

Conversations I welcome

A first external board role where directors want scrutiny of software commitments, engineering evidence and the responsibilities retained by a supplier.