Two clocks for an assessment: what applied, and what was recorded

An ordinary correction changes two different answers

On 10 September, an analyst records a report saying an undertaking became effective on 8 September. On 12 September, a correction says the effective date was actually 9 September. A briefing written on 11 September may therefore differ from one written on 13 September even though both ask about the same event. The system should be able to explain the difference.

Temporal database work distinguishes valid time from transaction time. Valid time concerns the modeled reality; transaction time concerns the period during which a record was current in the database. Snodgrass develops these distinctions and their combination in bitemporal tables. In contested analysis we should say “the recorded assertion applies,” not pretend a timestamp establishes what really happened. [1]

Make the two versions visible

An as-recorded query for 11 September returns v1. The same question with a recording cutoff of 13 September returns v2. Asked whether the undertaking applied on 8 September, the earlier snapshot says yes; the later snapshot says no. Neither result alone answers whether the source was reliable or whether a qualified reviewer accepted its interpretation.

A conflicting second source is not automatically a correction. If another participant disputes the effective date, retain both attributed claims with their evidence and review state. Supersession should describe an explicit replacement decision or source correction, not quietly erase disagreement.

The query needs both dimensions

Here valid_during is a daterange and recorded_during is a tstzrange. PostgreSQL provides containment, overlap, and explicit inclusive or exclusive range bounds. It does not make this application bitemporal automatically: the write path must maintain versions and recording intervals consistently. A date-granularity claim should not acquire invented second-level precision merely because the database supports timestamps. [2]

An atomic correction can close the current recording interval and insert its successor, while an audit log retains the operation. An append-only implementation can instead derive interval ends from later events. Either approach must prevent overlapping current versions caused by concurrent writes and distinguish an unknown endpoint from an assertion of indefinite validity.

SELECT claim_id, source_revision, interpretation
FROM claim_versions
WHERE valid_during @> DATE '2026-09-08'
  AND recorded_during @> TIMESTAMPTZ '2026-09-11 12:00:00+00'
  AND review_state = 'accepted';

Do not collapse the other clocks

The event date, document publication date, ingestion time, reviewer decision time, and effective interval can all differ. A late-arriving document must not be backdated into an earlier database snapshot. Record its earlier publication date separately. An import can preserve the exporting system’s history as attributed provenance while recording a new local ingestion event.

Uncertain dates need their own representation: an event may have happened within a window rather than throughout that window. OWL-Time supplies vocabulary for instants, intervals, durations, and ordering, but choosing the intended semantics remains the modeler’s responsibility. “Before” is not “caused,” and two overlapping intervals do not establish a common event. [3]

A historical answer depends on more than timestamps

Replaying a query with an old time filter is insufficient if entity aliases, access rules, or the ontology have changed underneath it. Pin the relevant record and rule versions. Retain the source revision and the activity that produced an interpretation; PROV-O provides terms for derivation, revision, and attribution. A historical view should reveal unavailable or redacted evidence rather than imply it was never present. [4]

Temporal filters may reduce the context sent to a model, but a short chronology can lose an exception or an unresolved interval. Recompute or invalidate summaries whose temporal dependencies change. Account for that update work separately from any per-question token saving.

Test time travel before relying on it

Use fixtures for late arrival, retroactive correction, contradictory sources, timezone changes, open endpoints, and concurrent updates. Check that a past recording snapshot remains stable after later corrections, while a current retrospective answer reflects the corrected record. Then ask a second analyst to explain why two answers differ.

For TACITUS, the intended boundary is a reviewed temporal record in DIALECTICA and an inspectable assessment in PRAXIS. Bitemporal completeness across capsule creation, import, and agent output remains development and evaluation work. The schema is a way to make errors observable, not evidence that we have eliminated them.

Day 8 must not borrow Day 15’s consultation

Event time, publication time, workspace recorded time and applicable intervals remain separate. The Group Q example adds a notice published on 20 August but captured on 22 August: publicly knowable and known in this workspace answer different questions. [5]