The same events, a different story

Consider three remembered events from the migration history:

A = benchmark detects SQLite contention
B = team decides to adopt PostgreSQL
C = PostgreSQL deployment completes

As an unordered set, {A, B, C}, the system knows all three happened. As a trajectory, A → B → C, it can say something stronger: the benchmark preceded the decision, and the decision preceded the deployment. Now hold the contents constant and change only the ordering to B → A → C. Nothing was added and nothing was removed, yet the benchmark can no longer have motivated the decision. It may corroborate the decision, strengthen confidence in it, or justify retaining it — but a later measurement cannot have been the reason for an earlier choice.

This chapter tests one hypothesis: a memory system is not only a collection of remembered states; for some questions, the ordered transitions between those states are themselves part of what must be remembered. A set of events records what occurred. A trajectory records how one state became another. The experiment asks whether that difference is measurable: hold the memories constant, change only their temporal structure, and check whether the system changes its conclusion exactly when it should — and remains invariant when ordering should not matter.

The hypothesis is stated as a prediction, not a fact. Everything that follows either earns it or narrows it.

Time is not metadata

An early version of this chapter treated time as annotation: attach timestamps to memories, sort by them, prefer the newest. That design fails in two directions at once.

First, timestamps without transition semantics cannot answer historical questions. The project used SQLite in April and PostgreSQL after the July cutover; both statements are true of different times. Sorting passages by date retrieves the right documents for either question, but retrieval is not resolution. Something must still decide which retrieved state held at the requested time, and a timestamp sort is a ranking, not a model of change.

Second, timestamp order alone cannot carry authority. The Redis history makes the point: session-040 floats the idea, session-044 observes the working set fits in memory, and adr-009 decides against introducing Redis. The decision wins because it is a decision, not because it is last. Reverse the pattern — a standing decision followed by later discussion that revisits it without reopening it — and newest-first ranking prefers chatter over commitment. When something was said and what it did must be interpreted together, which is the interaction Chapters 4 and 5 return inside the temporal problem.

The rebuild therefore starts from the distinctions the previous draft already earned — history versus position, supersession versus contradiction, correction versus revision, validity as an interval, recency as a baseline rather than a solution, uncertainty where conflict is genuinely unresolved — and gives them machinery they previously lacked: an explicit representation of transitions, tested by permutation.

A set is not a trajectory

The chapter’s representation uses four objects.

State is what currently holds within some scope: event-store.backend = SQLite. Event is something that may change, establish, revise, record, or describe state: a benchmark, a decision, a deployment completing. Transition binds the two: state-before --event--> state-after. Trajectory is an ordered or partially ordered sequence of transitions:

S0 --E1--> S1 --E2--> S2 --E3--> S3

A weak memory retains the endpoint: PostgreSQL is current. A stronger temporal memory preserves how the system got there:

SQLite current
    ↓ contention observed (session-014)
SQLite [problem known]
    ↓ PostgreSQL selected (adr-007)
SQLite [PostgreSQL planned]
    ↓ deployment completed
PostgreSQL current

The second representation answers more questions: what was current in April, what changed, what happened immediately before the transition, which evidence could have informed the decision. Whether that extra machinery is worth its cost is the experiment’s question, not this section’s assumption.

When order changes meaning

For some events, applying A then B reaches a different state than applying B then A. PROPOSE → ACCEPT is not ACCEPT → PROPOSE. DECIDE → REVOKE leaves no standing commitment; REVOKE → DECIDE leaves a live one. CLAIM → CORRECTION revises understanding; CORRECTION → CLAIM reads as a claim made after its own correction, which is incoherent. TASK_CREATED → TASK_COMPLETED closes a loop that the reverse order never opened.

The word for this property is non-commutativity, used here only as shorthand: order changes the resulting state. The chapter does not develop the algebra further because the experiment needs the phenomenon, not the formalism.

The migration fixture exhibits it directly. In the canonical order, the June benchmark is an admissible antecedent of the June decision: it precedes the decision, so it could have motivated it. In the permuted order, where the decision predates the benchmark, the same benchmark with the same contents is admissible only as corroboration. The frozen E8-B run checks exactly this pair and passes: the admissibility verdict changes while the event set is identical. Contents held constant, structure changed, conclusion changed — the predicted effect, measured rather than asserted.

