Part 2 ended with a line from Diego: “Time travel runs forward too. Retroactive bookings, planned prices, scenarios for the future.” That's exactly where we pick up now.

With the two timelines from part 2 in place, three different questions suddenly become answerable cleanly — questions that constantly get tangled up in day-to-day data work: what will hold? what held back then? what did we know back then? Three questions that inevitably collide without that split — and have three clear answers with it.

If you haven't met Philomena, Amal and Yerodin yet: they are fictional characters from the FastChangeCo universe, which I use to make real-world challenges from projects and coaching sessions tangible.

This article is part 3 of a four-part series on bitemporal data in practice. It bundles two of the eight reasons from the hub article “8 reasons why bitemporal data is needed”: storing reality for the past, the present and the future — and handling retroactive operations cleanly.

The core argument: once the two timelines are in place, bitemporality answers three business questions that constantly get tangled up in day-to-day data work — across past, present and future.

At FastChangeCo, it starts with a planning round. Philomena Pavlovic, business analyst, is sitting with marketing over the campaign plan for Black Friday. Five price campaigns are supposed to go live automatically on November 28 at 0:00 — and switch back to the regular price on December 2 at 0:00. “How do we enter this,” she asks the team, “without somebody hammering manual SQL updates at midnight?”

Yerodin van Dusseldorp, controller, furrows his brow. “And my forecast-vs-actuals comparison — that breaks straight away if the price base shifts automatically. When I look back at the end of December, will I see the campaign price or the regular one? And what do I compare my forecast against?”

Amal Leyla Qasim, data modeler in the team, glances at the whiteboard from the week before last. The two timelines from the meeting on part 2 are still up there — assertion and state. “We've already got the tool,” she says. “We're just using it in one direction so far.”

Philomena looks up. “In one direction?” Amal reaches for the pen.

Three questions, one mechanism

From part 2 we have two timelines set. The Assertion Timeline (technical) records when we learned about a value. The State Timeline (business) records from when it actually holds in reality. Two axes, each with its own question.

Amal draws the State Timeline as a horizontal line on the whiteboard. “What we've been overlooking: this line has no built-in direction. ‘Now' is just one value on an axis that stretches into the future just as it stretches into the past. Once you see that, the toolbox changes.”

Three questions then become answerable that inevitably collide without two timelines:

As-Is — what holds? Not: what holds right now. Today's state is just a special case — the question works for any point on the State Timeline.

As-Was — what actually held back then in business terms, even if we only learned about it later?

As-Of — what did we know back then?

“Two timelines, three different answers,” Amal says. “Without them, the questions collide and the whole team puzzles over why yesterday's report looks different today.”

Three examples from daily business are waiting for answers: Black Friday, the pay-scale settlement, Yerodin's forecast comparison. One per question.

Future: planned prices

First question: what will hold? Philomena's Black Friday planning lives on this question being applicable to data in the future as well.

Concretely, Philomena enters five records today — one per planned campaign. Inscription Timestamp: now — so it's clear when we recorded the prices as binding. State Timestamp: from November 28 at 0:00 — so it's clear from when they actually hold. Two timestamps, one record, no conflict.

What happens technically on November 28 at 0:00? Nothing. The record is already in the system, it simply becomes valid in business terms. No cron jobs, no midnight SQL, no marketing intern staying awake. The mirror image holds on December 2 at 0:00: a second record, also entered ahead of time, becomes valid and supersedes the Black Friday price.

Amal to Yerodin: “And if someone asks on November 30 ‘what was the price on November 1' — the campaigns don't change that, because they sit at a different position on the timeline. The business validity for November 1 is independent of what comes later.”

The practical effect isn't small. Marketing plans today, the system fires at the right time. Pricing teams no longer need to maintain activation lists, operations no longer have to arm midnight cron jobs, and the transition into the sale runs as quietly as a clock ticking over. Philomena's reaction is dry: “Finally I can go home and sleep before the campaign goes live.”

In the hub article, this is the reason “Store reality for past, present and future”. Anyone planning prices into the future is answering an As-Is question — just for a point in time that hasn't arrived yet.

Past: retroactive bookings

Second question: what actually held back then in business terms — even if we only learned about it later? The retroactive pay-scale booking lives on exactly this split.

