The 1st Part finished with a promise: for two timelines to interlock cleanly, their time periods have to be brought into a clear relationship with one another. That mechanism is what we look at now.
Part 1 covered the what and the why: as soon as data arrives in a different order than it actually happened, data quality erodes without bitemporal historization. That leaves the how – and this is where most teams land in the same spot: conceptually it is clear what should happen, but how do you approach it methodically?
If you have not met Diego, Amal and Xuefang yet: they are fictional characters from the FastChangeCo universe, which I use to make real challenges from projects and coaching tangible.
This article is Part 2 of a four-part series on bitemporal data in practice. It takes on the fourth of the eight reasons from the hub article “8 reasons why you need bitemporal data”: the ability to travel through time within your data.
The core thesis: time travel is not a side effect of bitemporality. It is its actual purpose – and it has a grammar you can learn.
The DeLorean in the office
There is an analogy that holds up surprisingly well when it comes to temporal data: the DeLorean from “Back to the Future” in my offifce. A car that travels through time. That is exactly what a bitemporal data solution does – except it does not drive into the future. It places you at any point in the past and shows you what your data looked like from there.
At FastChangeCo, this turns into a very concrete question. Amal Leyla Qasim, data modeler on the team, took away from Part 1 that two timelines resolve the late-arrival problem. But she is stuck on a practical point: “Fine, now we have two timestamps instead of one. But what do I actually do with them when someone asks me for an old state?”
Diego Pasión, who coaches the team, picks the question up. “That is exactly the right entry point. Before we talk about joins and SQL, let us clarify what kind of question you are even asking. Because there is not one time travel – there are three.”
As-Is, As-Was, As-Of: three views on the same data
Diego steps to the whiteboard and writes three terms underneath each other. “Same table, same rows – and still three completely different answers, depending on the point in time you look from.”
As-Is – what does reality look like today? This is the present-day view. The state that is currently valid, exactly as it stands in the system right now. Most reports a business team pulls daily are As-Is queries, even if nobody calls them that.
As-Was – what did reality look like back then? Here you travel along the business timeline. You are not asking what is valid today, but what was valid in reality at a specific past date. What was the price of this product on March 1? Which address did this customer have last quarter?
As-Of – what did we know back then? This is the view that simply does not exist without bitemporality. You travel along the technical timeline and ask: what picture of reality did our warehouse hold on a specific date? Not what was true – but what we believed to be correct at the time.
Xuefang Kaya, junior on the team, jumps in at exactly the point where it first clicks for most people. “Wait – As-Was and As-Of sound the same to me. Both are about the past.”
Diego nods. “Good objection, that is the knot. An exchange rate was wrong in March, we correct it in May. As-Was asks: what was the correct rate on March 10? The corrected value – that is reality. As-Of asks: what would our report have shown on March 10? The wrong value – we did not know about the correction yet. Two different truths about the same day. That difference is bitemporality.”
Two timelines, not one calendar
For the three views to work, you need two independent timelines. Part 1 introduced them; here they become the tool.
The Assertion Timeline (technical) records when a value became known in our warehouse. Its timestamp is the Inscription Timestamp. The State Timeline (business) records from when a value was valid in reality – via the State Timestamp.
The decisive point: these two axes are independent. There is no single calendar that answers both questions at once. Every bitemporal fact sits at the crossing of two axes – one asking “when was this true?”, the other asking “when did we know it?”.
This is exactly where the late-arrival problem from Part 1 dissolves. A correction that arrives late lands at a different position on the Assertion Timeline than the original – so it no longer overwrites it. It gets its own place in the grid instead of displacing the older value.
“Which means”, Amal sums up, “I stop making one timeline answer two questions. I give each question its own axis.” Diego: “Exactly. And the moment you do that, you can travel deliberately – along one axis, along the other, or along both at once.”
Closed-open intervals: “before”, not “until”
Before we get to the relations between time periods, one detail that saves a lot of time in implementation – or costs it, if you ignore it: how a time period is bounded in the first place.
In bitemporal historization you work with closed-open intervals: the start point belongs to the period, the end point no longer does. Diego anchors it in the relocation example: “You live at an address from January 1, and on September 12 you move. Your old period is then not ‘January 1 until September 12’, but ‘from January 1, before September 12’. The 11th still belongs to it, the 12th already belongs to the new period.”
From that follows this series’ wording rule: we write “before”, not “until”. “Until” leaves it open whether the end day still counts; “before” makes it unambiguous. The two periods share exactly one boundary value – no gap, no overlap.
This is more than cosmetics: a gap-free, overlap-free timeline makes every load simpler. When you insert a record, you never have to check whether an end day has been assigned twice – the boundary always belongs to exactly one side. You make this decision once at the start, and afterwards it carries itself.
The grammar of time travel: the Allen Relationship
Now to the heart of it. Amal’s starting question was: what do I actually do when a correction comes in and has to be slotted in somewhere? The answer is the Allen Relationship.
The Allen Relationship describes how two time periods can relate to one another – and there are not infinitely many possibilities, but exactly thirteen. Two periods can lie before or after one another, meet, overlap, sit inside one another, start together, end together or be identical. That was the whole list.
“Thirteen sounds like a lot at first”, Xuefang says. Diego waves it off. “Thirteen is a shopping list. You do not have to memorize it – you just have to know that it is finite. The moment you have a concrete correction in front of you, you look it up: which of the thirteen relations applies here? And from that follows what to do.”
That is the difference between one, two or three newly inserted rows. The key point: the existing row is never modified – it is end-dated on the Assertion Timeline, and new rows are added on top. If the correction appends cleanly, one is enough: the new period. If it overlaps an existing period at one end, two are added – a duplicate of the old row for the part that is still valid, plus the new period. And if the correction cuts into the middle, it is three: one duplicate for the part before and one for the part after, plus the new period. Which case applies is what the Allen Relationship tells you. Reading it “like a shopping list” is something you practise in the Temporal Data Training.
About this series: This is Part 2 of 4 in our series “Bitemporal Data in Practice”, which moves from the concrete engineering pain to the strategic decision. Part 1 shows why one timeline is not enough for late arrivals. The overall picture is given by the hub article “8 reasons why you need bitemporal data”. Part 3 leaves pure error correction behind and looks at past, present and future.
Time travel that actually works
Modules 1 and 2 of the Temporal Data Training teach exactly this way of thinking: the Allen Relationship, clock ticks and bitemporal structures – with SQL tutorials and exercises you can apply directly to your own architecture. The training is currently being re-recorded.
→ Join the waitlist (with an early-bird advantage as a series reader)
What the end user never sees
At this point an objection comes up regularly, and Xuefang voices it: “This all sounds like quite a lot of complexity. Do our business teams now have to understand all of it?”
The answer is simple: Bitemporal data is generally not meant for the end user. Its job is to put the data into the right order in the background. Bitemporality operates beneath the surface – it is not supposed to be visible at all.
What the business team gets in the end is a clear view: usually the current view of the data, sometimes the business view of a specific point in time. What was my price yesterday? What is valid today? What is planned for the future? A lean query answers these questions – the whole machinery of two timelines and thirteen relations stays hidden behind it.
What matters is the teams who implement it: there you need a certain level of maturity and an understanding of what happens in the background. But here too the rule holds – implement it cleanly once, at the start of the data solution, then automate it. “You build the complexity in correctly once”, Diego says, “after that it is a solution pattern you reuse again and again – not a problem you rethink in every project.”
From concept to method
Amal’s starting question was: conceptually I understand this now – but how do I begin methodically? The time travel rests on three building blocks: first, clarify which kind of question you are asking – As-Is, As-Was or As-Of; second, cleanly separate the two axes and keep them gap-free with closed-open intervals; third, use the Allen Relationship as a finite list to slot every correction into place.
That is the technical core of bitemporality. Not a mysterious depth, but a countable craft – learned once, then mastered.
“The knot in the brain”, Diego says as the meeting wraps up, “we almost untangled it today. What remains: so far we have only talked about corrections – about past things we put right. But time travel also runs forward. Retroactive postings, planned prices, scenarios for the future. We will look at that next time.” That is exactly where we continue in Part 3.
So long,
Dirk