Temporal history
Every business record keeps its complete change history. Each version is bounded by the period during which it was true, so you can reconstruct any record as it stood at any past moment.
Why it exists
Master data feeds decisions, and decisions get questioned later. "What address did we hold when that statement was posted?" is a question you can only answer if the old value still exists.
Overwriting in place makes that unanswerable. Keeping history makes it routine.
The guarantees
Two properties hold by construction, enforced by the database rather than by convention:
- No gaps. Every moment since a record was created is covered by exactly one version.
- No overlaps. No two versions of the same record claim the same moment.
Together these mean a point-in-time question always has exactly one answer. Not zero, not two.
History versus audit
Two different things, easily confused:
| Answers | Shape | |
|---|---|---|
| Temporal history | What did this record look like at that time? | Versions of a record |
| Audit log | Who changed this, and when? | Append-only events |
History reconstructs a state; the audit log investigates an action. You usually want both: history tells you the address was wrong, the audit log tells you who changed it and when.
Relationship effectivity
Relationships carry their own effective period, so a link that ends is closed rather than deleted. When a fact changes — an asset sold, an employment ended — the previous window closes and a new one opens.
Asking who owned an asset last March returns the owner as at last March, not the current one.
Initial loads
The very first bulk load into a new tenant can skip history, since there is no prior state to preserve and nothing has changed yet. A record loaded that way begins its history at its first real change.
This is a deliberate option for the initial load only. Using it for ongoing operation discards exactly the history you will later want.
Next
Last verified against commit 952ed91b (2026-08-03)