Bi-temporal facts, explained through a voice interaction

“Bi-temporal” becomes practical when a caller says, “Actually, move the appointment to Friday.” The system now needs to distinguish a change in the world from a change in what it recorded.

That distinction is useful for audits, corrections, and later agent decisions. It is also easy to overstate. In Northsun, the full bi-temporal model applies specifically to evidence_refs and locked_facts—not to every stored memory and not automatically to every public response.

Two timelines answer two questions

Bi-temporal records preserve two independent time dimensions:

• Valid time: when a claim applies in the world.
• Transaction time: when the system held that recorded version.

Suppose an appointment was booked for Thursday on Monday. On Wednesday, the caller moves it to Friday.

If Friday is a normal change, Thursday can remain valid until the change takes effect and Friday can become valid afterward. If “Thursday” was entered incorrectly on Monday, a correction can record that the system believed the wrong value until Wednesday even though it was never valid in the world.

Those are different histories. A single updated_at field cannot represent both without ambiguity.

Evolution and correction are not the same operation

An evolution says the world changed: the old value was valid, then a new value replaced it. A correction says the recorded belief was wrong: the transaction history should preserve that the system held it, while the valid-time history reflects the corrected claim.

Northsun's locked-fact substrate supports assertion, evolution, correction, supersession, and as-of lookup. Earlier versions remain linked rather than being silently rewritten.

That substrate can support questions such as:

• What appointment date was valid at the time of the call?
• What value had the system recorded when the agent answered?
• Which evidence reference supported that version?
• Was the later change an evolution or a correction?

The D3 scope is exact

Northsun's locked D3 decision assigns the full valid_range plus tx_range model to two fact-bearing tables:

• evidence_refs
• locked_facts

memory_objects are not bi-temporal. Their ingestion timestamp is informational and must not be treated as transaction time. Historical fact reconstruction routes through evidence and locked facts, not through embedded memory objects.

This matters because “Northsun is bi-temporal” can otherwise imply more than the implementation supports. The accurate claim is that Northsun has bi-temporal evidence and locked-fact substrate with an explicitly bounded scope.

What an as-of query can establish

An as-of query evaluates both clocks for a tenant, entity, and fact key. Conceptually:

SELECT fact_value, evidence_ref_id
FROM locked_facts
WHERE tenant_id = $1
  AND entity_id = $2
  AND fact_key = $3
  AND valid_range @> $world_time
  AND tx_range @> $knowledge_time;

The two timestamps may be equal during a simple replay, but they answer different questions. Keeping them separate prevents an evaluator from accidentally asking what is true now when the real question is what the system knew then.

Substrate is not deployed behavior

Repository migrations and procedures prove that Northsun can represent and query the two-timeline fact model. They do not, by themselves, prove that:

• every caller-memory response contains locked facts or evidence references;
• the frozen public REST trio includes a direct facts endpoint;
• every agent action can be replayed end to end; or
• a specific deployed tenant has exercised correction and reconstruction successfully.

The frozen caller-memory REST API does not expose a direct facts or evidence endpoint. Customer-visible governed recall requires the serving path to select the applicable context, attach the right evidence and temporal state, and demonstrate that behavior under real failure cases.

That is the boundary between architecture and product proof: the substrate makes historical belief representable; a controlled runtime test establishes what a customer actually receives.

How to evaluate the claim

A useful proof exercise is to create one controlled fact, evolve or correct it, then query the earlier and later knowledge times. Preserve the tenant, entity, fact key, evidence reference, and timestamps used in the test. Separately inspect the context packet delivered to the agent.

If both checks pass, you have evidence for the substrate and the serving behavior. If only the database check passes, describe it as substrate proof.

Next steps

• Read the deeper bi-temporal memory explainer.
• See why memory becomes a context-control problem.
• Use the glossary for evidence, locked-fact, and temporal terms.
• Start from the Northsun introduction for the live-versus-beta boundary.

Choose Northsun as your agent memory layer.