Temporal knowledge graphs: tracking what changed and when

In this article

• Valid time versus ingestion time
• Why a single timestamp field is not enough
• Snapshots versus event history
• Why "what did the report say last quarter" questions break normal systems
• Restatements and how they get handled
• Slowly changing dimensions, compared
• What temporal modeling costs to maintain
• Where SIGNLD fits
• FAQ

Valid time versus ingestion time

Most business systems overwrite a value the moment it changes. A customer's account tier moves from "standard" to "enterprise," and the old value is simply gone. This works fine for an operational system, whose job is to reflect current state, but it destroys the historical record: there is no way to later ask what tier the account was in on the date a deal closed.

For the wider context, see our knowledge graph glossary of 40 terms.

Bi-temporal modeling fixes this by tracking two independent time dimensions for every fact. Valid time is when the fact was actually true in the business: the account was enterprise starting March 1. Ingestion time is when the system learned that fact: the change was recorded in the source system on March 4, three days after it actually took effect, because someone processed the paperwork late. These two dates are rarely the same, and treating them as one is where most historical reporting quietly goes wrong.

Once both timestamps exist on a fact, four distinct questions become answerable instead of one: what was true then, what is true now, what did we know then, and what do we know now. A single timestamp can only ever answer one of these.

Why a single timestamp field is not enough

A common shortcut is to add one "last updated" column and assume that solves history. It does not, because "last updated" conflates the two questions above. If a contract's discount rate is corrected six months in, a single timestamp cannot tell you whether the rate was actually different for those six months, or whether it was always correct and the record was simply wrong.

This distinction matters most in disputes and audits. If a customer disputes an invoice's rate, the business needs to know what rate was valid on the invoice date, not what the system displays today. A single timestamp answers "when was this row last touched," an ingestion-time question dressed up as a valid-time one, and the two frequently disagree.

Snapshots versus event history

There are two common approaches to preserving history, and they are not interchangeable. A snapshot approach copies the relevant data at fixed intervals, end of day or end of month, and stores each copy separately. This is simple to build and query, but it only captures state at the snapshot boundary, and anything that changed and reverted between two snapshots leaves no trace.

Event history takes the opposite approach: it stores every individual change as its own record, each with a valid-time range and an ingestion timestamp, and derives current state by replaying events up to a point in time. This captures everything snapshots miss, but requires more storage and more work to reconstruct a point-in-time view on demand.

In a temporal knowledge graph, event history is generally the more useful of the two because the graph's edges are naturally suited to carrying valid-time ranges, an edge between a Customer and a Tier can simply be marked valid from March 1 to whenever it is superseded, rather than requiring a separate snapshot table per entity type. Snapshots remain useful as a performance shortcut, a cached answer to "what did this look like on this date" that avoids replaying every event, but they should sit on top of event history rather than replace it.

Why "what did the report say last quarter" questions break normal systems

A common failure mode is the forecast reconciliation question: what did the pipeline look like when this quarter's forecast was made, versus what actually closed. Most CRM and reporting systems cannot answer this cleanly, because the pipeline view a person sees today reflects every subsequent update, stages moved, deals deleted, amounts corrected. The system shows current truth layered on top of the past, with no way to peel the layers apart.

This is a temporal modeling problem, not a reporting one. Answering it requires ingestion-time filtering: show every deal as it was known as of the forecast date, ignoring anything learned afterward. Without ingestion time recorded separately from valid time, a system cannot distinguish a deal already lost by the forecast date from one marked lost later that propagated backward into today's view. The two look identical with only one timestamp, and they mean very different things for judging forecast accuracy.

The same pattern shows up in board reporting, compliance reviews, and root-cause analysis: someone needs the belief state at a past date, not current state relabeled with a past date on it.

Restatements and how they get handled

Restatements, a source system correcting a past value after the fact, are the sharpest test of a temporal model. A finance team might discover in April that a February invoice was recorded wrong, and correct it. The naive fix, updating the February record in place, quietly rewrites history: any report already run against the old number becomes unreproducible, because that number no longer exists anywhere.

A properly temporal system instead adds a new fact: the corrected amount, with a valid-time range covering February, and an ingestion timestamp in April marking when the correction was learned. The original, incorrect fact is not deleted, it is marked as superseded. This means a report generated in March using the original number can be reproduced exactly as it was, while a report generated in May using the corrected number reflects the restated figure, and both are legitimately correct answers to two different questions: what the February close reported at the time, and what the restated books show now.

This matters beyond finance. Any correction to a past record, a misclassified transaction, a fixed entry error, a ticket reassigned after root-cause review, is a restatement, and the same logic applies: keep the original, add the correction, timestamp both, and let consumers choose the belief-at-the-time or corrected-truth version.

