An internal agent finds a recent approval for shared service tokens and tells an engineer the approach is permitted. The approval is real, but it applies to a different service. How should a retrieval system distinguish a relevant result from the rule that actually governs the answer?

That is the trust problem behind enterprise retrieval: the most relevant document is not always the most current or the most authoritative. A plausible, well-cited answer can still send an engineer in the wrong direction.

Relevance refers to how closely a document matches a question, while currency indicates whether the information is up to date. Authority establishes whether the document reflects the organization’s official guidance. Vector similarity can help identify relevant documents, but it cannot reliably determine whether the information is current or officially approved.

This becomes a challenge when sources disagree. An official authentication standard may prohibit shared tokens while a newer design review approves a limited exception. The review is more recent, but the standard remains authoritative outside the exception’s scope. A similarity score alone cannot determine which guidance applies to the engineer’s question.

This post shows how to treat relevance, currency, and authority as separate evidence signals. It will examine the challenges this creates for large enterprises, how curated and live knowledge can be routed and reconciled, and how the approach handles a concrete authentication question. Finally, the post will go into implementation lessons, ways to evaluate the design, and the trade-offs that determine when it is worth adopting.

Why Large Enterprises Feel This First

In a small team, engineers generally know which documents to rely on and who to ask when something is unclear. That becomes harder in a large enterprise, where standards, exceptions, and implementation decisions are often managed by different teams.

An architecture team might own a standard, while a review board approves exceptions, and delivery teams handle implementation. An exception granted to one system for a limited period can be mistaken for a broader policy change if an agent retrieves the approval without its original context.

Keeping track of the latest guidance presents another challenge. Standards may be copied across repositories and wikis, ownership can change, and outdated versions may remain searchable. An agent might retrieve an older document without recognizing that it has been superseded. If engineers then use that answer in a design document, architecture review, or audit, they could be relying on guidance that no longer applies.

Two Kinds of Knowledge

One practical way to make authority and freshness explicit is to separate knowledge by the job it does.

The curated path holds relatively stable material: policies, architecture standards, approved patterns, glossaries, decision frameworks, and known failure modes. This material changes slowly, has an owner, and goes through review, much like architecture decision records or a governed wiki. Its main value is authority, and the model should not have to rediscover it in every query.

The live path holds material that changes frequently: tickets, incident reports, recent design reviews, logs, code comments, and meeting notes. Its main value is freshness, and conventional retrieval works well for bringing it into context when needed.

Neither path works alone. Curated material can lag behind recent changes, while live retrieval can surface a timely exception without identifying the standard it modifies. The separation helps the system preserve those different roles, provided each source retains reliable metadata about its owner, status, and scope.

Route Before You Synthesize – The Hybrid

With two paths in place, the system needs an explicit decision about which one can answer a given question. That decision should happen before synthesis, not inside the prompt.

Diagram 1

The router acts as a policy layer. It classifies the question by intent and freshness requirements, assigns confidence to that decision, and uses both paths when confidence is low, and the stakes are high.

  • “What is our approved pattern for service-to-service authentication?” (needs the official position so curated path)
  • “What changed in the payment service after Tuesday’s incident?” (needs current state so live path)
  • “Does the authentication change made last week still comply with our approved service-to-service standard?” (both, using the official position and the recent change)

After retrieval, synthesis needs explicit precedence rules based on source governance and scope to determine how curated guidance and live evidence should inform the response. Each source must carry document type, owner, version, timestamp, and, where relevant, exception scope and expiry into synthesis. The system can then apply the rule to evidence rather than infer it from the wording of a retrieved passage.

When sources still materially disagree, the agent should say so instead of blending them into a single, confident answer. Treat disagreement as a first-class system state: log the sources involved and the precedence rule that was applied, and when the evidence cannot support a safe answer, route the question to a person or the team that owns the guidance.

How the Paths Compare

Diagram 2

Where This Pattern Fits

Routing on its own is not new. Common retrieval frameworks already include query routers that choose between indexes or tools, and graph-based approaches add structured, LLM-generated knowledge alongside raw chunks. What is often less discussed is routing authority and freshness specifically, treating “which source is official” and “which source is current” as separate signals that shape both retrieval and synthesis.

An Illustrative Example

Consider this hypothetical scenario. A platform team is building a notifications service that needs to call an internal ledger API. An engineer asks the agent:

“Can our notifications service use the shared service token approach that was approved last week to call the ledger API?”