When order should not matter

Sensitivity without discrimination is superstition. Swapping two independent events — a README update and an unrelated CSS fix — must leave the migration conclusions untouched. A system that becomes hypersensitive to ordering, twitching at every permutation, has not learned time; it has learned to hallucinate significance in sequence numbers.

The suite therefore scores both directions as first-class metrics. Order-sensitive accuracy asks whether the answer changed correctly when a labelled permutation should change it. Order-invariant stability asks whether the answer stayed put when a labelled permutation should change nothing. The E8-C run swaps the independent pair and checks three subjects under all five resolver conditions; the temporal resolver is stable on every one. A useful temporal memory is sensitive to order without being superstitious about it.

Before does not mean because

Temporal order rules some causal explanations out more easily than it proves others. If the benchmark postdates the decision, it cannot have been the decision’s antecedent reason — that exclusion is solid. But if the benchmark predates the decision, precedence alone does not establish that it caused the decision. The decision record, its stated rationale, and the evidence lineage must do that work.

This restraint shapes the Chapter 7 integration. Chapter 7 records which evidence supports which claim; Chapter 8 asks an additional question of each support edge: is the evidence temporally admissible for the role it is claimed to play? A June benchmark can support the proposition that SQLite had contention, and it can support a June decision as an antecedent — but a July benchmark offered as the reason for a June decision fails admissibility while remaining perfectly good corroboration. The implemented check distinguishes three relation families: MOTIVATED_BY requires precedence, CORROBORATED_BY permits later evidence, and CORRECTED_BY requires the correction to follow its target in record time. Unknown relation kinds abstain rather than invent constraints. The E8 suite verifies both halves: a later benchmark is rejected as antecedent and accepted as corroboration. Support says why a claim should be believed; time says whether the story about when is coherent. Neither collapses into the other.

There is more than one clock

Real histories conflate at least five meanings of time, and the experiment keeps them distinct even where it does not implement all five as independent axes:

• event time: when the represented event occurred;
• valid time: when a state actually held;
• record time: when the memory system learned it;
• decision time: when a commitment was made;
• effective time: when that commitment began changing the relevant state.

The minimum serious model is bitemporal: valid time crossed with record time. Suppose the July cutover reaches the memory system only in August. Then two questions with different correct answers become askable: what was actually true on 20 July (PostgreSQL), and what did the system know on 20 July (SQLite, if the cutover was still unrecorded). A single-axis interval cannot represent both without corrupting one. The query interface therefore carries an explicit standpoint:

state.bitemporal(subject, valid_at=..., known_at=...)

Given what was known by August, what was valid in July — versus what was believed at the time. The E8-E run exercises the matched pair on the frozen log and passes: the retroactive answer reports PostgreSQL, the historical-standpoint answer refuses to pretend the system knew it then.

Two related separations matter. A decision exists before it takes effect: the September migration decision names a release-gated effective date, and between decision and release the correct current answer (SQLite) differs from the correct planned answer (PostgreSQL). The E8-F run checks both sides of the effective boundary and passes. And standby questions of agency — current for whom — are deliberately deferred: the v0.1 standpoint is the project’s, with agent and task standpoints designed as extension points rather than implemented machinery. The chapter claims no more multi-agent semantics than it runs.

Distributed histories do not arrive neatly

With several independent publishers, ordering ambiguity is not a thought experiment but the normal case. The demonstration uses three publishers — benchmark, decisions, deployment — each with its own sequence numbers, exchanging messages through a ZeroMQ forwarder and into a recorder. The recorder preserves both the semantic order and the arrival order, because their difference is the demo’s entire point.

ZeroMQ is transport, not memory, and the chapter treats it accordingly. The relevant documented behaviours, verified against the ZeroMQ RFC 29 publish-subscribe specification, the ZeroMQ Guide, and the pyzmq documentation before any code was written, are: PUB/SUB topic filtering with anonymous subscribers; the XSUB/XPUB proxy pattern that collects from many publishers and forwards to subscribers; fair-queued interleaving across publishers with no global order guarantee; the slow-joiner effect, where subscribers that connect after publishing starts miss early messages; and high-water-mark queue limits, past which messages are dropped rather than queued. None of these is a memory semantic. Together they are the reason a memory system cannot mistake delivery order for historical order: with fair queueing across publishers and no cross-publisher ordering guarantee, arrival order is an observation about the network, and temporal order belongs in the model.

