Retrieval needs a contract, not just a vector database

A common AI automation brief sounds simple: connect our docs to a model so people can ask questions.

The prototype usually works. Someone uploads a support handbook, a few product notes, maybe a folder of policy documents. The first questions are obvious. The answers look good enough to create excitement.

This is the moment where the earlier choice between RAG and CAG becomes operational rather than architectural. The retrieval pattern matters, but the contract around it matters more.

Then real usage begins.

A customer success lead asks about a policy that changed last month. Sales asks a pricing question that depends on region and contract type. Product asks for the current definition of a feature, but the knowledge base contains a roadmap draft, a launch memo, and a stale FAQ. The answer is confident, but not trustworthy.

At that point many teams blame the model. Sometimes the model is part of the problem. More often, the retrieval layer was never given a contract.

OpenAI’s retrieval documentation describes retrieval as semantic search over your data, with vector stores acting as indices. It also shows that search results can include relevant chunks, similarity scores, file origin, attributes for filtering, ranking options, and chunking configuration. Those are not just implementation details. They are operating decisions. (developers.openai.com)

The missing artifact is not another database

A vector database can store and search embedded content. It cannot decide which documents are allowed to answer a payroll question. It cannot know when a legal memo becomes stale. It cannot choose whether an answer should say “I do not know” instead of stitching together two weak passages.

That is the role of a retrieval contract.

A retrieval contract is a short operating agreement for an AI knowledge workflow. It defines what the system is allowed to retrieve, how it should treat age and authority, what it should do when retrieval is weak, who owns source quality, and how the team checks whether the system is improving.

Without that contract, “connect our docs to AI” becomes a vague hope. With it, retrieval becomes a governed subsystem.

What the contract should contain

1. Source scope

Start by naming the sources that are in bounds.

For example: published help center articles, approved sales enablement pages, current product documentation, and signed policy documents. Then name what is out of bounds: drafts, meeting notes, old proposals, personal exports, Slack threads, and anything without an owner.

This matters because retrieval systems are literal. If stale or unofficial material is indexed, the system may retrieve it. If two files contradict each other, the model may synthesize an answer that sounds clean but rests on messy inputs.

Source scope should also include hierarchy. If the public documentation and an internal draft disagree, which one wins? If a policy page and a support macro disagree, which one is authoritative?

2. Freshness rules

Every knowledge workflow needs a freshness policy.

Some content can live for months. A security procedure, pricing page, or compliance rule may need tighter review. The contract should say how often each source category is refreshed, what metadata is required, and what happens when a file passes its review date.

Freshness is not only a technical sync question. It is an accountability question. Someone has to know that the thing being retrieved is still safe to use.

3. Retrieval behavior

The team should decide how retrieval is supposed to work before arguing about answer quality.

Should the system search all sources or filter by department, region, language, product line, or customer segment? Should it prefer exact keyword overlap, semantic similarity, or a hybrid approach? Should it raise the threshold for high-risk topics and accept broader recall for low-risk research?

OpenAI’s retrieval guide shows that attribute filtering can narrow search before semantic retrieval and that ranking options can tune relevance thresholds and the balance between semantic and text matching. The operational point is simple: these settings should reflect product decisions, not hidden defaults. (developers.openai.com)

4. Fallback behavior

A reliable system must know when not to answer.

The contract should define what happens when retrieval returns weak evidence, conflicting evidence, missing evidence, or old evidence. Possible fallbacks include:

• ask a clarifying question
• say the answer is not available in the approved sources
• show the best available source without synthesizing a final answer
• route the question to a human owner
• create a review ticket for missing or conflicting documentation

This is where many RAG systems fail. They are optimized for answering, not for being right under uncertainty.

5. Ownership

Retrieval quality has owners.

Engineering may own ingestion, chunking, metadata, and search configuration. Product may own the user experience and accepted use cases. Operations or department leads may own source quality. Legal, security, or finance may own approval rules for sensitive topics.

If nobody owns the source, nobody owns the answer.

A useful contract names the accountable owner for each source category and the person who can decide whether a source should be added, removed, archived, or demoted.

6. Evaluation and review loop

Do not wait for users to complain.

Create a small evaluation set before launch. Include common questions, ambiguous questions, stale-source traps, cross-source questions, and questions the system should refuse to answer. For each one, define what good retrieval looks like: which source should appear, which source should not appear, and what fallback is acceptable.

Then review real queries on a cadence. Look for patterns: missing documents, bad metadata, chunks that are too broad, chunks that are too narrow, unclear ownership, or queries that reveal a broken process outside the AI system.

The goal is not to make retrieval perfect. The goal is to make failures visible and fixable.

The practical test

Before you ship an AI knowledge assistant, ask six questions:

1. Which sources are allowed to answer this use case?
2. Which source wins when two documents conflict?
3. How fresh does the source need to be?
4. What should the system do when retrieval is weak?
5. Who owns each source and each failure mode?
6. Which sample questions prove the workflow is safe enough to use?

If the team cannot answer these questions, the next step is not a better demo. It is a retrieval contract.

A contract turns a prototype into a workflow

RAG reliability is not only a model problem. It is a product and operations problem around evidence.

The best AI knowledge systems are not the ones with the most documents connected. They are the ones with clear boundaries, maintained sources, explicit fallback behavior, and a review loop that catches reality as it changes.

A vector database can make information searchable. A retrieval contract makes the search usable in a real business workflow.

That is the difference between an impressive prototype and an internal tool people can trust.

If the workflow also uses automations, the same contract should connect to n8n production governance. Retrieval decides what evidence enters the answer. Workflow governance decides what happens after that answer is produced.