Two clocks

A record with one clock has to rewrite its past whenever it learns something late. Syderial keeps two clocks for every entry.

Clock	Field	Meaning	Set by
Valid time	valid_from, valid_to	When the claim applied, according to its source.	The entry, from its evidence.
Recorded time	recorded_at	When the record learned it.	Syderial, at posting.

The research literature calls recorded time transaction time.

Figure 1. The failure of V-204 on both clocks. The adjustment moves it earlier in the world, to 22:40 on 10 March, and posts it later in the record, on 14 March. The earlier entry is unchanged.

Two questions, two answers

• What applied on 11 March, according to the sources? Read by valid time. After the adjustment, the record says V-204 was failed from 22:40 on 10 March, on the authority of the principal who posted the adjustment.
• What did we know on 12 March? Read by recorded time as of 12 March. The record had entry 7Q4N-0193 only, a failure observed on the morning of 11 March. Syderial posted the adjustment two days later.

Audits ask the second question: what did the agent know when it acted? A record with one clock can answer it only by keeping a separate history.

What this means for your application

• You never update an entry in place. You post a new entry, and both clocks of the old entry stay as they were.
• Syderial sets recorded_at. A client can’t backdate what the record knew.
• An entry can be valid from long before it was recorded, as when a person states a decision made last month.

Further reading

Bitemporal Claims: Separating Validity from Knowledge shows why two clocks are enough, why one isn’t, and what auditability requires of a claim store.