One of the most persistent ideas in software is that there is such a thing as the current state. The policy is active. The balance is correct. The order is completed. The record is up to date.

It sounds harmless. Even reassuring. And for many use cases, it appears to work just fine.

Until the moment a real decision has to be made.

In my recent posts, I’ve been circling around back-dated changes and claims decisions, using Life & Health insurance as an example. Not because insurance is special, but because it is unforgiving. Time matters. Liability matters. And when something goes wrong, “almost correct” is not good enough.

What keeps showing up in these discussions is a quiet but dangerous assumption: that the latest version of state is the most relevant one.

Let’s return briefly to the claims scenario.

A policy evolves over time. Premiums are paid. Sometimes they are not. Policies lapse and are reinstated. Coverage changes are requested, approved, and often made effective in the past. And at some point, an insured event occurs.

When a claim arrives, the business question is very precise: what was valid at the moment the insured event occurred?

Not what is valid now. Not what the policy looks like today. Not what the system currently shows as “active”.

And yet, many systems insist on answering exactly those questions instead.

The problem with “current state” is not that it is wrong. The problem is that it is context-free.

Current state collapses time. It smooths over how things got there. It hides sequence, causality, and eligibility behind a single snapshot that looks authoritative but explains very little.

In a decision-heavy domain, this is not a convenience. It is a risk.

Claims decisions, compliance checks, audits, legal disputes — all of them live in a world where when something was true matters just as much as what was true. A reinstatement that is perfectly valid today may have been irrelevant last month. A coverage increase that exists in the system may be legally meaningless for a past event.

The business understands this instinctively. The system often does not.

This is where back-dated changes become so revealing.

A back-dated change is not an edge case. It is a signal. It tells us that business reality does not unfold neatly in real time. Decisions are made late. Information arrives after the fact. Effects are applied to periods that have already passed.

The business has no trouble with this. It distinguishes clearly between:

• when something happened,
• when it was recorded,
• and when it is allowed to take effect.

State-based systems, however, tend to treat back-dated changes as a problem to be “fixed”. They overwrite values. They normalize timelines. They attempt to restore a single, coherent present.

In doing so, they erase the very information that makes decisions explainable.

What #EventModeling changes — quietly but fundamentally — is the question we ask.

Instead of asking “What is the state?”, we ask: “What happened, in which order, and what was valid when this decision had to be made?”

That shift sounds subtle. It isn’t.

When you model a policy as a sequence of business facts over time, “current state” stops being the authority. It becomes just one possible projection — useful for some purposes, but insufficient for decisions that depend on history.

A claims decision is no longer derived from a snapshot. It is derived by walking the timeline up to the insured event and considering only the facts that were effective at that point. Back-dated changes do not require special handling. They are simply facts with effective dates in the past, recorded later.

The answer emerges naturally, and more importantly, it can be explained.

This is why “current state” is such a dangerous lie in decision-heavy systems.

It gives the illusion of certainty while quietly discarding context. It optimizes for convenience at the expense of understanding. It answers the wrong question very efficiently.

The business never asked for that.

What the business needs is the ability to say, years later if necessary: this was the situation at that moment, these were the facts we had, and this is why the decision was correct.

State alone cannot do that. History can.

Insurance makes this painfully obvious, but it is not unique. The same pattern shows up in finance, healthcare, logistics, and any domain where decisions must survive scrutiny. Wherever time matters, flattening reality into “now” is not a simplification — it is a distortion.

EventModeling is not a rejection of state. It is a refusal to treat state as truth.

It reminds us that systems exist to reflect business reality, not to rewrite it into something more convenient.

And business reality, inconvenient as it may be, unfolds in time.

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
• Post 8: Why Systems Forget What the Business Never Did
• Post 9: Why EventModeling Still Struggles in the Enterprise

Originally published on LinkedIn (2026-01-11): https://www.linkedin.com/pulse/why-current-state-dangerous-lie-decision-heavy-systems-schenker-qveje