Pay-scale settlement on October 15. The pay raise applies retroactively from July 1. Classically, without bitemporal historization, HR would simply update the values now — and the historical Q3 report instantly shows higher salaries, as if they had already held in July. The state at Q3 close is gone.

Bitemporal separates this cleanly. A new record is added: State Timestamp = from July 1 (when it holds in business terms), Inscription Timestamp = October 15 (when we learned it). Both states exist in the table side by side — the original Q3 state stays untouched on the Assertion Timeline, the corrected value is effective from July 1 onwards via the State Timeline.

This is the As-Was question. What held in business terms on July 1? From October 15 onwards we know the answer — but it was already the right answer on July 1. We just hadn't known it yet.

Yerodin sees it immediately: “My Q3 report stays stable. And the current data state is still correct.” That's exactly the point. The past can be reconciled correctly in business terms without rewriting historical reports.

The same pattern carries every retroactive operation. The invoice arrives on the 4th of a month and still has to be booked into the previous month — State Timestamp in the previous month, Inscription Timestamp in the current month. In the hub article this is the reason “Retroactive operations”, and it's the same toolbox that handles the pay-scale change.

Present: stable reports in a moving world

Third question: what did we know back then? This is where Yerodin's sceptic question from the start of the meeting gets resolved.

Yerodin's real worry, sharpened: as soon as HR books retroactively on the State Timeline, every historical report potentially shifts. His forecast-vs-actuals comparison from Q3 close showed certain salary figures back then. If those figures change retroactively, his entire forecast accuracy wobbles.

Amal: “You're asking a different question than you think. Your forecast was created with the knowledge state of that time. The right question isn't ‘what held in business terms back then' — that's the As-Was view. The right question is ‘what did we know when the report was created?'”

That is the As-Of question — and the underlying mechanism is simple. As-Of cuts the Assertion Timeline at a past date. Anything we only learned afterwards stays invisible for that query. Yerodin's forecast comparison thus pulls the same data state he pulled at Q3 close — regardless of what HR has since added to the system.

Yerodin nods slowly. “So my forecast-vs-actuals comparison stays stable, even when HR reshuffles the past via the State Timeline. The two timelines aren't an extra comfort. They're the precondition for ‘back then' to mean anything unambiguous at all.”

Only separating the two timelines turns “back then” into two different questions.

What-if: time travel for scenarios

There's an extension that often comes up in planning conversations — and in the FastChangeCo meeting, Philomena raises it too: not every time journey has to be ‘real'. Some scenarios are hypothetical.

“What if we cut cost centres differently — what would revenue look like with a new org structure? Or a second forecast alongside the official one that makes a different assumption about utilisation. Can we do something like that?”

Amal: “That's nothing other than a record with a State Timestamp in the future that's deliberately never activated. A scenario state next to the live state — on the same table, with the same tool.”

Yerodin latches on right away: “And I can maintain forecasts in several versions side by side without the versions overwriting each other. Each version with its own State-Timestamp corridor — viewable, comparable, auditable.”

This isn't the core of this article — but it shows how far the toolbox carries once the two timelines are cleanly in place.

Black Friday, retroactive pay raises, planned contract changes — all examples I work on with teams in practice. The business mechanism is usually clear — but the step from “current state” to “reality modelled over time” rarely goes without a few steep stretches.

From pain to method

What the three take away from the meeting looks like a shared win. Philomena: marketing plans prices today, the system fires them at the right time on its own. Yerodin: historical reports stay stable, even when HR reconciles the past. Amal: the same mechanism from part 2 carries everything — built right once, then usable in all three directions. Three problems, one tool, three satisfied voices in the meeting room.

Three questions that constantly get tangled up in day-to-day data work — As-Is, As-Was, As-Of — and that suddenly have three clear answers with two timelines. That's all it is. And at the same time, that's exactly it.

Bitemporal isn't a tool for correcting the past — it's a tool for treating time as a plannable axis in the first place.

Up to this point it's been all business application. Three business questions, three clear answers, three examples from daily work. But who actually asks whether you can prove all of this — when the auditor shows up tomorrow and wants to know why the Q3 report looked the way it did? The argument that wins management over comes in the final part of this series.

If you want to learn the concept solidly first, before your own project starts: the Temporal Data Training will be available again from May 2026.

So long,
Dirk