Skip to content

Bitemporal Event Register

Bitemporal register / ledger artifact — instantiates Event-Log-Centered Modeling

Records every fact along two clocks — when it happened and when the system came to know it — with the source of each assertion, so you can ask what was believed as of any past moment.

Most logs collapse two different times into one and quietly mislead as a result. The time an event occurred and the time the system learned of it are not the same, and treating them as one makes it impossible to answer "what did we believe last Tuesday?" Bitemporal Event Register keeps them apart. For every fact it records two timestamps — event time (when it happened in the world) and record time (when it entered the register) — plus the provenance of the assertion (who said so, from what source). Its defining capability is the as-of query: reconstructing not just past reality but past belief about reality — what the system held to be true as of any chosen record time, before a later correction arrived. Where an ordinary log answers "what happened," the bitemporal register also answers "and when did we come to know it, and on whose word."

Example

An insurer keeps its claims history in a bitemporal register. A hailstorm claim is filed on March 3 (event time: the storm was March 1). On March 20 an adjuster revises the damage estimate upward after a re-inspection. Both assertions live in the register with distinct clocks: the original estimate carries event-time March 1 / record-time March 3, provenance "intake system"; the revision carries event-time March 1 / record-time March 20, provenance "adjuster #402, re-inspection report."

Six months later a regulator asks: what was this claim's reserved amount as of March 15? An ordinary current-state system can only show today's number and cannot honestly answer. The bitemporal register runs an as-of query at record-time March 15 and returns the original estimate — because on March 15 the revision did not yet exist in the system's knowledge, regardless of the storm being long past. The register can show both "what was actually true" (event-time reasoning) and "what we believed and when" (record-time reasoning), each with its source. That separation is exactly what audits, disputes, and restatements require — and what a single-timestamp log can never reconstruct.

How it works

The register's distinctive machinery is the two-clock discipline and the assertion trail:

  • Stamp two times on every fact. Event time (when it occurred) and record time (when the register learned it) are recorded separately and never conflated.
  • Never overwrite a belief — supersede it. A correction is a new assertion with a later record time; the earlier belief remains, so history-of-knowledge is preserved.
  • Attach provenance to each assertion. Every recorded fact carries who asserted it and from what source, so belief can be traced, not just stated.
  • Serve as-of queries on either axis. Ask "what was true at event-time T" or "what did we believe at record-time T," and the register answers each faithfully.

Tuning parameters

  • Temporal grain — how finely the two clocks are resolved (day, second, millisecond). Finer grain answers sharper as-of questions but multiplies versions and storage.
  • Provenance depth — how much source detail each assertion carries. Rich provenance supports strong audit and later reconciliation but adds capture cost and bulk.
  • Correction visibility — whether superseded beliefs stay fully queryable or are archived. Full visibility maximizes auditability; archiving trims the working set at the cost of instant as-of access.
  • Bitemporal scope — which entities warrant two clocks versus one. Applying bitemporality everywhere is expensive; reserving it for facts that get corrected or audited keeps it proportionate.
  • As-of default — whether queries default to "latest belief" or require an explicit record-time. Defaulting to latest is convenient but invites the very time-collapse the register exists to prevent.

When it helps, and when it misleads

Its strength is that it makes belief a first-class, queryable dimension: restatements, audits, disputes, and "what did we know and when" investigations become exact rather than reconstructed from memory. The valid-time / transaction-time distinction it implements is the established model for exactly this.[1]

It misleads when the two clocks are confused or when one is silently used for the other — sorting by record time and calling it chronology, or answering an as-of-belief question with event-time data, produces authoritative-looking nonsense. The register is also heavier than a single-timestamp log and tempts over-application; not every fact needs two clocks. And it records what was asserted, not what was true — a well-provenanced assertion can still be wrong; resolving which of several conflicting assertions to trust is a separate job. The discipline is to keep the two clocks rigorously distinct, always state which axis a query runs on, and reserve bitemporality for facts where knowledge genuinely evolves.

How it implements the components

Bitemporal Event Register realizes the knowledge-over-time side of the archetype — the components that separate occurrence from recording and trace each assertion to its source:

  • event_time_and_record_time — its defining structure: two distinct clocks on every fact, enabling as-of queries on either axis.
  • provenance_record — each assertion carries who recorded it and from what source, so belief is traceable.

It records two clocks and provenance but does not itself correct or reconcile: issuing a correction as an appended reversing event is Compensating-Event Correction, and weighing several conflicting sources to decide which to trust is Provenance-Weighted Event Reconciliation.

Notes

The register answers two questions that novices routinely merge: "what was true then?" and "what did we believe then?" These diverge precisely when a correction has landed — the storm's real damage (event time) was fixed on March 1, but the system's belief about it (record time) changed on March 20. Any report that does not say which of the two it is answering is ambiguous, and the ambiguity usually favors whoever is reading it.

References

[1] Bitemporal modeling distinguishes valid time (when a fact is true in the world) from transaction time (when the fact was stored in the database). The two-axis model is long-established in temporal-database research and is reflected in the temporal features of the SQL:2011 standard. ↩