Temporal Data
Our data architecture preserves time as part of company state rather than treating the latest value as the only truth.
Why current state is not enough
Businesses change continuously. Managers change, contracts are amended, pricing changes, customers move between statuses, employees change roles, and operating rules evolve.
A system that stores only current state can answer what is true now. It cannot reliably answer what was true when this happened.
Temporal representation
Where the workload requires it, our data layer can preserve:
- Effective dates
- Event timelines
- Version history
- State transitions
- Historical snapshots
- Changing relationships
- Point-in-time reconstruction
The distinction between event time and current state is operationally important.
A customer may currently be active while having been suspended three months ago. A manager may own an account today but not have owned it when a complaint occurred. A contract may contain one price now and a different price during the period being analyzed.
Flattening those states into the newest value introduces false history.
Point-in-time questions
Temporal state becomes especially important in causal or investigative workloads.
What changed before this metric changed?
Answering that requires more than retrieving documents that mention the metric. The system may need to reconstruct which employees, contracts, prices, customer statuses, or operating conditions were in effect before and after the change.
Likewise, asking what information was known at a specific point should not be answered using facts that became available later.
Relationship history
Relationships can also be temporal.
- Employee→ reports to →Manager
- Customer→ assigned to →Account owner
- Contract→ governs →Service
Each relationship may have an effective interval rather than a permanent truth value. We preserve temporal information where it materially affects reasoning instead of forcing historical company state into a timeless graph.
The result is a knowledge layer capable of distinguishing current truth, historical truth, and when the transition occurred. Without that distinction, an intelligent system can produce answers that are factually correct today and still wrong for the question being asked.
Scope
This page is the data-layer responsibility: capturing and storing time as it arrives — effective dates, version history, event timelines and state transitions — so that chronology survives ingestion instead of being flattened into a current-value snapshot.
Reasoning over that record is a separate concern. Reconstructing what the business looked like on a past date, and answering a question as of that date, belongs to Historical / Temporal State in the knowledge layer. If time is not captured here, that page has nothing to work with.