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

Notice what it is not. It is not "what is our claims policy?" It is not "show me the latest checklist." It is a question about a specific past moment, judged by the rules that applied then. And 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.

The answer depends on the date.

Real questions are frequently not about now

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 organisational questions are frequently not about now. They sound like this:

• Was the SOP followed on the day of the incident?
• Which playbook bound the team when the contract was signed?
• What evidence rules applied when the case was opened?
• Was the lodgement compliant under the checklist then in force?

High-stakes questions are disproportionately past-tense. Product demos are disproportionately present-tense. That mismatch is not a user-training problem. It is a substrate problem dressed up as a chatbot feature.

What "up to date" optimises for

"Keep the knowledge base up to date" is good operational hygiene. It is not a strategy for audit. Currency — having the latest tip of the chain — is what helps someone starting work today. Applicability — knowing which version covered a past business date — is what helps someone answering for then.

Most stacks optimise only the first. SharePoint folders labelled Current Policies. Vector indexes re-embedded after every rewrite. Chatbots that retrieve the highest-scoring chunk and speak in the tone of certainty. None of that encodes when each thing was true.

We think that is the quiet failure of the "put it in the knowledge base" decade: institutions bought truth-now and then asked for truth-when, and the system performed confidence instead of a walk.

Confidently wrong is worse than "I don't know"

A junior who says "I'm not sure — I'll dig up the 2024 pack" forces a human process. A fluent model that returns a polished paragraph against the wrong version ends the conversation early and wrong. The more capable the generator, the more dangerous a now-only substrate becomes, because the failure mode stops looking like a failure.

Later we will construct a sharper version of this: a retrieval stack that does not even return the current tip — it returns a stale intermediate version that simply scores higher on similarity, still with full confidence. For now the simpler case is enough: the tip is current, and the tip is still the wrong answer for 2024.

What this book owns

The mechanism, in one sentence: an as-at query walks a supersedes chain to the version whose validity window covers the date in question. Chapter 3 walks that chain end to end on three explicit versions. The artefact we are aiming at is a defensible record — a store that does not just know what is true, but when each thing was true.

One fence, early: a sibling piece, Trust Is a Link, audits where an answer came from. This book audits when. The two-click receipt mechanics are not our topic. Neither is deciding which of seven PDFs is the canonical policy, nor the economics of bronze versus silver retention. Those are real problems with other owners. Here the spine is temporal applicability.

Next we need two words used carefully, because almost every bad design collapses them into one: currency and applicability.

Walk into almost any operations team and you will find a folder — physical or digital — where the top document is treated as truth. Version 21. Current checklist. Latest playbook. The older files are archived, renamed, or quietly deleted because "we don't want people using the wrong one."

That instinct is understandable. For work that starts today, the tip of the chain is often the right default. The mistake is treating that default as a complete theory of organisational knowledge. The lodgement question from Chapter 1 does not want the tip. It wants the version that governed the world on a particular day.

Two properties

Name them so they cannot be smuggled into each other:

Currency and applicability only agree when nothing material has changed since D. In a living organisation, policies move. Training packs rewrite. Checklists grow a digital attestation step that did not exist two years ago. The normal case for historical questions is that the current tip is the wrong answer.

Overwrite is not hygiene

The filesystem instinct is overwrite: one current object, history optional. The warehouse instinct, which Chapter 5 will name properly as slowly changing dimensions, is different: when a value changes, you insert a new version with effective dates rather than destroying the old one¹.

Most organisations run filesystem instinct on policies and then expect warehouse-grade answers from the AI sitting on top. That is not a model gap. It is a modelling gap. Overwrite is operationally convenient and legally toxic when the clean tip erases the binding past.

We do not think "delete the old SOPs so nobody uses them" is sophistication. It is how you make the past un-queryable and then act surprised when an audit asks a past-tense question.

Deprecated but binding

Real organisational knowledge carries status. Current policy. Deprecated policy still binding on old contracts. Two departments in genuine disagreement. A solution path tried and abandoned with the reason attached. A prompt can only assert a flattened truth. It has no natural place for status.

Without applicability, "deprecated" tends to mean "hide it so the chatbot does not confuse people." That is exactly wrong for contracts and cases still governed by the old rules. Applicability does not keep every obsolete page as a default. It keeps the binding version addressable for the dates it still owns.

Supersedes, in one paragraph

A supersedes edge is not a synonym for delete. 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. When an ingest process witnesses a new version arriving, it should record that succession as structure — not as folklore in a change-log email nobody will find in three years. That is all the edge grammar this book needs. The rest of the trust stack (clickable receipts, multi-hop relationship graphs, janitor compaction) lives in sibling writing; here the edge exists so an as-at walk has something to walk.

Decay is not enough