Three items in the knowledge base are relevant:

  1. An enterprise authentication standard. A enterprise security standard that requires workload identity with mutual TLS and prohibits shared long-lived tokens. Design review notes from last week. They grant the billing service, and only the billing service, a time-bound exception to use a shared token while it migrates off a legacy platform.
  2. An incident ticket from last month. A shared token was found in a build log, and rotation is under way.

What relevance-only retrieval does

Because the question repeats phrases from the recent review, a relevance-only ranking could surface that review above the governing standard. If the model treats a scoped approval as a general rule, it might answer:

“Yes. A shared token approach was approved in last week’s design review.”

The answer is traceable to a retrieved document but wrong for the notifications service. The approval applies only to billing, and the governing standard has been missed.

What the hybrid does:

  1. Route. A compliance question needs both the official position and the current state, so the router sends it to both paths.
  2. Retrieve with metadata. The standard comes back with its type, owner, and version. The review comes back with its date, scope, and expiry, and the incident with its date.
  3. Apply precedence. The standard governs the principle. The review is a scoped exception, not a replacement, and because it states its scope and expiry, synthesis can resolve the disagreement. The incident is a current fact that raises the stakes.
  4. Answer with provenance:

“Not by default. The Service-to-Service Authentication Standard (version 3, owned by security architecture) requires workload identity with mutual TLS. Last weeks’ time-bound exception applies only to the billing service. A shared token was also exposed in last Thursday’s incident. If the notifications service needs an exception, it would need its own review.”

If the review lacked a clear scope or expiry, the agent should surface that uncertainty and refer the question to the guidance owner.

Lessons Learned

Implementation lessons from these patterns:

  1. Provenance can be lost at ingestion. Identifying documents by file path alone can create conflicts when multiple repositories contain files at the same path, potentially causing one document to overwrite another and obscuring its source Document should account for host, repository, branch, and directory as well as the path. Authority metadata is only as reliable as the identity beneath it.
  2. Curated knowledge helps resolve vocabulary as well as policy. A curated concept layer can expand shorthand and map related terminology before retrieval, improving matching when a query and its relevant documents use different terms.
  3. Curated scope can be too narrow. Restricting retrieval to documents linked to a recognized concept can improve precision but sometimes excluded the best evidence. When scoped evidence is weak, an unscoped retrieval pass can help identify stronger results, with overrides recorded for traceability.. Routing needs a fallback and a trace, not just a classifier.
  4. “Not enough evidence” is a valid answer. Confidence thresholds on the reranked evidence allow an agent to decline to answer instead of synthesizing weak matches. In governance work, a clear refusal beats a fluent guess.
  5. Make evidence inspectable. Display ranked sources with file, section, and confidence information so engineers can check the basis of a decision, including the source’s authority and scope.
  6. Fail soft at every stage. Query rewriting, reranking, and curated knowledge layers should have appropriate timeouts and fallbacks, so a slow component lowers answer quality instead of taking the agent down.

Measuring Whether It Works

  • Evaluate routing, evidence selection, and synthesis separately so a poor answer can be traced to the stage that failed.
  • Measure route accuracy on a labeled query set that includes source conflicts, scoped exceptions, and ordinary questions. Assess whether the router chose the curated path, live path, or both.
  • Track conflict-detection performance, unsupported answers that reach users, and the additional latency and cost of dual-path retrieval.

Trade-offs Worth Knowing

A hybrid design introduces more moving parts. Queries can be misrouted; curated guidance requires ownership and review; and precedence rules need regression testing. Dual-path retrieval may also increase latency and cost, so the additional reliability should be measured rather than assumed.

The additional complexity is most defensible when a question requires both institutional guidance and recent operational context, as in architecture review or security triage. For small or low-governance knowledge bases, simpler retrieval may be sufficient.

Where to Start

The implementation starts with evidence quality. Four practical steps follow:

  1. Capture authority metadata at ingestion. It is far cheaper to record than to infer later, and every precedence rule depends on it.
  2. Keep the curated set small, owned, and versioned. Structured Markdown or a lightweight knowledge store often works better for this material than a noisy embedding index.
  3. Start the router with rules. Simple rules and basic embeddings make a reasonable first version. Measure route accuracy before investing in a trained classifier.
  4. Expose unresolved conflicts. When evidence disagrees or remains thin, show the uncertainty and the relevant sources. Recurring conflicts can also signal guidance that needs review.

A retrieved answer is only as trustworthy as the evidence governing it. In the authentication example, the newest approval was relevant but did not authorize another service to reuse the exception. Preserving authority, currency, and scope through routing and synthesis lets an engineer see why the agent reached its conclusion and when to seek human review.