In my previous post, I started digging into one of my favourite topics: back-dated changes. Not because they are rare or exotic, but because they are remarkably honest. They tend to expose very quickly whether a system is grounded in business reality or whether it quietly assumes that time does not really matter. Back-dated changes have a way of revealing the gaps between how a business reasons about the world and how software often tries to simplify it.

In this post, I want to take the same idea one step further by using a slightly more complex Life & Health insurance example. The goal is not to make the problem harder, but to make it more realistic. Complexity in this case does not come from technology; it comes from the business itself — from the way real policies evolve over time.

Consider a term life policy that has been active for several years. It is issued with a sum assured of €200’000, and for a long time premiums are paid regularly. Eventually, however, payments are missed and the policy lapses. Some time later, the customer requests reinstatement. Underwriting is required, assessments are made, and the reinstatement is finally approved — with an effective date back-dated to the beginning of the month. Later still, the customer requests an increase in the sum assured. That change is processed after some delay and, once again, the effective date lies in the past. And then, somewhere in the middle of all this, the insured dies. The first notice of loss arrives weeks later.

None of this is unusual. Anyone who has worked in Life & Health insurance will immediately recognize this as a very ordinary policy lifecycle. It is messy, temporal, and full of late knowledge. And yet, this is exactly the kind of scenario where systems tend to struggle the most.

From the perspective of the claims department, the situation is actually very clear. They are not interested in “the policy” in some abstract sense, nor in what the policy looks like today. They are interested in one very precise question: what was valid at the moment the insured event occurred? Was the policy in force at that time? Had the reinstatement already taken effect? Did the increased sum assured apply yet? These are not technical questions; they are business questions rooted in time.

This is where many systems begin to show cracks. Most of them are extremely good at telling you what the policy looks like now. They will show an active policy, a successful reinstatement, and an increased sum assured. From a state-based perspective, everything looks consistent and tidy. But that “current state” does not actually answer the claims question. In fact, it often obscures it, because it collapses several moments in time into a single representation.

The reason for this mismatch is simple. The business does not reason in terms of state. It reasons in terms of facts and their timing. A policy lapse is a fact. A reinstatement approval is a fact. A back-dated effective date is a fact. The death of the insured is a fact. None of these facts erase or overwrite the others. They accumulate, they coexist, and their meaning depends on context. What matters is which of these facts were valid at a specific point in time.

This is also why back-dated changes are so revealing. A back-dated change is not a correction of history; it is a new fact about the past that becomes known or decided at a later point in time. The business is entirely comfortable with this distinction. It knows when a change was recorded and from which date it should apply. Many systems, however, try to “fix” history instead. They overwrite earlier values, normalize timelines, and collapse everything into a single, supposedly correct state. In doing so, they lose the very information needed to explain decisions.

This is the point where EventModeling quietly changes the conversation. Not by introducing new technology or by insisting on a particular architectural style, but by forcing us to look at the business the way the business actually operates. When working with EventModeling, we do not start with policy state. We start with decisions and then walk the timeline that led to them. We lay out what happened, in which order, and we distinguish carefully between when something occurred, when it was recorded, and when it became effective.

In this way of working, back-dated changes stop being special cases. They are simply events with effective dates in the past. When a claims question arises — “What was valid on the day of death?” — we do not inspect a snapshot or reverse-engineer flags. We walk the timeline up to that day. Every fact that was effective before that moment is in scope; everything else is not. The answer emerges naturally, and more importantly, it is explainable in business terms.

This is the fundamental difference between event-centric thinking and state-based approaches. State-based systems are optimized for convenience and for showing the latest version of things. Event-centric systems are optimized for understanding. They preserve business memory. Insurance makes this distinction particularly visible because time, liability, and money are unforgiving, but the same pattern appears in finance, healthcare, logistics, and any domain where decisions must be justified, audited, and explained years later.

Back-dated changes do not break systems. They only break systems that quietly assume that history can be rewritten. The business never made that assumption.

Prior posts in the series:

• Post 1: We lack a shared language and blueprint
• Post 2: We can work with a small set of repeatable building blocks
• Post 3: We need a living map for the enterprise
• Post 4: When “change state” quietly reshapens our boundaries
• Post 5: Where does a domain get the facts it needs to make a decision?
• Post 6: Boundaries Follow Decisions, Not Data
• Post 7: When software makes simple business decisions hard

Originally published on LinkedIn (2026-01-07): https://www.linkedin.com/pulse/why-systems-forget-what-business-never-did-gabriel-n-schenker-yw4be