# Temporal RAG Architecture for an Enterprise Policy Repository This is a design proposal. Nothing here has been implemented or validated. ## 1. Temporal RAG Decision **Decision:** Temporal RAG is required. Plain RAG would retrieve the semantically best chunk regardless of which version it belongs to, which breaks all three user needs (current, as-of-date, and change-over-time). **Chosen architecture: a version-aware index, not a graph.** - A relational **policy registry** is the source of truth for lineage, effective intervals, amendments, corrections, and status. - An **immutable chunk index** (dense plus BM25) holds every version's chunks. Chunks are never re-embedded because a policy was superseded. - **Validity is resolved at query time** by the registry, which produces a set of `version_id`s. Retrieval is then pre-filtered to that set. **Why not GraphRAG:** The relationships are a simple lineage (policy family → versions → amendments → corrections). A relational model with recursive queries covers this. A graph adds update cost without enabling a query you can't already answer. Revisit it only if cross-policy dependencies ("this procedure implements that security policy") become a requirement. ## 2. Temporal Knowledge Audit Publication, effective, and ingestion dates are treated as independent throughout. Effective dates may precede publication (retroactive) or follow it (scheduled). | Type | Present? | Time semantics | Source | Validity model | Update behavior | Conflict risk | |---|---|---|---|---|---|---| | Point-in-time facts | Limited (notice dates, approval dates) | Instant | Document headers | None; they are dated, not valid over a span | Static | Low | | Interval-valid facts | **Yes**, the core case | Effective from → superseded or expired | Policy headers | Half-open interval | Interval end changes when a successor arrives | **High** | | Versioned documents | **Yes** | Revision number plus effective date | Header and revision number | One active version per policy family and scope | New version closes the previous interval | High if numbering and dates disagree | | Events | Marginal (compliance notices may cite a regulatory event) | Event date ≠ publication date | Notice body | Not a validity span | Static | Medium | | Amendments | **Yes** | Own effective date, attached to base | Amendment doc | Valid with its base, from its own date | Changes the effective state without replacing the base | **High**: partial override of clauses | | Replacements | **Yes** | Successor effective date | New policy doc | Ends predecessor | Closes predecessor interval | Medium | | Overlapping validity | **Yes**: base plus amendments; scheduled versions; transition periods | Concurrent | Derived | Composition of base and amendments | Recomputed per policy family | High | | Historical snapshots | **Yes**, six years of archive | Past intervals | Archive | Closed intervals | Immutable, except via corrections | Medium (archive gaps) | | Continuously evolving entities | Yes, logically (a policy family over time) | Lineage | Derived | Lineage chain | Grows weekly | Medium | **Correction notices add a second time axis.** They can change what the text of a past version *should have said*. So there are two historical questions: "what applied on date D, as best known today?" and "what did we publish and believe at the time?" The default is the former. Any correction affecting the answer is disclosed. ## 3. Temporal Data Contract **Time types kept separate** | Time | Field(s) | Notes | |---|---|---| | Publication time | `publication_date` | When the document was released; never used for validity | | Validity time | `effective_from`, `stated_expiry` (optional), derived `effective_to` | Validity convention: **[effective_from, effective_to)**, dates in organization timezone | | System ingestion time | `ingestion_time`, `registry_txn_id` | When we learned it; supports "as known at" audits | | Event time | `event_date` for compliance notices only | Omitted for all other doc types as unjustified | **Fields** | Group | Fields | |---|---| | Identity | `policy_id` (stable family), `document_id`, `version_id`, `revision_number`, `policy_domain` (HR/security/travel/expense/compliance) | | Type and status | `doc_type` (BASE, REPLACEMENT, AMENDMENT, CORRECTION, NOTICE), `status` (DRAFT, SCHEDULED, ACTIVE, SUPERSEDED, WITHDRAWN) | | Lineage | `supersedes`, `amends`, `corrects`, `target_sections[]`; derived (never authored): `superseded_by`, `effective_to` | | Provenance | `source_uri`, `content_hash`, `effective_date_source` (explicit / inferred), `extraction_confidence`, `reviewed_by` | | Chunk-level | `chunk_id`, `version_id`, `section_path`, `section_id`, `chunk_order` | | Access | `acl_groups` (HR/security content is often audience-restricted; enforced as a pre-filter) | **Design rule:** Mutable fields (`effective_to`, `status`, `superseded_by`) live only in the registry. They are never embedded and never baked into the vector payload. This is what makes supersession a registry write rather than a re-index. ## 4. Ingestion Pipeline 1. **Document analysis.** Classify `doc_type`, parse revision number, and identify the target policy. Header fields come from deterministic parsing first, with an LLM fallback that carries a confidence score. 2. **Temporal anchor extraction.** Pull the effective date, publication date, stated expiry, and "supersedes/amends Rev N §X" statements. Missing or low-confidence effective dates go to a **human review queue** and are never defaulted to the publication date. 3. **Event/fact extraction.** Only for notices (the event date) and for amendment targets (which sections change). 4. **Normalization.** ISO dates, one timezone, canonical `policy_id` matching by ID, then by title similarity with human confirmation on ambiguous matches. 5. **Version relationship.** Determine replacement vs amendment vs correction, and write the registry lineage in a staged state (not yet visible). 6. **Chunk enrichment.** Chunk along section structure. Table rows and list continuations inherit their heading. Each embedded chunk is prefixed with an **immutable context header**: `Policy: International Travel | Version 4 (Rev 4) | Effective 2024-03-01 | §3.2 Approvals | Type: BASE` Amendment chunks add `AMENDS Rev 4 §3.2, effective <date>`. 7. **Indexing.** Upsert chunks (dense and BM25) with `version_id`. The chunks stay invisible to retrieval until the registry marks the version ACTIVE or SCHEDULED. Also build one **policy-level summary** per version, scoped to that version (never "the current policy"), to support policy-family identification. ## 5. Representation Architecture | Option | Fit | Benefit | Complexity | Update cost | Query support | Failure mode | |---|---|---|---|---|---|---| | Vector + temporal metadata | Partial | Simple | Low | Low | Current and as-of if filters are right | Mutable validity metadata goes stale; no composition of base plus amendments | | **Version-aware index (registry + immutable chunks)** | **Strong** | Exact version resolution, citations by version, no re-embedding on supersession | Medium | **Low (localized)** | Current, as-of, change history | Registry errors silently select the wrong version | | Temporal knowledge graph | Weak | Rich relations | High | Medium–high | Cross-entity temporal reasoning | Over-engineering; extraction errors become graph facts | | Hierarchical time graph | Weak | Good for event timelines | Medium–high | Medium | Diachronic over many events | Policies are not event streams | | Hybrid graph + vector | Not justified | Cross-policy reasoning | Highest | Highest | Dependency queries | Same as above, plus sync burden | **Chosen:** the version-aware index. Escalation trigger for a graph: a real requirement for cross-policy dependency queries. ## 6. Incremental Update Workflow **Flow:** New source → extract anchors and facts → match to existing `policy_id` and version → classify change → write staged registry changes → upsert chunks for the new document only → recompute the affected policy family's effective states → validate invariants → atomic publish. | Class | Detection | Action | Index impact | |---|---|---|---| | NEW FACT (new policy) | No matching `policy_id` | Insert family and version | New chunks only | | SUPERSESSION | States "replaces Rev N" or matches the family with a later effective date | Set predecessor's derived `effective_to`; status SUPERSEDED | Registry only; old chunks untouched | | AMENDMENT | Names base and target sections | Attach to base with its own effective date | New chunks only; base unchanged | | CORRECTION | Corrects a named version | Store as new record with its own transaction time; never overwrite the original | New chunks plus registry link | | EXPIRATION | Retirement notice with no successor | Set `effective_to`; policy has no successor | Registry only | | DUPLICATE | Same `content_hash` | Skip and log | None | | CONFLICT | Overlapping intervals for the same family and scope, or two documents superseding the same version | **Quarantine; do not publish** | None until resolved | | UNKNOWN | Cannot classify | Review queue | None | **Publish invariants checked before the atomic registry commit:** - Lineage is acyclic. - No unintended gaps or overlaps within a family and scope. - Every version has a reviewed effective date. - Revision numbers have no unexplained gaps. **Retroactive effective dates** are legitimate, but they change historical answers. They are logged as "historical answer change" events and trigger regression tests. **Full rebuild is required only** when the embedding model or chunking strategy changes. In that case, build a shadow index and cut over. ## 7. Query Decomposition Logic Every query becomes a structured object: `{semantic_core, mode, as_of_date, window, relative_expr→resolved, ambiguity_flags}`. The mode is CURRENT, POINT_IN_TIME, or CHANGE_HISTORY. | Query | Semantic core | Temporal reading | Handling | |---|---|---|---| | "What's the current international travel approval policy?" | Travel approvals | CURRENT, `as_of = today` | Resolve the active state and state the as-of date | | "What was the expense limit on 2022-03-15?" | Expense limits | POINT_IN_TIME (explicit) | Resolve the state at that date | | "How has the remote work policy changed since 2021?" | Remote work | CHANGE_HISTORY, window 2021→today | Coverage engine required | | "Could I expense meals last March?" | Meal expenses | Implicit historical; **window**, not a date | March may span versions, so retrieve all that overlap. Expose the ambiguity: policy may key on expense date vs submission date | | "What's the policy on laptops?" | Device policy | Ambiguous (current is the default) | Answer current, state the as-of date, flag any SCHEDULED future version | | "What applied when I joined?" | Unknown | Needs a user attribute | Ask for the date | Historical intent is never silently downgraded to current. Relative expressions are resolved against query time and echoed back in the answer. ## 8. Retrieval Architecture **Common stages:** (0) resolve the query object and ACL scope → (A) identify policy families via semantic search over version-scoped summaries → (B) registry resolves valid `version_id`s. | Stage | CURRENT | POINT_IN_TIME | CHANGE_HISTORY | |---|---|---|---| | **Candidate generation** | Hybrid dense+BM25 within the valid set | Same | Same, per lineage node | | **Filter** | Pre-filter to `version_id` ∈ {active base + amendments effective ≤ today} | Pre-filter to state at `as_of_date` | All versions and amendments in the window | | **Ranking** | RRF fusion of dense and BM25 | Same | Per-version ranking | | **Temporal constraint** | **Hard**: invalid versions are never candidates | **Hard** | Window overlap, with coverage gate | | **Reranking** | Cross-encoder; amendment chunks outrank the base chunks of the sections they override | Same | Cross-encoder within each version, then ordered by time | | **Final evidence set** | Top-k chunks plus each cited version's header block; overridden base chunks excluded | Same | Relevant chunks from **every** lineage node, plus the change digest if one is available | **Guards:** If the registry resolves no valid version at the requested date (before the policy existed, or in an archive gap), return "no evidence" and never the nearest-date version. Temporal filtering is a pre-filter, because post-filtering top-k loses valid chunks that fall just below the cutoff. ## 9. Temporal Coverage Model Applies to CHANGE_HISTORY and to window queries. The lineage is finite and enumerable, so coverage can be checked exactly. 1. **Define the window** (explicit or first version → today). 2. **Anchors** = every lineage node in the window (base, replacements, amendments, corrections). 3. **Measure coverage** = relevant-section evidence retrieved per node ÷ nodes whose `target_sections` or content plausibly touch the semantic core. 4. **Detect gaps** in two ways: lineage nodes with no retrieved evidence, and validity gaps or revision-number gaps in the registry (which suggest missing archive documents). 5. **Endpoint bias:** flag when evidence comes only from the first and latest versions. 6. **Retrieve missing periods** with targeted per-version queries. | Status | Condition | |---|---| | COMPLETE | All relevant nodes have evidence and no unexplained registry gaps | | PARTIAL | Some relevant nodes lack evidence after re-retrieval | | BIASED | Evidence is concentrated at endpoints or one period | | INSUFFICIENT | Too few nodes to describe a change sequence | Only COMPLETE permits a change narrative stated without caveats. PARTIAL and BIASED require constrained answers that name the missing versions. ## 10. Conflict & Version Policy | Situation | Classification | Labels | |---|---|---| | Newer version, same family | VERSION CHANGE | Newer = LATEST VALID; older = HISTORICALLY VALID, SUPERSEDED | | Published but not yet effective | VERSION CHANGE (scheduled) | Marked LATEST VALID **(scheduled)**; the currently active one stays current until the effective date. This qualifier extends your label set | | Correction notice | CORRECTION | Corrected clause: SUPERSEDED for as-corrected answers; original remains HISTORICALLY VALID as "what was published" | | FAQ or training deck disagrees with a policy | SOURCE DISAGREEMENT | Policy of record wins; derivative is CONFLICTING and flagged | | Region or employee-group variants | CONCURRENT VALID STATES | Both valid, each with scope | | Two documents claim to supersede the same version | CONFLICTING | Quarantined; surfaced as UNKNOWN until resolved | **Rules:** Supersession changes validity, never retrievability. A policy documented as authoritative is never overridden by a derivative document. Where authority is equal and no rule resolves the conflict, say so rather than picking one. ## 11. Context Construction The structure follows **version**, with **change sequence** for history queries. - **Current / as-of:** one block per policy family, with a header (`Policy · Version · Rev · Effective from–to · Status`), then the base sections with applicable amendments inlined and labeled (`[AMENDED by Amendment 2, eff. 2025-06-01, §3.2]`). - **Change history:** blocks in chronological order, one per lineage node. If section-level diffs were computed at ingestion (a localized, per-version-pair derived artifact), include them as a *digest*. Source chunks are still included, because the digest is not citable evidence. - **Window queries across several versions:** group by version, ordered by date, with the boundary dates explicit. ## 12. Generation Contract The generator must: - Open with the **as-of date and the exact version used**: "As of 2026-10-04, under Travel Policy v4 (Rev 4, effective 2024-03-01)…" - Cite every material claim as `[policy_id · version · Rev N · effective date · §section]`, mapped to retrieved evidence. - Label statements as CURRENT FACT, HISTORICAL FACT, CHANGE, TREND, UNCERTAINTY, or EVIDENCE GAP. - Mention a SCHEDULED future version when it exists. - Disclose applicable corrections and archive gaps (for example, a missing Rev 3). - If coverage is not COMPLETE, constrain the answer to the evidence and name the missing versions. Never infer continuity across a gap. - If no version resolves, say that no applicable policy evidence was found. Do not answer from general knowledge. ## 13. Update Stability Plan | Aspect | Rule | |---|---| | Updated fact retrieval | New versions are discoverable only after the registry commit; check with a post-publish probe query | | Old version retention | Chunks are never deleted. Status is soft; withdrawal is a status, not a delete | | Current version selection | Computed from the registry at query time, never cached beyond the day boundary (effective dates roll over) | | Historical query stability | Answers for a past date must not change after unrelated ingestion. They may change only for retroactive effective dates or corrections, and those are logged | | Retrieval drift | BM25 statistics and ANN graph shifts as the corpus grows. Mitigate by running golden-query regression on impacted families after each ingest, plus a rotating sample of the rest | | Summary regeneration | Version-scoped summaries are regenerated only for the affected version. Family-level summaries are rebuilt only for the affected family | | Update cost | Per weekly batch: embed new chunks only, write registry rows, recompute affected families, run regression. A full rebuild is reserved for embedding or chunking changes (shadow index) | A successful ingest does not imply correct retrieval, which is why regression is a publish-gate step. ## 14. Evaluation Suite | Test | Expected evidence | Pass condition | Failure interpretation | |---|---|---|---| | Point-in-time QA | Chunks from the version valid at the date | Right version cited; right answer | Wrong version selection or interval-boundary error | | Current-state QA | Active base plus applicable amendments | Cites the active version and amendments | Stale registry or filter bypass | | Historical QA | A superseded but then-valid version | Retrieves the old version, not the current one | Silent downgrade to current | | Diachronic analysis | One evidence set per lineage node | Narrative covers all nodes in order | Endpoint bias or missing period | | Temporal coverage | Registry lineage vs retrieved nodes | Status computed correctly on planted gaps | Coverage engine blind to gaps | | Version selection | Boundary cases: the day before and the effective day | Correct on both sides | Off-by-one in half-open intervals | | Update correction | A correction notice ingested | Answers reflect the correction and disclose it | Correction not linked to the version | | Conflict handling | Planted FAQ conflict and double-supersession | Conflict surfaced or quarantined | Conflict collapse | | Incremental update | Add an amendment | Only new chunks are embedded; amended answers change | Hidden re-index or missed amendment composition | | Retrieval stability | Golden queries before and after unrelated ingests | Evidence sets unchanged | Retrieval drift | Also include ACL tests (restricted policies never appear to unauthorized users) and a missing-version test (Rev 3 absent is disclosed). ## 15. Failure & Repair Matrix | Failure | Detection | Cause | Repair target | |---|---|---|---| | Outdated retrieval | Current-state QA cites a superseded version | Stale cache or missing interval closure | Registry update path; cache expiry | | Temporal leakage | Past-date answer uses a later version | Post-filtering or missing pre-filter | Retrieval filter stage | | Wrong version | Boundary tests fail | Interval convention mismatch | Resolver logic and timezone handling | | Endpoint bias | Coverage returns BIASED | Top-k dominated by newest and oldest | Per-node retrieval | | Missing period | Registry gap versus evidence | Archive incomplete or retrieval cut | Archive audit; coverage re-retrieval | | Conflict collapse | Two sources, one answer | No authority rule | Conflict policy; context labeling | | Event-time confusion | Notice date treated as effective date | Extraction defaulting | Anchor extraction; review queue | | Publication-time confusion | Retroactive policy mis-dated | Fallback to publication date | Data contract (no defaulting) | | Update drift | Golden queries change after ingest | BM25/ANN shift or metadata edits | Regression gate | | Stale summary | Summary describes a superseded state | Non-version-scoped summary | Summary versioning | ## 16. Implementation Roadmap | Phase | Build | Dependency | Validation | Exit criterion | |---|---|---|---|---| | 1. Temporal data contract | Registry schema, interval convention, invariants | Policy owners agree on semantics | Schema review on 20 sample policies | Open decisions below resolved or defaulted | | 2. Ingestion | Header parsing, review queue, chunk enrichment, lineage matching | Phase 1 | Extraction accuracy on a labeled sample | High effective-date and lineage accuracy; low-confidence cases route to review | | 3. Retrieval | Registry resolver, pre-filtered hybrid search, reranking | Phase 2 | Point-in-time and current QA | All version-selection tests pass | | 4. Context / generation | Version-block context, citation format, as-of statements | Phase 3 | Citation checks | Every material claim traceable | | 5. Incremental updates | Change classifier, staged publish, invariants, regression gate | Phases 2–3 | Replay six months of historical arrivals | No full rebuild; stable golden queries | | 6. Evaluation | Full suite, coverage engine | Phases 3–5 | Planted-failure runs | All ten tests wired to CI | | 7. Operations | Monitoring, review SLAs, shadow-index rebuild runbook | Phase 6 | Dry-run model migration | Documented runbook; alerts live | ## 17. Temporal RAG Architecture Pack | Item | Summary | |---|---| | **ARCHITECTURE** | Registry (bitemporal lineage) + immutable versioned hybrid chunk index; no graph | | **TEMPORAL MODEL** | Publication, effective [from, to), ingestion, and (notices only) event time kept separate; mutable fields only in the registry | | **UPDATE MODEL** | Classify (new, supersede, amend, correct, expire, duplicate, conflict, unknown) → staged registry write → embed new chunks only → invariants → atomic publish → regression | | **QUERY MODEL** | Structured object: mode, as-of date, window, resolved relative time, exposed ambiguity | | **RETRIEVAL MODEL** | Policy-family identification → registry-resolved valid versions → pre-filtered hybrid retrieval → rerank, with amendments overriding base sections | | **COVERAGE GATE** | Change-history answers require COMPLETE; PARTIAL and BIASED force constrained answers naming missing versions | | **VERSION POLICY** | Supersession alters validity, never retrievability; corrections are additive records; authoritative policy beats derivative sources | | **PROVENANCE RULE** | Every material claim cites `[policy_id · version · Rev · effective date · §section]`, and every answer states its as-of date | | **FIRST COMPONENT TO BUILD** | The registry plus the version resolver (effective-state computation) | | **FIRST EVALUATION** | Boundary-date version selection (day before and day of an effective date) | | **BIGGEST TEMPORAL RISK** | Wrong or missing effective dates at ingestion (retroactive or scheduled policies), which silently corrupt every downstream stage | | **DO NOT BUILD YET** | Knowledge graph, pre-consolidated amended-policy texts, automatic clause-level diff narratives, cross-policy dependency reasoning | **STATUS: READY WITH OPEN DECISIONS** **Open decisions** 1. Effective-date boundary convention (inclusive start and exclusive end), and the timezone used. 2. Which date governs applicability for expense and travel rules: incident date, travel date, or submission date. This is a policy question, not an engineering one. 3. Whether policies have regional or employee-group variants, which would require a scope field. 4. Whether amendments name target sections in a machine-readable way, or whether that must be extracted. 5. Archive completeness for the six-year history (revision-number gap audit). 6. The authority hierarchy between policies, procedures, notices, and derivative documents. 7. ACL model for restricted HR and security content.