Facts change. Spectron records when each fact was true, not only what the current value is.
Every active attribute and relation carries a validity interval:
valid_from— when the fact became true (often the extraction or correction time; document facts may use an effective date from the source).valid_until— when the fact ceased to be true.nullmeans still valid.
Together these fields power current-state reads, point-in-time reconstruction, and full correction history. The broader picture — system time, known time, and valid time — is in Tri-temporal model.
What temporal validity enables
Current state — default queries return attributes whose validity interval includes “now”.
Point in time — ask what was true on a past date (“what role did Alice hold in February 2025?”) using asOf or validity parameters on entity reads.
History — walk the supersession chain for a key to see every value it took, in order.
Temporal language in chat — when a turn says “I became CEO in January 2025” or “I used to live in Berlin”, extraction sets or adjusts validity bounds where it can; unresolved dates may become uncertainty records instead of guessed timestamps.
How it differs from deletion
Closing a fact with valid_until is not the same as deleting it. The record stays in the store for audit and time-travel queries; it simply drops out of “what is true now”.
| Operation | Delete-and-replace | Temporal validity |
|---|---|---|
| Apply correction | Old value gone | Old value closed; new value opened |
| Query current state | Latest row wins | Filter by open validity interval |
| Query past state | Often impossible | Filter by interval containing the instant |
| Undo a bad correction | Restore from backup | Reopen prior value in the chain |
Interaction with supersession
Supersession tracks why a value changed (replaced by a newer belief). Temporal validity tracks when each value was active. A correction updates both: the old attribute gets valid_until and a link to its replacement; the new attribute gets valid_from and a link back. See Reconciliation and supersession.
Correction path versus expiry path
Two situations set valid_until:
Correction — a conflicting new value supersedes the old one. The chain links old → new.
Expiry — a fact ends without a replacement (a promotion that lapses, a time-boxed assignment, an instruction that was revoked). valid_until is set directly — at extraction when temporal language supplies an end date, or via POST /forget / lifecycle operations when you expire memory explicitly.
Reading validity through the API
GET /entities/{type}/{name}— active attributes for an entity; optional temporal query params on the request.GET /entities/{type}/{name}/history/{key}— ordered supersession history for one key.POST /querywithas_of— belief-level recall at a past instant.
Field-level schema detail lives in Data model and schema for operators who manage SurrealDB directly.