Compliance · Data Governance

The Answer Depends on the Date

As-at queries and the difference between a knowledge base and a defensible record. Real organizational questions are frequently not about now — and a system that only knows the current policy will answer the past with full confidence and total wrongness.

Here is a question that quietly breaks most knowledge systems: Was this claim compliant when it was lodged in 2024?

Notice it is not a question about now. It is a question about a specific past moment, judged by the rules that applied then. A system that only knows the current state does not merely fail to answer it — it answers wrongly, confidently, by checking a 2024 lodgement against a 2026 rulebook. In a regulated vertical, that confident-wrong compliance verdict is the kind of mistake that ends careers.

We have spent two years stuffing policies, SOPs, and contract playbooks into retrieval systems and calling the result “institutional knowledge.” The marketing promise is always the same: ask in plain English, get the answer. The unspoken assumption underneath is worse: that the answer is always about now.

Real organizational questions are frequently not about now. The answer depends on the date.

Currency is not applicability

Most document stores and chat-over-docs products optimise for one property: currency. Which file is latest? Which chunk has the newest embedding? Which policy PDF has the highest version number in the filename?

Compliance questions need a different property: applicability. Which version governed the world on a particular day? Which SOP bound the team on the day of the incident? Which claims checklist was in force when the form was lodged?

Currency and applicability only agree when nothing has changed since the date that matters. The moment policy moves — and in a living organisation it always does — “give me the current document” becomes a systematic way to falsify the past.

This is not exotic data science. The BI world spent decades formalising the same problem as slowly changing dimensions (SCDs): dimension attributes that are mostly stable but change unpredictably over time.¹ Type 2 SCD practice is blunt and correct — when a value changes, you insert a new row with effective dates rather than overwriting the old one, so you can still query history as it stood.² Soft data (policies, SOPs, playbooks, wiki claims) needs the same discipline. Overwrite is operationally convenient and legally toxic.

Walk the chain: one as-at query, three versions

Here is the minimum mechanism that makes past-tense questions answerable. Call the query type as-at: given a logical document (or claim) and a business date D, return the version whose validity window covers D.

Suppose a claims checklist lives as three successive versions in a governed knowledge graph — not as three sibling files in a folder, but as a chain the ingest process recorded as it happened:

A claim was lodged on 12 June 2024. In 2026 a regulator asks: was that lodgement compliant at the time it was made?

That is the whole mechanism. No Git restore. No hope that someone archived the right PDF. No “I think we were on version nineteen.” The succession was witnessed at ingest and stored as structure; the walk is deterministic.

A now-only system, asked the same question, answers against v21 and produces a confidently wrong compliance verdict. The more fluent the model, the more dangerous that verdict becomes.

How RAG fails this with full confidence

Now put the same three versions into the substrate most organisations actually ship: a vector index over document chunks.

There is no validity window in the ranking function. There is cosine similarity, maybe a recency boost if someone remembered to add one, maybe metadata filters if someone remembered to maintain them. The retriever’s job is to return the top-k chunks that look like the question. Structured succession is not a first-class object; GraphRAG-style work exists precisely because baseline RAG is weak on questions that require relationships across a corpus, not just local text match.³⁴

Construct the failure explicitly:

That is not a model quality problem. It is a substrate problem. A filesystem holds versions as sibling files with no semantics; RAG retrieves whichever chunk scores highest, with v20’s text happily outranking both the current tip and the historically correct version — a stale answer with full confidence.

Worse, confidence can be decorated. Research on RAG attributions finds that a large share of generated citations are unfaithful even when the surface answer looks right — post-rationalised “support” that did not actually drive the answer.⁵ Temporal wrongness plus citation theatre is a compound failure: wrong version, wrong warrant, executive-ready tone.

Two clocks (for readers who already speak warehouse)

What makes this precise rather than hand-wavy is bitemporal history: two independent time axes. Martin Fowler, following Snodgrass and the SQL:2011 standard, names them valid time (also: actual time) and transaction time (also: record time).⁶ SQL:2011 itself exposes the pair as application-time and system-versioned periods; tables with both are bitemporal.⁷

Fowler’s payroll scenario is the intuition pump. An employee rate is known as $100/day from 1 January. Payroll runs on 25 February. On 15 March we learn the rate actually changed to $211/day effective 15 February. What was the rate for 25 February?⁸ By valid time, it was $211. By transaction time — what the system knew when it ran payroll — it was $100. Both answers are correct for different questions. A compliance audit that cannot ask each clock separately is not an audit; it is a shrug.

In our published work, those two clocks already have different jobs. The Model Is Not the Memory owns the transaction-time problem: reconstruct what the agent observed as of a past instant. This piece owns valid time: what was true in the world during a window, retrieved by walking today’s chain — no restore required. Together they are bitemporal modelling. Name the pair; claim the pair.

For BI readers: this is SCD Type 2 logic arriving in the soft-data warehouse. In BI for Soft Data we argued that organisational exhaust can be compiled into a navigable warehouse of claims and edges. As-at is the temporal dimension of that warehouse — free, if the ingest agent records succession as edges instead of overwriting the page and calling it hygiene.

Supersedes, in one paragraph

A supersedes edge is not a synonym for “delete the old thing.” It is a typed succession: version B replaces version A as the default for new work, while A remains addressable with its validity window intact. Deprecated-but-binding is a real organisational status — old contracts still run on old rules — and it is unworkable without a walk that can find the binding version for a past date. That is all the edge grammar this article needs; the rest of the trust stack (clickable receipts, two-click audits of where an answer came from) lives next door in Trust Is a Link. This article audits when.

What to specify instead of “put it in the knowledge base”

If you are buying, building, or governing an AI knowledge layer for policies and procedures, the as-at requirement is concrete enough to put in a brief:

Related pieces in this series name the rest of the stack lightly: decision attestation packages as the portable proof object that can carry those page versions as-of an instant; the missing memory tier as the substrate that can hold typed edges at all. None of those substitute for the validity walk. They lean on it.

FAQ

Isn’t “always use the latest policy” good enough?

For training and for work that starts today, often yes. For audits, disputes, incident reviews, and any contract still bound to older terms, latest is the wrong default. The high-stakes questions are disproportionately past-tense.

Can’t we just filter RAG by document date?

A date filter is a patch, not a model of succession. It does not encode “v20 supersedes v19,” does not handle overlapping windows cleanly, and still ranks by similarity inside the filter. As-at is a walk over structure, not a hope about metadata hygiene.

Is this the same as Git history?

Git (or any system-time history of the store) answers what the system recorded when. That is transaction time — essential for “what did the agent see at 9:17am?” It is not the same as “what rule bound the business on the lodgement date?” You need both clocks.

Do we need a full data warehouse for policies?

No. You need validity windows and succession edges on the soft-data graph you already claim is your knowledge base. The warehouse analogy is conceptual: SCD Type 2 discipline, not a mandatory star schema for PDFs.

Close

A knowledge base that only knows now will keep winning demos and failing audits. The fix is not a cleverer prompt. It is a first-class recognition that the answer depends on the date — and a substrate that can walk to the version whose validity window covers the day that mattered.

Build that once, and every past-tense question stops being a career risk dressed up as a chatbot reply. That is the bar for a defensible record.