The implemented topology follows the documented pattern: PUB publishers connect to the proxy’s XSUB frontend, the SUB recorder connects to the XPUB backend, and a readiness gate — the recorder subscribes before any publisher sends — replaces the customary startup sleep as the correctness mechanism. (A short settling pause remains so subscription propagation is not racing the first send; it governs timing, not correctness.) Publishers, proxy, and recorder are separate concerns behind a transport abstraction, with an in-memory transport serving the deterministic test suite so temporal semantics never depend on socket behaviour. PUB/SUB carries no durability: everything the memory layer believes comes from the append-only log described next, never from a socket.

The live run makes the separation visible. Semantic order in the frozen capture:

ch8-benchmark → ch8-decision → ch8-deploy

Arrival order at the recorder, under controlled send delays:

ch8-deploy → ch8-benchmark → ch8-decision

Resolved temporal order after replay:

ch8-benchmark → ch8-decision → ch8-deploy

Naive arrival-order processing would reconstruct the history backwards, reading the deployment as the earliest event. The temporal engine recovers the semantic order from event times and explicit causal parents. One honest qualification belongs here: in this fixture the arrival-order resolver still lands on PostgreSQL as the current value, because the decision event itself carries that value. It reaches the right value through the wrong trajectory — replaying the deployment before the decision that authorised it — which misattributes the transition even where the endpoint coincides. The failure class is arrival order confused with event order, and it shows in the reconstructed rationale rather than the final string.

Build the event stream

The durable layer is deliberately unglamorous: newline-delimited JSON over an append-only log, indexed in memory. No database server, no model endpoint, nothing that cannot be inspected with standard tools. Each line pairs a versioned event envelope with recorder metadata:

{"envelope": {...}, "received_at": ..., "ingest_seq": N}

The envelope (temporal-event-v0.1) carries identity (event_id, plus source_id with a per-source sequence number so each publisher’s local order survives interleaving), kind (a small generic vocabulary: fact established, observation recorded, decision made, state changed, revision, correction, retraction, task created, task completed), subject and fluent value, the three time axes (event time, record time, effective validity interval), explicit relations (causal parents, supersession pointers, correction pointers, evidence references into Chapter 7 lineage), and a schema version. Every field earns its place: identity plus sequence detects gaps, the time axes drive bitemporal queries, the relations drive admissibility checks, and the version makes reinterpretation visible.

Recorder metadata is strictly observational. received_at and ingest_seq record when this system saw the message; they never substitute for when the event occurred or when its state became effective. Out-of-order arrival must remain ingestible, so referential checks (a causal parent not yet seen) defer to health reporting rather than rejecting the write — a deliberate choice, since a transport that refused disorder could never observe it. Corrections append; they never edit an earlier line. What was originally recorded and what was later learned coexist, which is what makes the bitemporal queries possible at all.

Health reporting is structural, and the chapter refuses to oversell it: event and source counts, sequence gaps, duplicate identifiers and sequences, unknown references, temporal-causality violations, projection version and drift, last ingest. A clean report means the history is well-formed. It does not mean the history is true.

Reconstruct the trajectory

The temporal engine is a deterministic reducer with no model calls:

new_state = reduce(old_state, event)

Replay applies it in temporal order — causal parents first, then event time, then a stable identifier order for genuinely concurrent events. The rules are generic over subjects, keys, values, validity, and relations; no rule names PostgreSQL, SQLite, or any fixture literal. Facts establish state, observations enrich the record without moving it, decisions record intent without changing current state until their effective transition arrives, revisions supersede going forward, corrections append revised understanding while preserving the original record, and unknown kinds are recorded without being applied.

Two architectural choices from the concepts analysis are implemented and priced rather than merely discussed. Current belief is a view over the log, and the suite runs both maintenance policies: a computed resolver that replays at query time (always fresh, cost growing with history) and a materialized projection maintained during ingest (cheap lookup, with invalidation complexity). Late arrivals re-apply from the insertion point, and a rebuild command regenerates the projection from the log; the E8-J run verifies all three digests match, including across a correction. The measured costs, on synthetic histories up to ten thousand events, show replay time growing linearly (about two milliseconds at ten thousand events), current-state queries in the low milliseconds under either policy, and disordered ingest paying suffix-replay proportional to the disorder distance — quadratic in the pathological all-disordered case. The honest reading: materialized belief wins for current-state lookups when ingest is mostly ordered, and its advantage is a performance optimisation with a measured price, not a semantic improvement. No reader or language model participates in any of this; a model may later render temporal answers into prose, downstream of semantics it must not reinterpret.

