Document Version Control for an AI Knowledge Base: Cite the Current One

Document version control for an AI knowledge base means giving every document a stable identity, a version number, an effective date and a status, then letting the agent retrieve only documents marked current unless someone asks about the past. The rules must live in the metadata and in the retrieval filter, not in the agent's good judgment. With those in place, the agent can cite the exact version it used, and a person can verify the answer in seconds.

Key takeaways

• Separate a document's identity from its version, so the system knows that two files are the same document at different moments.
• Give every version a status (draft, scheduled, current, superseded or archived) and filter on it before the agent sees any text.
• Record an effective date, a review date and a pointer to the version being replaced, all in an unambiguous format.
• Retire a version by changing its status and removing its copies, not by deleting history. Old versions stay available for questions about the past.
• Make the agent cite title, version and effective date, and test it with questions whose correct answer changed between versions.

Why does an AI agent cite the wrong version?

Most knowledge bases grow by accumulation. A price list gets a copy called final, then another called final-revised, then one called final-new, and all of them stay in the shared folder. People cope because they carry context: they remember who updated the file last week, or they notice the older one looks dated. An agent has none of those cues. It sees passages of text and nothing else.

There is also a mechanical reason. Retrieval systems typically rank passages by how closely their meaning matches the question, not by recency or authority. An old version and a new version of the same policy are almost identical in meaning, so both score highly. The difference between them is usually a single sentence, and that sentence is exactly what the customer asked about.

In practice this produces three recurring failures:

• Both versions are retrieved and the agent blends them into an answer that matches neither.
• The old version is retrieved because it is longer, clearer or better formatted, and it wins.
• The right version is retrieved but cited without a date, so nobody can tell which one the agent used.

This is a close relative of the problem described in how to stop stale context from misleading your AI agent, but it starts earlier, in the files themselves, before any memory is involved. Fixing it there is cheaper than correcting it downstream.

What metadata should every document carry?

Version control starts with a small, fixed set of fields that travel with every document. They can sit in a header block, in a register spreadsheet or in the wiki's properties, as long as the retrieval layer can read them and filter on them. The fields below are enough for most companies.

• Document ID: a short, stable name such as cancellation-terms. It never changes and is never reused for a different document.
• Title: the human-readable name, identical across all versions.
• Version: a major and minor number, for example 3.0 or 3.1.
• Status: draft, scheduled, current, superseded or archived.
• Effective from: the date this version starts to apply.
• Effective until: empty while current, filled in when the version is retired.
• Review by: the date by which the owner must confirm the document is still correct.
• Supersedes: the version this one replaces.
• Scope: the clients, regions or teams the version applies to.
• Owner: a named person who can approve changes and retire versions.

The owner field matters more than it looks. A version without an owner has nobody who can retire it, and it will quietly stay current for years. The routine for assigning owners and reviewing documents is covered in AI knowledge base maintenance: owners and a review routine, and it pairs naturally with the fields above.

How should you name and date versions?

Naming rules sound trivial until two people apply them differently. Keep them short enough that nobody needs to look them up.

• Never use the words final, new, latest or copy in a file name. They describe a moment, and the moment passes.
• Build every name from the stable ID, the version and the effective date, for example cancellation-terms_v3-0_from-YYYY-MM-DD.
• Write dates with the year first, then month, then day. They sort correctly and cannot be misread between regional formats.
• Change the major number whenever an answer could change: a notice period, an eligibility rule, a limit, a fee structure. Change the minor number only for edits that cannot change an answer, such as typos or formatting.
• Never edit a published version in place. Any edit, however small, produces a new minor version with its own date.

The major and minor distinction gives you a useful signal. When a major version is published, the owner should run the test questions described later in this article. A minor version needs only a quick check that nothing else moved.

Keep two dates apart: when a version is published and when it takes effect. A new set of terms may be approved weeks before it applies. During that gap its status is scheduled, and the old version remains current. On the effective date the statuses swap. That swap should be automatic, or it should be a named task for the owner, not something people remember to do. The agent also needs to know today's date, otherwise it cannot compare it with the effective dates.

How do you retire a version without losing history?

Retirement is where most versioning schemes fail, because it feels like housekeeping. Treat it as a status change with a clear meaning at each stage.

• Draft: visible to authors only. Never indexed for the production agent.
• Scheduled: approved but not yet in effect. The agent may mention it as an upcoming change if asked what is changing.
• Current: the answer. There is exactly one current version per document ID and scope.
• Superseded: replaced by a newer version. Hidden from default retrieval, but available when a question names a past date or asks what changed.
• Archived: kept for records, outside the agent's index entirely.

Do not delete superseded versions. Disputes, audits and ordinary customer questions often turn on what applied at a particular time, such as the terms in force when a client signed. If the old text is gone, nobody can answer that, human or agent.

