I needed to read this, but I'm not sure what to make of it yet. The reason is I've been struggling with the idea that (bi-) temporal, consistent data is great,

I needed to read this, but I'm not sure what to make of it yet. The reason is I've been struggling with the idea that (bi-) temporal, consistent data is great, as it provides a ton of leverage both for users and for auditing and debugging. For some problems it's the cleanest, general solution. What irks me that the code that validates, consumes, transforms and displays the data lives in its own time model (git). Philosophically you're not really looking into the past. You're looking at an echo of the past that's displayed in a current form. And more practically it's simply tough to draw the line between assuring that historical data is still handled and rendered correctly and getting rid of overhead and complexity of a growing and evolving application. The article talks about eventual consistency, but I really don't have these kinds of problems and when I do, I fully agree with the author as long as it's very clear to the user whether something is consistent and when it will be.