Bitemporal Modeling

Bitemporal modeling rests on two orthogonal timelines:

• Valid Time: When a fact is true in the real world. For example, a contract's effective date of January 1, 2024, means the obligation was legally active from that date, regardless of when it was entered into the system.
• Transaction Time: When a fact is recorded in the database. This is system-generated and immutable, capturing the exact moment a row was inserted or updated.

These axes are independent. A contract signed in March (valid time) might not be entered into the system until April (transaction time). Later corrections to the valid time create new transaction-time entries without overwriting history.

A core principle of bitemporal modeling is that data is never deleted or overwritten. Instead, updates are implemented as logical inserts with new transaction-time intervals.

This creates an append-only, cryptographically verifiable audit trail. For legal obligation management, this means:

• Every correction to a deadline or party is preserved as a distinct record.
• A query can reconstruct the exact state of a contract as it was known at any historical point in time.
• Compliance officers can prove precisely when a change was made and what the previous state was, satisfying stringent regulatory requirements for data lineage.

Bitemporal tables enable two powerful query patterns that are impossible with conventional temporal tables:

• 'As of' a Valid Time: Retrieve the state of the world as it actually was on a given date. For example, 'Show me all active obligations on June 15, 2023.'
• 'As known at' a Transaction Time: Retrieve the state of the database as it was understood at a specific moment. For example, 'What did our system report as the deadline on July 1, 2023, before the amendment was processed?'

Combining both axes allows a query like: 'Show me what we believed on July 1, 2023, about the obligations that were active on June 15, 2023.' This is critical for reconstructing decision-making contexts during litigation.

A standard bitemporal table extends a conventional table with four timestamp columns:

• valid_start and valid_end: Define the interval during which the fact is true in reality. A valid_end of 9999-12-31 indicates a currently true fact.
• tx_start and tx_end: Define the interval during which the record existed in the database. tx_start is the insertion timestamp, and tx_end is set when the row is logically superseded.

A primary key typically includes the business key plus valid_start and tx_start. Constraints ensure that intervals for the same entity do not overlap on either axis, maintaining logical consistency.

Bitemporal modeling distinguishes between two fundamentally different types of data modifications:

• Correction (Error Fix): The valid time was entered incorrectly. The fix involves closing the current transaction-time row and inserting a new one with the corrected valid-time interval. The old, erroneous record remains in the transaction-time history.
• Retroactive Change (Late-Arriving Fact): A real-world event occurred in the past but is only being recorded now. The valid-time interval is set in the past, but the transaction time is the current system timestamp.

This distinction is vital for legal systems, where a scrivener's error and a retroactive amendment have entirely different legal implications.

Bitemporal databases provide the factual grounding for formal temporal reasoning systems like Allen's Interval Algebra and Temporal Logic (TL).

While temporal logic provides the rules for reasoning about 'before', 'after', and 'until', a bitemporal model provides the concrete, versioned facts upon which those rules operate. For example:

• A Temporal Constraint Satisfaction engine can query the bitemporal store to determine if a sequence of obligations has a valid timeline.
• A Temporal Contradiction detector can identify cases where the valid-time intervals of two clauses create a logical impossibility, while the transaction-time history shows when the contradiction was introduced.