Elsewhere we have argued that chronological stacking gives a wiki free temporal decay — newer claims append, older ones float up to be read as superseded, so currency becomes structural. That work, published as The Index Is the Data, answers "what is current?" This book extends the same family of ideas from decay to applicability: not which claim is current, but which claim was true on date D.

Definitions without a walk are still philosophy. Next chapter: three versions, one lodgement date, every step of the as-at query.

Chapter 1 asked whether a 2024 lodgement was compliant under the rules then in force. Chapter 2 separated currency from applicability. This chapter does the only thing that makes those distinctions operational: it walks one as-at query end to end against an explicit three-version chain.

No new philosophy. Entity, date, windows, edges, stop condition, answer payload.

The chain

Suppose a claims checklist is not three sibling files in a folder, but one logical entity with succession recorded as the versions arrived:

A claim was lodged on 12 June 2024. In 2026 someone with authority to make you sweat asks: was that lodgement compliant at the time it was made?

As-at walk, end to end

That is the whole mechanism. You did not restore a backup from 2024. You did not hope someone kept the right PDF in email. You did not ask a model to "be careful about dates." You walked structure that was written down when each succession was witnessed.

Real organizational questions are frequently not about now. The supersedes-chain makes as-at queries structural: walk to the version whose validity window covers the date in question.

Why the walk is possible

The validity window is a business record of when each thing was true in the world. The supersedes edge is a business record of succession. Both are cheap if you capture them at ingest — when the new version arrives and the old one stops being default — and expensive if you try to reconstruct them years later from filenames, folklore, and partial archives.

This is a valid-time answer²: what was true in the world during a window. It is not the same as rewinding the knowledge store to see what the system believed at 9:17am on a particular morning. That other clock matters too; Chapter 5 names both. For the lodgement audit, you need the walk above, on today's graph, to the historically binding version.

The now-only failure, stated coldly

Give the same question to a tip-default system. It has v21. v21 is current. It answers against v21. If v21 added or removed evidence requirements that did not exist in June 2024, the compliance verdict is wrong. The prose may still be excellent. The confidence may still be high. The career risk is still real.

The right answer was on the shelf the entire time as v19. The substrate refused to walk.

Mechanism only works when structure exists. What if the substrate has no windows — only chunks and similarity scores? That is the failure mode of Chapter 4: not merely answering with the tip, but answering with a stale intermediate version that simply outranks everything else.

Put the same three-version claims checklist from Chapter 3 into the substrate most organisations actually ship: a vector index over document chunks. Keep the files. Embed them. Connect a chat interface. Watch two questions diverge.

What the ranking function knows

Baseline retrieval-augmented generation embeds the query, scores chunks by similarity, and returns the top handful. That design is good at local text match. It is not a model of succession. Typed relationships such as "supersedes" or "valid from / valid to" are not first-class objects in the ranking function. Research on GraphRAG exists largely because baseline RAG fails when the question needs structure across a corpus rather than a single hot chunk.³⁴

Optional patches — a recency boost, a metadata date filter, a system prompt that says "prefer recent documents" — are hygiene. They are not an as-at walk. They do not encode that v20 supersedes v19, or that a modern-sounding intermediate version is wrong for a June 2024 business date.

Construct the failure

This is an architectural demonstration, not a published A/B test. It is enough that the mechanism is inevitable once you accept how ranking works.

A filesystem holds versions as sibling files with no semantics; RAG retrieves whichever chunk scores highest, with v20's text happily outranking v21's on the wrong day — a stale answer with full confidence.

Notice the failure is worse than "always use latest." Latest (v21) was not even selected. A mid-chain version won the beauty contest of cosine similarity. Temporal wrongness is not a rare edge case at the tip. It is any day the ranking function prefers the wrong window.

Confidence theatre

Wrong version is bad enough. Decorated wrong version is worse. Work on RAG attributions finds that a large share of generated citations are unfaithful even when the answer appears correct — post-rationalised "support" rather than the true evidence path.⁵

Compound that with temporal error and you get a package executives are trained to trust: fluent prose, official-looking references, and a version that did not apply. Confidence is the system grading itself. A defensible record hands the grading to a window and an edge.

What would have prevented it

Not a cleverer chunk size. Not a sterner system prompt. The Chapter 3 machinery: as-at as a query type, validity windows on versions, supersedes edges, and an answer payload that exposes which window was used. Graph-shaped retrieval can help multi-hop relationship questions; it does not automatically give you temporal applicability unless those temporal edges are first-class and the query type walks them.

We will not pretend "prefer recent documents" is governance. Hope is not a validity window.

For readers who already live in warehouses, none of this should feel exotic. The BI world paid for the same idea decades ago under different names. Chapter 5 makes that mapping explicit: two clocks, slowly changing dimensions, and why soft data gets the same discipline "for free" when succession is recorded as edges.

Leave policies for a moment. Consider payroll — a domain where wrong answers about the past have always been expensive.

A payroll system knows an employee's rate is $100/day starting 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?⁶

