Part 3 ended with a question hanging in the room: whether you can actually prove what's in your reports — and who would ever ask. For three parts it was all business application. Now someone from outside is asking. And the argument that wins management over starts right here.

If you don't yet know Sylvia, Diego, Michael, Yerodin and Amal: they are fictional characters from the FastChangeCo universe, which I use to make real challenges from projects and coaching tangible.

This article closes a four-part series on bitemporal data in practice. It bundles the three strategic reasons from the hub article "8 reasons why bitemporal data is needed" – decision analysis, legal regulations, audit and review – that otherwise tend to pass as buzzwords for "that's just what you do in the financial sector".

The one question that carries this article: can we prove what we knew, and when? It sounds like an obligation, yet it ends up somewhere else.

The one line nobody signs straight away

At FastChangeCo a contract is on the table. The customer is a major one, the kind of deal nobody wants to turn down, and the folder runs to forty pages of clauses — most of them routine. Sylvia Seven, CFO, reads them all anyway. She gets stuck on one.

"The Contractor shall ensure that, for every data record delivered, it can be reconstructed at any time at which point in time and with what state of knowledge that record was provided."

Sylvia reads it twice. "That's one sentence," she says, "but not one I sign on the side." She calls in Michael, Head of Data Management. He reads, says nothing, reads it again.

"Every data record delivered," Michael says eventually. "Not the current state. Every one. And not just what we delivered, but when — and what we even knew at that point." He quickly works out in his head what that means in deliveries per year, and he doesn't like the number. "If the customer asks in two years why a metric looked the way it did in March, then I have to be able to restore that March from two years ago. Not roughly — exactly."

Sylvia stays quiet. In her career she has seen enough contracts to know that sentences like this don't come from mistrust but from experience — at some point this customer was handed a figure that later changed quietly, and nobody could tell them what had happened between then and now. The clause is the scar of that experience.

Sylvia nods slowly. She says nothing that resolves it, no punchline, no "essentially this is just". She only notes: "We deliver the customer figures every month anyway. The question is whether we can pull them back once they're old."

That's exactly the sore spot. A classic data store knows only one state: the current one. Whoever overwrites loses the before. And a clause that demands "reconstruct at any time" asks for precisely what overwriting destroys.

Diego does the math

Michael brings in Diego, coach and mentor of the team. Diego reads the clause, then smiles a little – not because he wants to announce the solution, but because something looks familiar. "Read the sentence again, slowly: 'with what state of knowledge it was provided.' That's not about the delivery — it's about what you knew at that moment."

He reaches for the pen. "When a value held true in reality, and when you found out about it – those are two different things. You've been separating them for ages." On the whiteboard he draws the two timelines that have, in effect, been there since part 2: the Assertion Timeline (technical) records when we found out about a value, the State Timeline (business) records when it holds true.

"The state of knowledge at a reference date," Diego says, "is nothing other than a cut through the Assertion Timeline. You ask: what was known in March? And cut away everything you only learned afterwards. That's the As-Of view – the same one Yerodin used in part 3 to keep his forecast stable." He draws in the cut. "And by the way: you're not allowed to throw the old states away anyway, so the material for the reconstruction is already sitting right where it belongs."

Michael sees it coming. "Which means we build nothing new for the clause. We read what's already there, just from a different perspective." Diego: "And you worked that perspective out over the last three quarters, without ever thinking about a customer contract."

Diego makes it concrete. "Picture the customer asking in November: which revenue figure did you report to us for March – and what did you already know back then about the late postings that only arrived in May? Without the separation you'd have to guess, or search for a long time. With the Assertion Timeline you set the cut to the end of March and read off what was in the system at that point — not today's, the one from back then." That's the difference between "what's true today" and "what we delivered back then" – and both answers sit in the same table.

If you want to know how a finding like this translates into actual budget and a roadmap: in strategy workshops with data management leads and CDOs I draw exactly these two pictures side by side – what your data foundation already carries today, and where the gaps are before anyone from outside asks about them.

What Yerodin's reports are suddenly worth

Yerodin, controller, drifts in almost by chance and recognises his own reports. "That's the thing I've been working with since the pay-scale topic. My Q3 comparison still pulls the same state today as at the Q3 close – no matter what HR has reconciled since."

The very reports Yerodin built so that he could sleep are now the proof the clause demands. Amal, data modeler, sums up the mechanism in one sentence: "It's the toolkit from part 2 – the Allen relationship, closed-open intervals – only this time it isn't a controller reading it, it's a customer." The hub article for the series calls this the reason "Audit and review".

What that looks like in practice shows up in a small incident that has nothing to do with the major customer. An internal department complains: "You changed our February revenue figures after the fact." An accusation in the room, once the start of a long hunt — not this time. The team pulls the February state as it was visible at the monthly close, next to today's state, plus the point in time and the reason for the correction. When, how, why – in one query. After ten minutes the complaint is no longer a dispute but an explanation.

Michael remembers the old days, almost in passing: "You know what this actually replaces? The colleague who had to come into the office on New Year's Eve to pull the year-end snapshot off the warehouse – in case we ever needed that state again. We don't need them anymore. The state is always there."

Yerodin laughs briefly. "A complaint like that used to cost half a day – and in the end nobody believed us anyway." Amal, dryly: "Now nobody has to believe us. It's in the data, when something changed and why. That's a different tone of conversation."

Sylvia, a second time

Sylvia has been listening the whole time, more than she has spoken. When Diego is done, she doesn't say "so we sign". She says: "At my previous employer we went through a BaFin audit – Germany's financial regulator. Exhausting, weeks of it. But by the end I knew things about our own figures I had only assumed before. I didn't enjoy the audit. I didn't regret it."

She says no more about it. She looks at the clause, then at the whiteboard with the two timelines, then at the clause again. "We laid the foundation for something we wanted internally – stable reports, clean corrections, a forecast that doesn't wobble. And now there's a customer who happens to want the same foundation." She lets the sentence stand, without resolving it.

In the hub article this is the reason "Legal regulations": especially in the finance and insurance industry there are requirements for unchangeable, undeletable storage of data. What turns up at FastChangeCo as a customer clause is written into law for others – the mechanism behind it is the same. And the reason "Decision analysis" sits right next to it: whoever can reconstruct the state of knowledge from back then can also trace whether a decision was right with the knowledge of the time – not with today's.

From pain to decision

Look at the clause again now and it reads differently. "For every data record delivered" – that's the question of unchangeable, undeletable storage. "At which point in time" – that's the audit trail, the when, how, why. "With what state of knowledge" – that's decision analysis, the knowledge of back then. Three of the eight reasons from the hub, in a single contract sentence, without anyone having written them in there.

That's the arc of this series. Part 1 began with an engineering pain: data arriving in the wrong order. Part 2 built the mechanism – two timelines, cleanly separated. Part 3 showed the business value: past, present and future as a plannable axis. And here, in part 4, it turns out the same foundation answers a question nobody asked while building it.

Maybe you know the situation from the other direction: first there's the external requirement – an audit, a clause, a regulator – and then the search begins for how to meet it. At FastChangeCo it ran the other way. The foundation came first, the requirement after. Which of the two paths is ahead of you depends above all on when you start.

Sylvia signs in the end. Before she closes the folder, she says just one sentence, half to Michael, half to herself: "We didn't have to start anything new." No more of a point is needed.

Once the strategic decision has been made, the Temporal Data Training brings your team up to the necessary level of knowledge in two to four days – in-house if you like.

So long,
Dirk