A number can appear reassuring because it is precise. It has digits, a place in a record and perhaps a consistent format. None of those qualities establishes what it measures. In a 2023 integration review, we examined 360 synthetic property records. Three hundred and thirty-six supplied an explicit area unit; twenty-four did not. The processing path quietly treated the missing unit as square metres. That convention allowed every record to continue, but it changed an absence of information into an assertion about the property. Engineering had supplied a fact that the source had not provided.
A populated field can still be incomplete
The immediate appeal of the default was understandable. Most of the integration examples used a familiar unit, and a missing value interrupted work that teams wanted to complete. The implementation looked consistent and avoided a visible exception. A reviewer watching only the successful passage of records could conclude that the service was robust. Yet the robustness came partly from answering a question without sufficient authority. The system did not know that the twenty-four records used square metres. It knew only that an explicit unit was absent and that its code contained a convenient way to proceed.
The integration lead proposed keeping the convention and documenting it more clearly. Documentation would have made the assumption easier to find, which was an improvement over silence. It would not have established that the assumption was correct for the record being processed. A technical specification can accurately describe a decision the team should not be making. I therefore asked us to retain the unresolved state and seek clarification from the responsible source owner. The relevant question was not whether engineers agreed on a default, but who could supply the measurement meaning that the workflow needed.
We introduced explicit unit references and a route for authorised clarification. Where conversion was appropriate, the starting unit and handling rule had to be known. The system could not infer them from the size of the number or from what seemed plausible for the type of property. Such guesses can be persuasive precisely because they often produce reasonable-looking results. Plausibility is useful for identifying a question, but it is not the same as evidence that answers it. The design needed to make the missing qualifier visible to somebody who could resolve it responsibly.
Clarification has an operating cost
The programme took six weeks and cost ₹76 lakh. Reviewing the same 360 synthetic records after the change produced 350 resolved unit accounts and ten still pending clarification. Those ten stayed in the reported population. We did not count them as resolved because they had entered a managed queue, nor remove them so that the remaining records could be described as a perfect result. Detecting an unresolved case is useful progress, but it is different from completing it. The receiving process needed to know both what had improved and what still required another step.
There was a practical price for the more honest design. Some records stopped where they had previously moved immediately. Colleagues needed an explanation of the missing field, an appropriate route to the source and a way to understand the effect on their work. A visible unresolved state can be a poor service if nobody owns the next action. The engineering correction therefore had to connect with operating responsibility. It was not enough to replace a silent assumption with an obscure error that simply transferred the problem to a person less able to investigate it.
The exercise also needed limits in the public account. We used synthetic records to examine integration behaviour. The finding did not establish that actual policies had been mispriced, properties underinsured or coverage decisions invalidated. Those would require different evidence and professional judgement. It would have made the case sound more dramatic to imply customer harm, but it would also have made it less accurate. The leadership decision was already consequential: spend money and accept interrupted processing rather than let a convenient technical rule claim knowledge it did not possess.
This is why I distinguish representation from authority. A system may represent an area, a date, a status or a sequence. The format tells us how the value is stored and manipulated. Authority concerns why that value should be relied on for the decision at hand. The two are connected but not interchangeable. A perfectly formatted area without a unit may be incomplete. A sortable timestamp may not establish causal order across systems. A populated status may reflect a processing step rather than permission for an insurance action. Better formatting alone does not resolve those questions.
Defaults still have legitimate uses. An agreed display preference or an explicitly authorised convention can reduce unnecessary repetition. The problem is not that every default is suspect. It is that the design must distinguish a preference the system may choose from a fact whose meaning belongs to another owner. That distinction should be discussed using difficult examples, including missing, conflicting and unusual inputs. If the only examples in the design review are complete and typical, the team may never confront the point where a convenience becomes an unsupported decision.
The insurance context makes that boundary concrete. A platform may carry property measurements into a workflow without possessing authority to decide coverage or pricing. Engineers need to understand enough of the professional context to avoid erasing a meaningful distinction, while recognising where their own mandate ends. The appropriate specialists must define how the measurement participates in the decision. Technology should preserve that account and identify when the required inputs are absent. It should not make the uncertainty disappear merely because the next component expects a number in a particular field.
Preserve the question until its owner can answer
For leadership, the difficult moment is often the request to accept visible incompleteness. A report with ten unresolved records can look worse than one in which every field is populated. The second report may nevertheless contain less knowledge. I want teams to be able to explain why a smaller set of defensible answers is better than a larger set padded with assumptions, while also being accountable for the effort needed to resolve the remainder. Honesty about uncertainty should not become an excuse for indefinite delay. It should establish the next owner, question and decision more clearly.
I would start the next integration discussion with the missing-unit example rather than save it for acceptance testing. That would let the source and receiving teams agree what happens when the field is incomplete before delivery expectations depend on silent completion. It would also make the operating cost of clarification part of the original design. The lesson I carry is that a missing qualifier can be central to the decision, even when it occupies very little space in the record. Leaving that question visible until its owner can answer is an engineering responsibility, not a failure to make the screen look finished.