Partial order is represented rather than papered over. Where two events share a timestamp and no causal edge connects them, the resolver reports their relative order as unknown — and the E8-H run scores an invented total order as failure. With several publishers and imperfect clocks, “A and B both preceded C; their order is unknown” is a correct answer the machinery must be allowed to give. Vector clocks were researched and deferred: source sequences plus explicit causal parents resolve every ambiguity the controlled fixtures contain, and heavier machinery waits for a demonstrated need. Likewise the interval reasoning uses a small subset of Allen’s relations (before, meets, overlaps, during, equals) sufficient for validity-interval overlap and bounded-unknown answers (“between 12 and 18 June” scores above invented precision); the full thirteen-relation propagation network is reserved.

Four memory models

The experiment compares four conditions over identical frozen logs — the benchmark ladder’s ablation discipline applied to time:

• T0 bag ignores every temporal field and answers from event presence alone;
• T1 arrival resolves by newest arrival, the naive recency baseline;
• T1b event-time sorts by event time and takes the latest, repairing transport disorder without modelling transitions;
• T2 ordered replays event-time order through the reducer’s transition semantics;
• T3 temporal adds valid/record standpoints, effective dates, and supersession/correction semantics.

Event-time sorting is deliberately isolated as its own condition: if it solved everything, the chapter’s conclusion would be that richer trajectories were unnecessary, and the design invites that verdict.

Measure it

The E8 suite (E8-A through E8-J, plus a second-domain permutation) ran deterministically with zero model calls; both the emulated-disorder and live-ZeroMQ captures are frozen under experiments/benchmark/runs/ with manifests recording code commit, schema, fixture, reducer and projection versions, transport mode, and log digests. Each dimension is reported separately — there is no single temporal score. Results, quoting the frozen artifacts rather than the design intentions:

Recency is treated fairly here, and on clean monotonic histories it wins: every condition identifies PostgreSQL as current. The trajectory machinery earns its keep everywhere else. Order-sensitive permutation (E8-B): the benchmark’s admissibility as the decision’s antecedent flips correctly between canonical and permuted orders, 1.0. Order-invariant stability (E8-C): independent swaps move nothing under the temporal resolver, 1.0. Arrival disorder (E8-D): the live capture above resolves to semantic order while recording arrival separately. Late-arriving knowledge (E8-E): actual-versus-known standpoints diverge correctly, 1.0. Future-effective decision (E8-F): current versus planned differ on the right sides of the boundary, 1.0. Correction (E8-G): the original benchmark record survives alongside its correction with the pointer intact, 1.0; the revision contrast case keeps forward endorsement separate from backward record repair. Partial order (E8-H): the resolver refuses the invented total order, 1.0. Sequence gap (E8-I): the skipped sequence number surfaces GAP_DETECTED with INCOMPLETE_HISTORY rather than confident reconstruction, 1.0. Computed versus materialized (E8-J): projection, correction propagation, and rebuild digests all match, 1.0. Supersession accuracy on the revision fixture: 1.0. The temporal-causality violation rate on the clean fixtures is 0.0, and the check itself is verified by a dedicated test that plants a future-dated parent.

The failures are as instructive as the passes. Bag, arrival, and event-time conditions all answer the April historical question wrong (0.0): without transition semantics and a valid-at standpoint, even perfectly sorted timestamps cannot reach into the past correctly — event-time sorting repairs transport disorder but still cannot model when states held. The suite also records a strategic-vagueness control: where the log determines an exact date, bounded-unknown hedging is penalised, so uncertainty scores only where the record actually leaves it. A second domain (a feature-flag incident history) confirms the reducer operates on generic subjects rather than fixture literals: reordering the incident around the flag toggles admissibility exactly as the migration case does, while precedence is never read as proof of contribution.

What did time actually buy us?

