Skip to content

AI Systems

Knowledge base engineering: one question, one current answer

Most businesses have plenty of written knowledge and no way to tell which version is right. Before any search or assistant can help, the library needs structure, versions, access rules and named owners. An assistant will answer fluently from whatever it's given, including last year's policy.
Discuss your systemSee the six parts ↓
How long is labour covered on a water heater we installed?Shared driveWarranty_FINAL_v220222 yearsWarranty_FINAL_v22022supersededWikiWarranty FAQedited 2023not coveredWarranty FAQedited 2023supersededEmailRE: warranty change202190 daysRE: warranty change2021archivedPolicy libraryWarranty policy v420261 year1 yearcurrentFour sources, four answersowner · Operationsreview by · Mar 2027access · all staffLabour on our installs: 1 year · Warranty policy v4 §3 · owner Operations

Plenty of content, little structure

Before any assistant or search tool can help, knowledge has to exist in a usable form. Most organisations have plenty of content and little structure: duplicate versions, unclear ownership, inconsistent metadata, and permissions scattered across tools.

Outdated documents look exactly as authoritative as current ones. People learn to ask the colleague who knows instead, and the colleague becomes the knowledge base. Knowledge base engineering turns the documents into a system people and software can rely on.

Start with a map of where knowledge lives

The first deliverable is an inventory. For the business in our examples, it looked like this.
Shared drivePolicies, price sheets, old quotesThree versions of the warranty policy, and no way to tell which is current
WikiProcedures and onboardingWritten once, edited by whoever happened to notice
Ticket historyHow past problems were solvedGood answers buried in threads, mixed with customer details
Email and chatDecisions about exceptionsNever written back anywhere
The office leadEverything above, plus last month's changesOne person, interrupted all day

Six parts of a knowledge base that holds up

  1. 01

    Inventory

    Where does it live, and who owns it?

    Find every source of knowledge and the person responsible for each, including the ones that are only in someone's head.

  2. 02

    Structure

    What kind of content is it?

    Define content types (policy, procedure, reference, record), the metadata each needs, and how documents relate.

  3. 03

    Normalisation

    Can software read it?

    Extract content from files and tools into one consistent format, keeping headings and tables intact.

  4. 04

    Permissions

    Who may see it?

    Carry the source systems' access rules through, so search and AI respect them.

  5. 05

    Lifecycle

    Is it still right?

    Owners, review dates and versions, so content stays current and old versions retire instead of lingering.

  6. 06

    Access paths

    How do people and software get to it?

    Navigation, search and retrieval, for people and for AI systems, all from the same governed content.

One document, properly kept

Warranty policy v4

type
policy
section
§3 Labour
owner
Operations (operations manager)
version
v4, effective 1 Feb 2026
review by
1 Mar 2027
supersedes
v3, Warranty_FINAL_v2, the 2021 email
access
all staff
used by
knowledge assistant, quote drafting, website FAQ

When the review date comes, the owner gets a reminder. When v5 replaces it, v4 is marked superseded and drops out of answers, but stays in the archive for anyone who needs to know what applied last year.

Every system that answers warranty questions reads this one document, so a change made here reaches all of them at once.

What a knowledge base hands off

In

Sources
drives, wikis, tickets, email
Owners
teams and people
Source permissions
groups, spaces, roles
Knowledge base
structure · versions · access

Out

Current content
owned and dated
Access rules
carried through
One source
for people, search and AI

Worth building when nobody knows where to look

Good fit

  • Knowledge is spread across several tools and owned by different teams.
  • People who need it don't know where to look, or which version to trust.
  • You're planning search or an assistant on top of it.

Not the right fit

  • The knowledge is small and already well organised in one place. Ordinary documentation practice is enough.

Where it's the foundation

Built on top of it

Questions about knowledge base engineering

Do we have to rewrite all our documents?

No. Most of the work is finding, deduplicating, structuring and tagging what already exists, and agreeing owners. Rewriting is for content that is wrong or contradicts itself.

Where does the knowledge base live?

Often where your team already writes, such as a wiki or document library, with structure and metadata added. When content comes from many tools, a purpose-built store may sit behind them. Search and AI indexes are built from it, not instead of it.

Who keeps it current?

Named owners for each content type, with review dates and reminders. Questions people ask that the sources can't answer show owners exactly what's missing.

Can we start with one area?

Yes, and it's usually the right way. Start with the content behind the questions asked most often, such as pricing and warranty, and expand once that is working.