The honest answer is: it depends which clock you ask.

Valid time and transaction time

Bitemporal history treats time as two independent 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 exposes the pair as application-time periods and system-versioned tables; tables with both are bitemporal.⁷

In the payroll case, by valid time the rate was $211 on 25 February (the change was effective 15 February). By transaction time — what the system knew when it ran payroll — it was $100. Both answers are correct for different questions. A compliance conversation that cannot ask each clock separately is not careful; it is incomplete.

Mapping onto the soft-data stack

Together those axes are precisely bitemporal modelling. Name the pair; claim the pair. A potential collision between two pieces of the canon becomes a clean division of labour: Git-rewind style audits answer transaction time; as-at walks answer valid time.

Slowly changing dimensions — the cousin you already run

This is not exotic. A slowly changing dimension is a warehouse pattern for attributes that are mostly stable but change over time, often unpredictably.⁸ Type 2 practice is the one that matters here: when a value changes, insert a new row with effective dating rather than overwriting the old one, so history remains queryable.¹

Soft-data analogue: supersedes edges plus validity windows on policies, SOPs, and checklists. Same discipline, different medium. In BI for Soft Data we argued that organisational exhaust can be compiled into a navigable warehouse of claims and edges. This book is the temporal dimension of that warehouse — and it arrives nearly free when the ingest agent records succession as edges instead of overwriting the page and calling it hygiene.

Same doctrine, three short variants

Nothing new is invented here — only the date and the entity change:

• Incident review: as-at the SOP whose window covers the incident timestamp.
• Old contract: as-at the playbook in force on the signature date.
• Hire-date training: which policy version applied in someone's first week — useful when "what we train now" is not "what bound them then."

Each is entity + business date → validity-window walk. That is the whole portable framework.

Concept without procurement language stays a blog post. Chapter 6 turns the doctrine into language you can put in a brief: what "defensible record" must mean when someone tries to sell you a knowledge base.

Watch the language that fails in architecture briefs and RFPs: ingest all policies into the knowledge base / vector store / enterprise search. That sentence purchases currency-shaped demos. It does not purchase the Chapter 3 walk. If you do not name as-at, vendors will not build as-at. They will build chat.

Minimum specification

If a proposal cannot point to those six, it is not proposing a defensible record. It is proposing a knowledge base that is good at now — which you may still want, but should buy under its real name.

Pitfalls that look like solutions

• Date filters on RAG without succession. A filter is not a supersedes graph. Overlapping windows, mid-chain rewrites, and "which version is binding for D" still need structure.
• Filename versioning only. checklist_v19.pdf next to checklist_v21.pdf with no edges is a pile, not a chain.
• "Prefer recent documents" prompts. Pseudo-governance. Recency is not applicability.
• Collapsing history to "save space." Storage economics are a real topic with other owners; do not let them silently delete the windows your audits need.

Where this sits next to siblings

Trust Is a Link audits where an answer came from. This book audits when. Keep the division clean: do not smuggle two-click receipt UX into a temporal brief, and do not pretend a timeline replaces a clickable source path.

Decision attestation packages are kin on the evidence side — portable proof objects that can carry page versions as-of an instant. They lean on the timeline; they do not invent it. The missing memory tier argument — that agents need a durable, typed knowledge layer rather than prompt-stuffed monoliths — is the substrate reason edges can exist at all. Name those pieces; do not re-derive them here.

Out of scope on purpose: two-click trust mechanics, version deduplication as canonicality-as-synthesis, and bronze/silver retention economics. Different articles, different mechanisms.

What "done" looks like

The specification is the contract. The final chapter is the doctrine in one place — short enough to hand to a colleague who will not read six chapters but will run one test.

Return to the title without dressing it up. The answer depends on the date. If your stack cannot act on that sentence, it is not ready for the questions institutions actually ask when money, compliance, or reputation is on the line.

Operating doctrine

1. Past-tense organisational questions are normal, not edge cases reserved for auditors with free time.
2. Currency is not applicability. Latest is a default for new work, not a theory of history.
3. As-at is a walk: entity + business date → version whose validity window covers the date, via supersedes edges.
4. RAG without windows can return a stale intermediate chunk with full confidence. Similarity is not succession.
5. A defensible record knows when each thing was true. A knowledge base that only knows now will keep winning demos and failing audits.

What you leave with

• Portable framework: as-at queries over supersedes edges and validity windows.
• Flagship worked example: the three-version claims checklist walk in Chapter 3 (v19 for a 2024 lodgement, not v21).
• Failure construction: Chapter 4's stale-with-full-confidence retrieval mode.
• BI mapping: valid time vs transaction time; SCD Type 2 as the warehouse cousin (Chapter 5).
• Procurement language: the six-point brief in Chapter 6.

One test this week

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

The answer depends on the date. Make that a structural property of the store — not a hope about ranking.