This is one of my favourite topics: back dated changes…

Provocative question: Rewriting history or not?

A while ago, I described a seemingly simple insurance scenario to a group of engineers.

• Given a term life policy.
• Regular premium payments happened over the years.
• A policy change was recorded shortly before a claim was filed.

Within minutes, the discussion went exactly where it almost always goes. We were no longer talking about insurance. We were talking about models. Does this sound familiar?

I’m using a Life & Health insurance example here, but the pattern shows up in many industries whenever business decisions get translated into software.

Let’s restate the situation plainly. Ann Hunter bought a term life policy years ago. The sum assured was €200’000. Premiums were paid on time.

On 23 December 2025, a policy change was recorded increasing the sum assured to €300’000. No underwriting was required.

On 5 January 2026, the claims department received a first notice of loss (FNOL). The life insured (Ann) had died on 15 December 2025. The beneficiaries now claimed €300’000.

This is usually the moment where things derail. Suddenly we’re debating:

• whether the policy was “already changed”
• whether this is a correction or a late update
• which system owns the truth
• how to reconcile state
• how to ensure consistency

The discussion becomes academic, sophisticated, technically impressive, and completely disconnected from the business problem.

Because from a business perspective, there is no dilemma here. Insurance has a very old, very clear rule:

Liability is determined by the coverage in force at the time of the insured event.

The insured event occurred on 15 December 2025. On that date, the sum assured was €200’000. Everything that happened after that date is irrelevant to the insurer’s obligation. Not because a system says so. Not because a transaction failed. But because the business does not allow liability to change after the insured event.

This is the crucial distinction that gets lost in technical debates.

The claims department is not trying to fix the policy. They are not reconciling state. They are not repairing inconsistencies. They are interpreting facts.

Their question is not:

“What does the policy look like today?”

Their question is:

“What was true at the moment the insured event occurred?”

Once that question is answered, the decision makes itself.

This is why these discussions become hard only when we make them technical too early. When we flatten time into “current state”. When we treat history as something to correct. When we focus on data movement instead of business meaning.

The business problem was never complex. We made it complex by ignoring how the business actually thinks. When we stay laser-focused on business facts:

• time matters
• facts are immutable
• decisions are contextual

And suddenly, the system we need becomes much clearer. Not because we solved an academic modeling puzzle — but because we stopped solving the wrong problem.

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

Originally published on LinkedIn (2026-01-06): https://www.linkedin.com/pulse/when-software-makes-simple-business-decisions-hard-schenker-rh96e