The pre-registered verdict types resolve as Type A on fixture evidence: ordered and bitemporal state solves permutation, correction, late-arrival, and effective-time cases that bag and recency approaches fail, while remaining invariant on irrelevant swaps. The demotion clauses are recorded alongside the claim. The evidence is fixture-scoped: a deterministic ledger, nine to twelve events per case, no language-model reader, no real-corpus transfer. Type B (timestamps suffice) is rejected for historical and standpoint queries but explicitly sustained for clean current-state queries — recency is the right tool where change is monotonic and honestly recorded. Type C (bitemporal machinery only for specialist cases) describes part of the result fairly: late knowledge and future-effective scheduling are specialist shapes, and the architecture selects temporal machinery by failure class rather than applying it uniformly. Type D (transition semantics too brittle) is rejected insofar as the reducer’s generic rules cover two domains with no fixture-specific answer rules, but the brittleness warning stands as the reason the ontology stays small. Type E is confirmed as stated: materialized state helps current-state performance and its staleness is managed by derivation-from-log plus rebuild equivalence, with the suffix-replay cost measured above.

If a broader principle survives, it is this: for some memory tasks, preserving events without preserving their temporal relationships is insufficient — the same event set implies different state, rationale, and expectations under different valid orderings. Time, in state-changing histories, is part of the memory representation rather than annotation on it. And the complementary discipline: a memory is sometimes not an item but a transition — what the system must retain is how one state became another. Both lines are offered as results of the permutation experiment, bounded by its fixture scope, not as slogans.

What remains unfinished

The temporal layer hands Chapter 9 a richer state model than the one this chapter inherited. Question 5 — what did we leave unfinished — requires distinguishing intentions created from transitions completed: a planned migration with an effective date that arrived without its deployment is detectable only because the log records both the commitment and the absence of its expected transition. Once memory can reconstruct how state changed through time, the next problem is detecting expected transitions that never happened.

Deferred explicitly: agent- and task-relative standpoints, full vector-clock causality, the thirteen-relation interval network, write-path integration with the Chapter 4 graph (the read-only temporal path validator is the current boundary), any new Nexus routing capability, and real-corpus validation of every claim above. The trajectory-based processing observed in current reasoning systems — process supervision, multi-step tool loops, reflection trajectories — is noted as contextual analogy only: it shows that capable systems increasingly reason over intermediate states, and it establishes nothing about long-term memory architecture. That case had to be earned here, on the ledger, one permutation at a time.

Research foundations

Temporal question answering supports treating truth as time-indexed: TimeQA requires reasoning over facts holding at different times, SituatedQA makes temporal context part of correctness, StreamingQA evaluates adaptation to arriving knowledge, and LongMemEval tests updates across sessions. The lookup key in all four is effectively topic plus temporal standpoint, which this chapter makes explicit as valid and record time.

The deeper foundations are older. Lamport’s ordering of distributed events establishes that happens-before is a partial order and that total orderings are non-unique completions — the reason the resolver refuses to invent A-before-B. Allen’s interval relations supply the validity-interval vocabulary. Kowalski and Sergot’s event calculus provides the initiate/terminate pattern behind the reducer. Snodgrass and Ahn’s taxonomy of time in databases contributes the valid-versus-transaction-time distinction behind the bitemporal model. Transport behaviour follows the ZeroMQ publish-subscribe specification, the ZeroMQ Guide, and the pyzmq documentation. Trajectory-based computation in current AI systems is cited as related architecture, not as evidence for the memory thesis.

References

• Leslie Lamport, Time, Clocks, and the Ordering of Events in a Distributed System (1978).
• James F. Allen, Maintaining Knowledge about Temporal Intervals (1983).
• Robert Kowalski and Marek Sergot, A Logic-Based Calculus of Events (1986).
• Richard T. Snodgrass and Ilsoo Ahn, A Taxonomy of Time in Databases (1985).
• ZeroMQ RFC 29: Publish-Subscribe; ZeroMQ Guide; pyzmq documentation (docs).
• TimeQA: A Dataset for Answering Time-Sensitive Questions (2021).
• SituatedQA: Incorporating Extra-Linguistic Contexts into QA (2021).
• StreamingQA: A Benchmark for Adaptation to New Knowledge over Time (2022).
• LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory (2024).
• Bhuwan Dhingra et al., Time-Aware Language Models as Temporal Knowledge Bases (2022).