The date a system learns something is not the date it applies

## Ask which question the date must answer

A timeline looks authoritative because it puts events in order. The appearance can be misleading when the chosen order answers a different question from the one a colleague is asking. The time a change was recorded may not be the time the approved business change took effect. A late entry, a correction or a future-effective instruction can make those dates diverge. If the system keeps only one convenient view, the user may infer a history that the underlying decision does not support. The difficulty is not solved by displaying a more precise timestamp when the meaning of that timestamp remains unclear.

In the fictional Qorzuni review, 37 of 180 approved changes appeared in the wrong business-time view. Our design favoured the most recently entered record. That approach worked well in the ordinary test sequence, where events arrived in the order in which they applied. It was less useful when the business sequence and the entry sequence differed. I had accepted the simpler design because it reduced implementation complexity. The review showed where that simplicity had gone: it had become interpretive work for the colleague trying to reconstruct the appropriate account, sometimes without enough visible evidence to do so reliably.

The first question was therefore not which database feature to buy. It was which question each task needed the record to answer. A colleague might need to understand the approved state applying to a specified date. Another review might need to establish what the system had recorded at an earlier point. Those are related but different inquiries. We worked with authorised business owners to describe the views and the evidence required. Technology needed that meaning before it could decide how to represent the dates, corrections and source instructions in a way that would support actual work.

Keeping both dates does not mean that every user should receive an unexplained collection of timestamps. More fields can create another kind of confusion if their purpose is unclear. The interface needs labels and views that fit the task, with access to the underlying history when appropriate. I wanted a colleague to know why a late-entered change appeared in a particular account, rather than assume the system had simply sorted it incorrectly. The purpose was a more intelligible history, not a display of technical detail. A useful representation makes the important distinction available without expecting every user to reconstruct the entire data model.

## Preserve the approved decision without creating authority

We funded ₹92 lakh to separate the approved effective date from the recorded date and to support the relevant views. Underwriting and operations owners defined the source instruction and authorisation needed. The technology change did not allow a user to create retrospective cover or alter a contractual consequence simply by selecting another date. That boundary mattered throughout the discussion. A system can represent an authorised decision without acquiring the power to make that decision. If the source or approval is missing, adding a field does not supply it. The process must preserve the distinction between recording a fact and granting permission for it.

Corrections also require a clear account. Replacing an inaccurate record may improve the current view while still leaving a legitimate need to understand what was previously recorded and why it changed. The appropriate treatment depends on the business and its obligations, with professional input where needed. My role was to make sure the technology proposal did not quietly erase the question. We asked how an authorised colleague would follow the correction, locate the source and understand which view was relevant. That work was less visually impressive than the main interface, but it was central to whether the history could be trusted in a difficult case.

The operating team reasonably worried that two dates and more explicit exceptions would make routine work slower. I accepted the concern. A richer record can be poorly designed, and an awkward screen can push people towards private notes that create another history outside the system. We therefore tested the explanation and workflow with the people using it, rather than assume that a technically correct model would automatically produce a usable service. The system needed to show the ordinary view clearly while allowing the relevant distinction to be examined when it mattered. Complexity could be organised; it could not responsibly be declared absent.

The project also required agreement about ownership after release. Technology could maintain the representation and detect missing or inconsistent fields. Authorised business colleagues still had to establish the underlying decision and resolve questions about its meaning. Support needed to know which owner to involve rather than repair a display by changing a business date on its own. I wanted that division reflected in the operating procedure and the cost account. A useful design includes the work required to maintain a credible history, particularly when an exception cannot be settled through the ordinary automated path.

## Release the supported history and retain the exceptions

Our test set contained 102 scenarios covering ordinary sequences, late entries, corrections and future-effective changes. The revised path supported 88. Fourteen legacy scenarios still required an assisted process. We retained those fourteen in the release account rather than treating them as irrelevant because the modern path worked. Their continued existence affected support capacity, the claims that could be made about automation and the sequence of further work. A release can be useful while incomplete, provided the remaining scope is understood and responsibly handled. Removing unfinished scenarios from the report would not remove the people who still needed to use them.

The earlier 37 findings and the later 102 scenarios were different forms of evidence. One came from a review of approved changes; the other was a constructed test set. They did not support a simple before-and-after defect percentage. I wanted the report to state what each exercise established. The review identified a problem in the business-time view. The test showed support for 88 specified scenarios and the need for assistance in fourteen others. Neither result proved that every historical record had become correct. Continuing operation and further review were still necessary, with their own evidence rather than a borrowed claim from the initial test.

For a board, the question is whether the company's records can support the decisions directors and management expect to make from them. When a material conclusion depends on timing, does the reported date describe the business event, its approval or its entry into the system? Can a later correction be understood without rewriting the past into a deceptively simple story? Who resolves an ambiguous case, and what remains outside automated support? These questions help directors assess the reliability of a management account. They do not require directors to select the technical implementation or replace the professionals responsible for the underlying insurance decision.

The experience made me less willing to praise a timeline simply because it was easy to read. Ease matters, but the visible sequence must answer the right question. I had approved a model that worked neatly when everything arrived in order, then learned how much ordinary business falls outside that assumption. The revised service preserved the distinction and retained an assisted path for the cases it could not yet support. That was a more qualified release than the original ambition. It was also a more honest definition of progress: a record that explained more of the business, with clear limits on what it still could not establish.