Define What “Fresh” Means for Each Data Domain
The dangerous failure mode in enterprise AI is often not missing information, but confidently returning information that used to be correct. A product manual may remain valid until a replacement is approved, while inventory, account balances, and equipment alarms can become stale almost immediately. A single updated_at field cannot explain whether a source record changed, a file was synchronized, or an unchanged document was simply re-indexed.
Start by defining a time contract for every important source. Useful metadata includes event time, source-system update time, ingestion time, and the period during which a record is effective. Store these fields alongside the document version, source identifier, owner, and lifecycle status. If the source has no trustworthy timestamp, label freshness as unknown instead of treating ingestion time as proof that the content is current. This distinction lets retrieval apply meaningful filters and enables the final answer to disclose its temporal basis.
Route According to the Question’s Freshness Requirement
A query router should classify more than topic. It must infer the time scale required by the user. “How does the leave policy work?” can usually be answered from an approved knowledge base. “How much leave do I have today?” requires a live HR system lookup. Rules are effective for explicit wording, authorization constraints, and high-risk cases, while a language model can recognize less obvious intent. In practice, the routing policy should distinguish at least these paths:
- Stable knowledge: Policies, operating instructions, and product concepts can use a curated document index, with filters for version, approval status, and effective dates.
- Frequently changing data: Schedules, price lists, promotions, and internal announcements should favor structured sources with reliable update times and short cache lifetimes.
- Live transactional state: Inventory, order status, alerts, and balances should come directly from authoritative ERP, CRM, IoT, or account APIs rather than an old vector-store snapshot.
- Historical analysis: Trends, comparisons, and root-cause questions need an explicit time window and a reproducible warehouse or event log, not merely the newest record.
A single question may require multiple routes. An assistant could retrieve diagnostic steps from a maintenance manual, then obtain current sensor readings from an IoT platform. When assembling the response, preserve the timestamp and provenance of each component. A generic “latest data” badge is misleading when different parts of the answer were produced from sources with different update cycles.
Enforce Freshness During Retrieval and Answer Generation
A practical pipeline first extracts temporal expressions such as “now,” “last week,” “the current version,” or a specific date. It then creates a freshness requirement that can include maximum acceptable age, requested time range, cache policy, and mandatory source. This requirement should not be reduced to a simple real-time or non-real-time flag. The router can use it to select a document index, SQL query, internal API, or event platform, with authorization checked before any data reaches the language model.
Similarity score alone should never determine the winning result. Retrieval should exclude expired, draft, and superseded records before combining semantic relevance with source authority and temporal fitness. When sources disagree, resolve the conflict through ownership and version rules rather than automatically trusting the newest timestamp. A recently synchronized replica may still be less authoritative than a slightly older record in the system of record. Cache keys should also include tenant, permissions, time window, and source version; otherwise, identical wording can incorrectly reuse an answer created for a different user or business context.
Fail Safely When Freshness Cannot Be Verified
A trustworthy assistant must be able to say that it cannot confirm whether data is current. If an authoritative API is unavailable, timestamps are missing, or the requested date falls outside the source’s effective period, the system should lower confidence and show the available as-of time. Depending on risk, it can decline to answer, request confirmation, or direct the user to the source system. Questions affecting orders, finance, access, or equipment operation should not silently fall back to stale cache entries.
After launch, log the user query, inferred freshness requirement, chosen route, source version, data timestamps, and final outcome. Evaluation should cover more than factual correctness: include day-boundary changes, withdrawn versions, delayed synchronization, conflicting sources, and API outages. Begin with the business queries where stale answers create the greatest operational risk, then expand once their time contracts and fallback behavior are clear. Where several legacy systems are involved, an integration team familiar with data ownership and API boundaries can help make those contracts enforceable rather than merely documented.