The other half of retirement is copies. A version is rarely retired until every copy of it is. Look for attachments in email templates, pinned chat messages, exported PDFs, text pasted into prompts and notes in someone's personal folder. The rule is one home per document, with every other place holding a link and not a duplicate. This is the same principle explained in how to give an AI agent a reliable source of truth: one place wins, and everything else points to it.

What should the agent do when it answers?

The agent's behavior should be specified as rules, and the most important rule is enforced by the system, not requested in a prompt.

• Retrieve with a filter on status set to current and on effective dates that include today. Apply it before ranking, so superseded text never competes.
• Cite the title, version and effective date with every answer drawn from a document.
• For a question about the past, retrieve the version that was effective on that date and label the answer as historical.
• If two current versions exist for the same ID and scope, do not choose one. Say there is a conflict and route it to the owner.
• If no current version is found, say the agent cannot confirm the answer and name the owner.

The filter is the load-bearing part. An instruction such as use the latest version depends on the model noticing which passage is latest, and it will sometimes fail. A filter removes the choice. Retrieval-augmented systems generally fetch from an indexed store before generating an answer (see the [Google Cloud RAG architecture](https://docs.cloud.google.com/architecture/rag-capable-gen-ai-app-using-vertex-ai) for a reference design), and that retrieval step is the right place to enforce status and date.

The citation is the second safeguard. A cited version and date turn an invisible mistake into a visible one. A colleague reading the answer can see at once that it quotes version 2 while version 3 took effect last month.

A step-by-step plan to put this in place

You do not need to fix the whole knowledge base at once. Begin with the documents that change answers and work outward.

• Step 1: List the documents the agent can read. Group files that are versions of the same thing. Start with terms, price lists, procedures and eligibility rules.
• Step 2: Assign a document ID and a named owner to each group.
• Step 3: With each owner, decide which version is current. Where two files make conflicting claims, ask the owner and record the decision. Do not guess.
• Step 4: Add the metadata fields and set every older version to superseded, with its effective until date.
• Step 5: Configure retrieval to filter on status and dates before ranking, and to exclude draft and archived content.
• Step 6: Change the publishing routine so that releasing a new version and retiring the old one happen in the same action, by the same person.
• Step 7: Write a set of test questions whose answers differ between versions, and run them after every major publish. The method is described in how to test retrieval quality in an AI knowledge base.

If you can only do one thing this week, do step 3. Agreeing on what is actually current often exposes disagreements that no agent could have resolved.

Illustrative scenario: the cancellation terms

This is an illustrative scenario, not a real case. A services company revises its cancellation terms. The new version shortens the free cancellation window and takes effect at the start of next month. Both PDFs sit in the shared folder, named terms-final and terms-final-new. The older file has clearer worked examples.

A customer asks the agent whether they can still cancel without a fee. The agent retrieves the older file, because its examples match the question closely, and answers with the old rule. Nobody notices until the customer disputes a charge.

Now apply the rules. The new terms are registered under one document ID as a scheduled major version, and the old terms remain current until the effective date. On that date the statuses swap, and the old version receives an effective until date. The agent filters on current status, answers from the new terms and cites the title, version and effective date. If a customer who signed under the old terms asks what applied to them, the agent retrieves the version effective on the signing date and labels the answer historical. The same two files now produce two correct answers, each for the right question.

How Be Human handles document versioning

In a first engagement, Be Human defines the role the agent will play and the documents it needs, then agrees the metadata fields, the status rules and the named owner for each document before anything is indexed. Retrieval is configured to filter on status and effective dates, and the agent is set to cite version and date. Under managed operations, recurring evaluations include version-sensitive test questions, and review routines check that retired content has been removed from every place the agent can read. Publishing approval stays with your owners, and the agent is not permitted to promote a draft to current on its own.

Frequently asked questions

Do I need special software for document version control for an AI knowledge base? No. A shared drive or wiki with consistent metadata can work, provided the retrieval layer can filter on that metadata. Dedicated tools help with approvals and history, but the rules matter more than the platform, and the agent should read from a single indexed location.

Should the agent ever read superseded versions? Yes, in two cases: when a question refers to a past date, and when someone asks what changed. Default retrieval should exclude superseded content, and any answer drawn from it should be labeled historical so nobody mistakes it for the current rule.

How often should versions be reviewed? Each document carries a review-by date set by its owner, based on how often the underlying facts change. Documents that drive customer answers deserve shorter intervals. At review, the owner either confirms the version is still current or publishes a new one.

What if two teams publish conflicting versions of the same policy? First check the scope field, because both may be correct for different clients or regions. If they genuinely conflict, the agent should not pick one. It should flag the conflict to the owner, who decides, and the decision should be recorded as a new version.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.