Slowly changing dimensions, compared

Data warehousing already has a well-known pattern for this: slowly changing dimensions, usually abbreviated SCD. A Type 2 slowly changing dimension keeps a full history of changes to a dimension row, each with a start and end date, functionally similar in intent to what a temporal knowledge graph does with valid time on edges.

The practical differences are in scope and mechanism. SCD Type 2 is implemented per table, in a schema designed in advance, and typically tracks valid time only, since most warehouse pipelines batch-process data without separately preserving when a fact was learned versus when it became true. A temporal knowledge graph applies the same idea across every entity and relationship without a separate schema decision for each, and more naturally carries both valid time and ingestion time because facts arrive from many source systems on their own schedules, not one nightly batch.

Neither approach makes the other unnecessary. A warehouse with well-implemented SCD Type 2 is already doing real temporal modeling, and a graph consuming from it inherits that valid-time history. The graph mainly adds ingestion-time tracking and extends the pattern to relationships, not just properties.

What temporal modeling costs to maintain

Keeping both timestamps is not free. Every fact effectively doubles in metadata, and queries about current state need to filter out superseded history rather than reading the latest row. The payoff concentrates in specific, recurring situations, audits, forecast reconciliation, disputes, restatements, rather than in everyday reporting, where current state is usually all anyone needs.

The practical approach is selective: facts feeding financial reporting, contractual terms, and anything likely to be disputed or audited are worth the overhead, while low-stakes operational data can stay untracked without meaningful loss.

Comparison: point-in-time snapshot vs. event history vs. SCD Type 2 vs. bi-temporal graph

Aspect	Point-in-time snapshot	Event history	SCD Type 2 (warehouse)	Bi-temporal knowledge graph
Captures valid time	Only at snapshot boundary	Yes, continuously	Yes, per dimension row	Yes, on every fact
Captures ingestion time	Rarely	Sometimes	Rarely	Yes, separately from valid time
Handles restatements cleanly	No, snapshot must be rebuilt	Yes, add a new event	Partially, requires reprocessing	Yes, superseded fact retained
Storage overhead	Low to moderate	Higher, grows with change frequency	Moderate	Higher, offset by query flexibility
Scope	Whatever was snapshotted	Whatever events are logged	Per-table, schema-defined	Cross-system, entities and relationships

Where SIGNLD fits

SIGNLD's knowledge graph tracks both valid time and ingestion time for facts pulled from connected systems, so a Decision Brief can be traced back to exactly what was known, and when, when it was generated. Because connections are read-only across 800+ integrations, facts arrive continuously as source systems change rather than through a single scheduled batch, which makes ingestion-time tracking a natural part of how the graph is built rather than an added-on feature. This is part of how it works, detailed further at how it works, and it is one reason a past Decision Brief can be reproduced later using the same evidence it originally cited. See related terms in the knowledge graph glossary.

Related reading in this series: What is an ontology, and does your business need one and Who owns the Knowledge Graph: governance without a governance committee.

Key takeaways

• Most business systems overwrite a value the moment it changes.
• There are two common approaches to preserving history, and they are not interchangeable.
• Restatements, a source system correcting a past value after the fact, are the sharpest test of a temporal model.
• Valid time is when a fact was true in the real world.
• Queries asking about current state generally filter out superseded history, which adds a small amount of overhead but is rarely noticeable.

FAQ

What is the difference between valid time and transaction time?

Valid time is when a fact was true in the real world. Transaction time, also called ingestion time, is when the system recorded that fact. A change can be valid starting on one date but not recorded until days or weeks later, and bi-temporal modeling keeps both dates separately.

Do I need a temporal knowledge graph if I already have SCD Type 2 dimensions?

Not necessarily. Well-implemented SCD Type 2 already preserves valid-time history for warehouse dimensions. A temporal knowledge graph adds ingestion-time tracking and extends history to relationships across systems, which is most valuable if you regularly need to reconstruct past belief states, not just past values.

How does temporal tracking handle a deleted record?

Rather than physically deleting the record, a temporal system marks it as no longer valid from a given date forward, while keeping the original fact intact for anything valid before that date. This preserves the ability to answer questions about the period before the deletion happened.

Does temporal modeling slow down everyday queries?

Queries asking about current state generally filter out superseded history, which adds a small amount of overhead but is rarely noticeable. The cost shows up more in storage growth over time than in everyday query speed.

Is this the same thing as data lineage?

No. Lineage tracks where a fact came from and how it was transformed. Temporal modeling tracks when a fact was true and when it was learned. A system can have strong lineage and no temporal tracking, or the reverse, though the two are often built together.

Try SIGNLD free to see how facts in your own systems get tracked over time, or see how it works.