Core concepts · 31 / 42

Bi-temporal validity

Separate when a fact was true from when the system recorded it, with the exact Northsun substrate scope and public API boundary.

Bi-temporal modeling separates valid time—when something applies in the world—from transaction time—when a recorded version was current in the system. Northsun limits this substrate to evidence_refs and locked_facts; it does not make memory_objects bi-temporal.

Two different questions

Suppose a policy changed on March 1 but the system learned about it on March 5:

  • “What was valid on March 3?” is a valid-time question.
  • “What did the system have recorded on March 3?” is a transaction-time question.

A single updated_at field cannot answer both without ambiguity.

Table semantics

locked_facts stores caller-supplied valid_range and versioned tx_range values. Evolution and correction close the old transaction-time range and insert a successor. get_fact_as_of has a transaction-time form and a two-clock form that takes both a valid-time and a believed-at timestamp; callers needing both world time and knowledge time use the two-clock form.

evidence_refs stores t_valid, nullable t_invalid, and ingestion_time. A corrective migration generates:

valid_range = [t_valid, t_invalid or infinity)
tx_range    = [ingestion_time, infinity)

The evidence table does not share the locked-fact transaction-overlap constraint. Shared names do not imply identical mutation behavior.

Evolution versus correction

  • Evolution: the world changes. The old value may have been valid before the change.
  • Correction: the recorded value was wrong. The earlier belief is preserved for audit, while the corrected successor retains the applicable valid-time range.

Preserving recorded versions makes these cases distinguishable. It does not imply infinite retention or override deletion obligations.

What this enables—and what still needs proof

The substrate can support as-of fact queries and supersession inspection. An end-to-end replay claim additionally needs the exact served context, policy version, action, output, tenant controls, and deployed runtime behavior. Those are separate artifacts.

There is no direct facts or evidence endpoint in the frozen public REST trio. Use Locked facts and Evidence references to understand the substrate, and API reference for callable behavior.