Loomworks temporal retrieval investigation

1Where this came from

During the August 2026 review of external memory systems, two outside sources arrived at positions adjacent to Loomworks:

• A graph-engineering article (reviewed 2026-08-12 material) arguing that path-walking over connected facts answers "why" questions that similarity search cannot.
• Hindsight, an agent-memory product from Vectorize, whose retrieval runs four strategies in parallel: semantic similarity, keyword match, graph traversal, and temporal — the last one built on the observation that a question like "what did Alice do last spring?" requires reasoning about time, not about topic similarity.

The path-walking idea was already covered: the resident-engagement investigation (v0.2) examined graph databases, set standalone graph stores aside, and confirmed that recursive queries inside PostgreSQL handle Loomworks's graph workloads. The temporal idea was the genuinely new arrival. This document files it.

2What temporal retrieval is

Most retrieval answers "what is about X?" Temporal retrieval answers questions where when is part of the question:

• Point-in-time: what did the engagement hold to be true on a given date?
• Range: what entered Memory between two dates?
• Sequence: what came before, and what came after, a given contribution?
• Change: what has been superseded, corrected, or retracted since a given moment?
• Freshness: which downstream artifacts were derived before Memory moved?

A similarity search cannot answer these. Two assertions about the same topic look identical to a similarity index whether one superseded the other last week or last year. Time is a different axis, and it has to be queried as one.

3What Loomworks already holds

Temporal retrieval is cheap for Loomworks because the substrate was built for it from the start. Every requirement is already met by standing commitments:

• Every assertion carries when. Contribution time, commit time, and the acting party are recorded on every assertion as part of provenance.
• Nothing is erased. The non-erasure discipline means superseded and retracted assertions remain in Memory with their supersession relationships intact. A point-in-time question is answerable because the past was never deleted.
• The event record is append-only. The engine's event tables are a canonical, timestamped record of what happened, never mutated.
• Manifestations are timestamped bookmarks. A Manifestation is Memory organized at a moment in time — it is already a named temporal object. "What changed since the last Manifestation?" is a comparison between a bookmark and the present.

The contrast with the outside systems is instructive. Hindsight had to build freshness-tracking and history-preservation as features. Loomworks gets them as consequences of disciplines already in force. The missing piece is not data; it is the named query capability over data that already exists.

4Query patterns this enables

Concrete examples, stated as an Operator or contributor would ask them:

1. "What did we hold to be true about the credit system at the end of May?" — reconstruct Memory as of a date, honoring supersession.
2. "What has changed since Manifestation 12?" — diff current committed Memory against a bookmark.
3. "Show me everything that entered Memory the week the pricing decision landed." — range query with context.
4. "This assertion was corrected. What was derived from the old version before the correction?" — temporal join between supersession time and derivation times; this is the changed-premise question stated with time attached.
5. "Which Renders were produced from Manifestations that are now behind Memory?" — the staleness question as a standing query rather than a one-off check.

Patterns 4 and 5 show that temporal retrieval and provenance-thread walking are not separate capabilities. Walking threads answers what connects; temporal retrieval answers what connected when. The changed-premise alert — the recall reframe's flagship example — needs both.

5Fit with the recall reframe

The Operator direction of 2026-06-05 stands on record: not-forgetting is table stakes; the product is recall — finding the relevant thing, knowing what links to what, noticing a premise changed. Temporal retrieval is one of the named mechanisms recall will need, alongside:

• Topic recall — what is about X (already served by search over assertions).
• Structural recall — what connects to X (provenance-thread walking, recursive queries in PostgreSQL).
• Temporal recall — what was true when, what changed since (this document).

Filed as input to the future recall arc, whenever that arc is scoped. The seed reframe around recall remains an Operator decision and is not advanced by this document.

6Fit with the staleness question

The open staleness question (carried on record as B-5, and extended by the agents-as-output thread to executable artifacts) asks when a derived artifact should be considered stale because Memory moved. Temporal retrieval is the query machinery a staleness answer would run on: compare the derivation time of an artifact against the commit times of the assertions it derived from. This document does not answer the staleness question; it notes that the two share machinery, so whichever is built first should be built with the other in view.

7Considered and set aside

• New retrieval infrastructure. Set aside. No new database, no external memory service, no vector store. PostgreSQL timestamp queries, window functions, and the existing event tables cover every pattern in Section 4. This repeats the conclusion of the resident-engagement investigation: the substrate is PostgreSQL until a workload proves otherwise.
• Adopting an outside memory product. Set aside. Hindsight and its peers are agent working memory — automatic consolidation, no commit gate, no Operator authority over state transitions. Wiring one in would reintroduce the automatic-state-transition category error the seed rules out. The idea travels; the product does not.
• Natural-language date parsing as part of this capability. Deferred, not set aside. Turning "last spring" into a date range is a Companion-layer concern, separate from the engine's ability to answer a date-ranged query. The engine capability comes first; the conversational surface can follow.

8What building it would involve (sketch only)

Stated to size the work, not to commission it:

• Engine query surface: point-in-time Memory reconstruction, range queries, Manifestation diff, supersession-window queries. All expressible in PostgreSQL against existing tables.
• Companion read pathway: the Companion answers temporal questions by calling those queries and displaying results with provenance — consistent with the standing rule that the Companion displays what the engine attests and never composes facts itself.
• No schema change is expected. If inspection finds a missing index or a timestamp gap, that surfaces at Step 0, per the standing discipline of inspecting before building.

9Open questions

1. Should point-in-time reconstruction be a first-class engine route, or a capability of the Manifestation room (a "derive as of date" variant)?
2. Does "what changed since" belong to the engagement surface (an Operator-facing view) or to the Companion (a conversational answer), or both?
3. When the recall arc is scoped, do the three recall mechanisms (topic, structural, temporal) ship as one capability family or in sequence?

10Status and next step

Filed as an investigation for the queued-futures record. Next step is Operator disposition: hold in the queue, attach to the future recall arc, or commission a scoping note. Default if unstated: hold in the queue, attached to the recall reframe thread.