Knowledge in Motion: From Plato to Heraclitus

In the previous essay, I asked what would it take for a machine to know something.

Plato's account described knowledge as justified true belief. A computational system cannot implement truth in that philosophical sense, nor do these systems believe as humans do. But they can implement justification: they can preserve where a claim came from and show how that claim was derived.

For such systems, justification manifests from:

• Provenance — where did this claim come from?
• Proof — how was it established?
• Context — in what context is this relevant?

I represented this as a knowledge unit:

where S, P, and O are subject, predicate, and object; τ represents time; μ represents metadata; and J is the justification chain.

The earlier essay focused on provenance, proof and context. This one is about the element that is easy to add to a schema and much harder to honor in a production system: τ.

Heraclitus and Change

Heraclitus is associated with the thought that one cannot step into the same river twice. His own surviving fragment is subtler and more useful: "On those who step into the same rivers, different and different waters flow." Heraclitus understood change and the relentless march of time.

Plato's theory of timeless Forms was in part a response to Heraclitean theory of change. His worry was that if everything changes, nothing can be known. A computational theory of knowledge must answer both philosophers at once: it must justify its claims, as Plato demanded, while modelling a world in motion, as Heraclitus described.

An organization, asset, customer, policy, or network can persist over time while its properties, roles, relationships, and state evolve. That is the problem a knowledge system must solve for.

The Triple Without a Clock

Most machine knowledge is represented as triples that take the form:

Subject, predicate, object.

This is the basic form of RDF, a familiar graph edge, and the conceptual basis of many fact stores. But a bare triple has no built-in validity signal. The RDF abstract model treats graphs as timeless snapshots. Temporal information has long been added through modeling conventions and contextual structures, and RDF 1.2 — with triple terms, the standardization of the RDF-star work — now provides a sanctioned mechanism for annotating statements directly, including with temporal qualifiers.

When the world changes, a triple store usually has two weak options:

1. Overwrite the earlier assertion and lose history.
2. Keep multiple assertions without enough context to reconcile them.

Sooner or later, every serious system must answer questions such as:

• Who was the CEO in 2021?
• What policy applied when this decision was made?
• What did the system know when it generated this recommendation?
• Which evidence was available at that time?

These questions reveal two different clocks.

Validity time is when a claim held in the world. Assertion time is when the system learned, extracted, recorded, or accepted that claim.

The temporal-database community has studied this pair for decades under the names valid time and transaction time — the foundation of bitemporal modeling in TSQL2 and SQL:2011. The vocabulary here differs, but the discipline is the same, and the graph world has been slower to absorb it than the relational world.

A quarterly result may apply to July through September but not be filed until October. A correction in December can revise what the system believes about July. A system that stores only one time cannot distinguish what was true from what it knew at the time.

That distinction is the foundation of auditability. Without it, a system cannot reconstruct its prior beliefs or explain whether a past decision relied on information that was actually available then. This is no longer only an engineering virtue: under the EU AI Act, high-risk AI systems carry explicit logging and record-keeping obligations. Decision reconstruction is becoming a compliance requirement, and bitemporal knowledge is what makes it mechanically possible.

Retire Assertions; Do Not Erase Them

The engineering rule is simple:

When a fact is superseded, retire the assertion. Do not erase it. My earlier intuition was to version the fact, but that won't work without the help of the time dimension.

In a temporal graph, each important assertion carries a validity window and an assertion timestamp. When new evidence changes the current state, the previous assertion remains in the graph. Its validity interval is closed, and the new evidence is attached.

Note that "Status" in this table is a derived view, not a stored property. If "now" is an explicit query parameter — as it should be — then "active" is simply the answer to a temporal query evaluated at the present moment. Nothing in the graph is mutated to make it so.

The statements do not conflict because they answer different questions.

• "Who is CEO now?" returns Daniel Kim.
• "Who was CEO in 2021?" returns Jane Doe.
• "What did the system know in October 2022?" requires assertion time as well as validity time.

This approach produces three benefits:

1. Correctness: Historical and "as-of" questions become answerable.
2. Auditability: The graph preserves prior claims, their sources, and the evidence that superseded them.
3. Time-indexed justification: A document justifies a claim only after it enters the system's evidence base.

Provenance without time is incomplete provenance. It explains where a claim came from, but not whether the source was known, current, revised, or superseded when the system acted.

This also changes how we should handle terms such as reported, derived, disputed, and disproved. They should often be modeled as transitions rather than permanent labels. A claim may be reported, corroborated, qualified, defeated, or superseded over time. Temporal representation preserves that history rather than collapsing it into a single current status.

One honest caveat: the hard part in production is rarely storing two timestamps. It is deciding whether a new assertion supersedes, corroborates, or contradicts an existing one — a problem of entity resolution and conflict adjudication that no schema solves by itself. The temporal model does not make that judgment for you; it makes the judgment recordable, inspectable, and reversible.

From Time to Space

Time is one axis of change. Space, location, and topology are another — and they will be the subject of a future essay in this series. A brief preview of why they belong together:

In many enterprise domains, the two cannot be separated. A spatio-temporal graph can represent both the state of a system at a point in time and the changing relationships among its entities.

That enables queries such as:

Which assets were downstream of this pipeline during the interval in which pressure exceeded its safety threshold?

A purely temporal model can identify the period of elevated pressure. A spatial or topological model can identify nearby or connected assets. Only a spatio-temporal model can join those conditions.

This pattern appears across asset-heavy operations:

Knowledge representation and machine-learning research arrive at similar structures because many operational systems are graphs whose entities, relationships, and states change over time.

What Production Systems Need

The gap between this theory and most deployed AI systems is not exotic technology. It is discipline.

A time-aware knowledge system should:

• Capture both validity time and assertion time for consequential claims.
• Preserve superseded assertions rather than overwriting them.
• Treat "now" as an explicit query parameter.
• Retain source dates, event dates, reporting periods, effective dates, revisions, and document versions during ingestion.
• Add spatial or topological structure where operational questions require it.

Not every domain needs the most elaborate model. A practical maturity path is:

Knowledge Needs Dates

Plato reminds us that knowledge needs justification.

Heraclitus reminds us that the world changes while retaining enough continuity to be understood.

A computational theory of knowledge must satisfy both. Every claim should carry its provenance and proof, but it should also carry the interval in which it held and the time at which the system acquired its justification.

The point is not merely to include τ in the schema. Time must participate in ingestion, provenance, contradiction handling, reasoning, versioning, and query semantics.

Only then can a system move beyond storing facts and begin to represent knowledge in motion.

Read the earlier essay, Computational Knowledge and Reasoning: From Plato to Production Systems, or see how Context Graphs and reasoners work together in the DaaX technology overview.