Docs and articles
R-69
Technology
Tessera DB Tutorial: Bitemporal Queries to Reconstruct Historical State for Audit
Every fact carries valid time and transaction time. Learn to answer 'what was true on date X' and 'what did the system show on date X' — two different questions, two different queries.
PAR2 Labs
August 29, 2026
5 min
Every hyperedge in Tessera carries two independent time intervals: valid time (when the fact is true in the real world) and transaction time (when the database learned it). This tutorial shows how to query against each, and why you'll want to.
01
The mental model
Think of a customer who moved house. Their old address is:
Valid from 2024-01-01 to 2024-12-31 — when they actually lived there.
Recorded (transaction time) on 2024-01-10 — when they finally got around to telling the bank.
02
Two questions, two axes
"Where did they live on 2024-06-01?" → ask along valid time.
"What address did the system show on 2024-06-01?" → ask along transaction time.
03
Step 1: Record a bitemporal fact
When you insert or import a fact, Tessera stamps it on both clocks. You can set the valid-time interval explicitly (the period the fact describes) while transaction time is captured automatically as "now" — the moment the database learned it. A fact whose transaction-time interval is still open is the current, live version.
04
Step 2: Snapshot along valid time — what was true in the world
Ask for the state of the data as it was valid at a chosen instant. Tessera returns every fact whose valid-time interval contains that instant. This answers "where did this customer live in the middle of the year?" regardless of when the bank found out.
Transaction time answers questions about your system's knowledge of the world.
05
Step 3: Snapshot along transaction time — what the system knew
Ask for the state of the data as the database recorded it at a chosen instant. This is time-travel over the system's own knowledge. Query the database as of early January and the new address will not appear — it wasn't recorded until the 10th — even though, in hindsight, it was already true. That gap between reality and knowledge is exactly what a regulator asks about.
06
Step 4: Facts overlapping a range
Ask for every fact whose valid time overlaps a window — "all addresses valid at any point during the second quarter." This surfaces everything that was in effect across a period, not just at a single instant.
07
Step 5: Combine both clocks
The most useful queries combine both axes: "what was true in the world on date X, as known to the system on date Y." Because the new address was valid mid-year but wasn't yet recorded in early January, that combined query correctly returns nothing for it — the honest historical answer, and the question regulators ask.
08
When to reach for each
Valid time answers questions about the world. Transaction time answers questions about your system's knowledge of the world. Audits, regulations, and disputes almost always want the second one.
09
What you have now
You can reconstruct the state of any entity at any past point in time, and independently reconstruct what your system would have shown at that point. Those two capabilities together cover almost every audit, compliance, and dispute-resolution case — without maintaining a separate audit log.
Key Takeaways
01
Recorded a fact on both clocks: an explicit valid-time interval, with transaction time captured automatically.
02
Taken snapshots along valid time (what was true) and along transaction time (what the system knew).
03
Found every fact whose valid time overlaps a window, not just a single instant.
04
Combined both clocks to ask what was true on one date, as known to the system on another.
PAR2 Labs · Technology
Talk to us