Knowledge Governance: Who Owns the Answers?

Drift is the default

Three months after launch, a well-configured chatbot is quietly wrong about several things. A price changed. A policy was revised in a document nobody uploaded. A product was discontinued. None of these produced an error — the old material simply kept existing and kept being retrieved.

What makes this hard is that drift is invisible from the inside. The dashboard looks fine. Containment is stable. The only signal is customers being told something that is no longer true, and that signal reaches you through complaints rather than through monitoring.

The fix is not a technology. It is naming who is responsible for which answers and how quickly they have to update them — the same arrangement any company already has for its website, its price list and its terms.

Ownership by category, not by document

The instinct is to assign an owner to the knowledge base. That produces one overloaded person who becomes a bottleneck and eventually stops. Assign by category instead, matching whoever already owns that subject in the business.

• Pricing and commercial terms — commercial or finance, who already change them and know when.
• Product and catalogue — whoever owns the product line, including discontinuations.
• Delivery, logistics and availability — operations, because they learn about changes first.
• Policies, guarantees and legal wording — legal or compliance, with a review requirement rather than free editing.
• Support answers and troubleshooting — the support lead, who sees which answers fail.
• Escalation wording, fallbacks and tone — whoever owns customer experience.
• Opening hours, branches and contact details — an administrative owner, because these change often and matter more than their triviality suggests.

Write the map down with names rather than departments. 'Marketing owns pricing' fails at the first handover; a named person with a named deputy does not.

Update SLAs that match decay speed

Not all material decays at the same rate, and applying one review cycle to everything means either wasting effort or being permanently out of date on the fast-moving parts.

1. 1Same-day categoriesPricing, stock and availability, opening-hours exceptions, anything in an active campaign. These have a same-day commitment or they should not be answered from indexed material at all — they should come from a live lookup.
2. 2Within-the-week categoriesProduct changes, delivery terms, new policies. The commitment is that the person who made the change updates the material within the week, not that somebody notices later.
3. 3Quarterly review categoriesGeneral product descriptions, how-it-works material, FAQ answers. These rarely change but rot quietly, and a scheduled read catches what nobody reported.
4. 4Trigger-based updatesAny change to a price list, a policy document or a product catalogue should trigger a knowledge update as part of that change, not as a separate task somebody remembers.

Approval: who may change an answer

Governance fails in both directions. Too little approval and the material becomes a wiki of contradictions; too much and nobody updates anything because the process is heavier than the fix.

• Low-risk material — support answers, phrasing improvements, FAQ additions — should be editable directly by the owner, with a log rather than a gate.
• Commercial material — prices, discounts, terms — needs a second pair of eyes, because a typo here becomes a commitment.
• Legal and compliance wording should be reviewed, not edited. The owner supplies the text; nobody else paraphrases it.
• Deactivation should be as easy as editing. The fastest correction for a wrong answer is switching off the entry that produced it, and if that requires a ticket it will not be done.
• New categories need a decision, not just an upload. Material arriving with no owner is material that will be stale in a year.

Change logs and traceability

When a customer is told something wrong, the useful question is not who is to blame but which entry said it and when it was last touched. That requires two records.

• Which knowledge produced which answer. Without this, investigating a wrong answer means guessing at the material.
• Who changed what, when, and what it said before. A corrected answer that turns out to have been right the first time needs a way back.
• When each entry was last reviewed, distinct from when it was last edited. Confirmed-as-still-correct is a meaningful event and should be recorded as one.
• Which entries are active. A deactivated entry that is still indexed somewhere is a wrong answer waiting to happen.
• Version history on prompts and behaviour rules, not only on content. Tone and escalation wording drift too, and they are harder to reconstruct.

The monthly routine

1. 1Read the knowledge-gap escalationsThe conversations where the bot admitted it did not know are the most accurate list of what to write next. Fifteen minutes with this list is worth more than a planning session.
2. 2Read ten bad conversationsNot aggregate scores — actual transcripts. Drift shows up here first, usually as an answer that is confidently out of date.
3. 3Check the fast-decaying categoriesPricing, stock, hours, campaigns. A five-minute check against the source of truth, every month, regardless of whether anyone reported a problem.
4. 4Review anything untouched for twelve monthsConfirm, update or delete. 'Confirm' is a valid and common outcome and it resets the clock.
5. 5Re-run the test setThe fixed question set from launch, plus whatever real failures have been added since. This catches side effects of the month's edits.

How Vexvon supports governance

Ownership by category is supported structurally: knowledge entries are classified into thirteen types — FAQ, pricing, product, catalogue, branch, campaign, opening hours, policy and others — with automatic type detection, and they can be grouped into categories. That typing is what makes an ownership map assignable rather than theoretical.

Entries can be activated or deactivated individually, which is the mechanism the approval section above depends on: the fastest correction is switching an entry off, and it does not require deleting anything or waiting for a rebuild. Embeddings refresh automatically when an entry changes, so a correction is live without further action.

Traceability comes from answer transparency, which records which knowledge entries produced a given reply. That turns 'the bot said something wrong' into a specific entry with a specific owner. Prompt versions are tracked separately with one active at a time and a path back to the previous one, which covers the behaviour-rule drift that content logs miss.

For the same-day categories, the alternative to an update SLA is not indexing the fact at all: a company's own API can be registered as a tool the agent calls mid-conversation, so stock, order status and availability come from the system that holds them rather than from a copy that has to be maintained.

Frequently asked questions

1. 1What is knowledge governance for a chatbot?The operating model that keeps the material accurate after launch: who owns which answers, how quickly they must update them, who approves changes and what is logged. Without it, accuracy decays quietly from the day you go live.
2. 2Should one person own the knowledge base?No. A single owner becomes a bottleneck and eventually stops. Assign by category to whoever already owns that subject in the business, with named people rather than departments.
3. 3How often should material be reviewed?By decay speed: same-day for pricing, stock and campaigns; within the week for product and policy changes; quarterly for general descriptions; and triggered automatically whenever the underlying source document changes.
4. 4What should be logged?Which knowledge produced which answer, who changed what and when, what it said before, when each entry was last reviewed as distinct from edited, and version history on behaviour rules as well as content.
5. 5What is the fastest way to fix a wrong answer?Deactivate the entry that produced it, then correct it properly. That is why deactivation has to be as easy as editing and must not require a ticket.
6. 6How do you know drift is happening?You mostly do not, from dashboards. Read the knowledge-gap escalations and ten bad transcripts each month; that is where confidently outdated answers surface first.

Write the ownership map first

Before any process design, write a one-page table: category, named owner, named deputy, review cycle. Most organisations discover while writing it that two or three categories have no plausible owner at all — and those are precisely the categories that will be wrong within six months.