Enterprise Generative Search — Azure and Open Source  ·  View 21 of 41  ·  Data

Freshness Lifecycle

The loop that keeps the index honest about time, and publishes it when it is not.

Editable source SVG draw.io All views
Change detected delta, CDC or crawl Prioritised by freshness class Reprocessed only what changed Republished idempotent upsert Probed canary query per source Superseded old version demoted Staleness published as-of on every answer Freshness Loop per source class queued 5 min or 24 h parse and embed alias swap found or alarmed graph edge written back to watching Freshness Lifecycle — Keeping the Index Honest About Time Application we own Decision point Data store Security / platform Staleness is never hidden. Where a source is behind its class, the answer says so rather than reading as current. v 1.0 · owner Data and AI Global Practice

Decisions

  • Staleness is published, never hidden. Where a source is behind its freshness class, answers drawing on it carry an as-of and the confidence is reduced.
  • Supersession is written as a graph edge at publish time, so a retired document can still be retrieved and will be labelled as superseded rather than quietly outranked.
  • A canary query per source proves the loop actually closed. A pipeline that reports success while returning nothing is the failure this catches.

Numbers

  • Freshness classes: collaboration 5 minutes, support 15 minutes, archive and external 24 hours, governed tables query-time.
  • Canary queries run every 10 minutes per source; a miss alerts before a user reports it.

Assumptions

  • Sources provide a usable change feed. Where they do not — the archive — the blob change feed substitutes, at the cost of a coarser freshness class.
  • Stale content is more often useful than harmful, so the platform labels it rather than withholding it. That is a stated risk acceptance, recorded in view 41.