Knowledge base

A knowledge base makes knowledge findable, usable, and maintainable; it is not a shared folder

Define whom the knowledge base serves, what it can answer, and what it must not do

The same material used by customer service for procedure, compliance for rule decisions, and customers for public answers carries different authority. Define users, questions, time, and prohibited use before choosing sources and the conditions under which the system must say it does not know.

A complete knowledge base normally separates sources, usable representations, and control information

Originals preserve evidence, parsed passages support discovery, and metadata and access rules govern use. Keep the three linked but distinct so the team can return to an original and update or remove every derivative.

Document, Q&A, rule, graph, and hybrid knowledge bases solve different problems

Long documents preserve explanation, Q&A supports stable frequent questions, rule structures support determinate decisions, and graphs support entity relationships. Choose form from task and evidence instead of forcing every source into the currently fashionable representation.

The knowledge model and metadata determine whether content can be interpreted and filtered correctly

Two similarly titled policies may apply to different regions, products, and dates. Without object type, version, effective period, owner, and access labels, retrieval sees textual similarity but cannot decide applicability.

1. Knowledge objects

   Define stable IDs and granularity for documents, sections, records, facts, terms, entities, relationships, rules, Q&A, procedures, and cases.

   Object catalogue, ID convention, sample records

2. Business semantics

   Record approved names, synonyms, definitions, scope notes, units, states, and relationship direction so that departments do not use one word for different objects.

   Glossary, taxonomy, semantic mappings

3. Source and accountability

   Link every item to a source version, creation or transformation activity, content owner, approver, maintainer, and conflict authority.

   Provenance chain, role register, approvals

4. Time and state

   Distinguish creation, publication, approval, effective, expiry, acquisition, and index time, plus draft, active, superseded, withdrawn, and archived states.

   Validity intervals, state events, version history

5. Applicability and access

   Record organisation, region, product, process, role, language, classification, tenant, permitted use, and prohibited output so filtering occurs before retrieval.

   Scope tags, access policies, permission tests

6. Structure and location

   Preserve heading hierarchy, page and section, table headers, attachments, record keys, anchors, and neighbouring context so a fragment remains understandable and citable.

   Parsed structure, locators, original links

7. Quality and lifecycle

   Record completeness, currency, consistency, parse status, known gaps, review status, review-by date, replacements, and disposition requirements.

   Quality results, issues, review and exit tasks

Build from business questions, then acquire, organise, validate, and publish

Uploading everything first often creates a large repository that cannot answer responsibly. Begin with valuable questions, eligible sources, and a judgement method, then onboard, organise, validate, and release in stages so each content set can show what it serves.

1. 1. Confirm the answerable scope

   For each user task, define the question, correct answer form, source, permission, historical basis, consequence of error, and human escalation.

2. 2. Inventory and approve sources

   Identify official content, systems of record, experts, and external sources. Confirm ownership, rights, applicability, version, and quality instead of ingesting everything accessible.

3. 3. Design objects and metadata

   Decide what remains original text, what becomes a fact or rule, and what needs terminology relationships. Standardise identity, version, access, provenance, and locators.

4. 4. Establish secure acquisition

   Use controlled connectors, exports, or events and retain snapshots, checksums, and failures. Separate raw, intermediate, and approved publication zones.

5. 5. Transform and organise

   Parsing, OCR, cleaning, translation, classification, entity resolution, rule structuring, and chunking must create traceable derivatives; anomalies enter human review.

6. 6. Build indexes and access services

   Choose structured query, full text, keyword, vector, graph, or hybrid retrieval by question, and apply access, status, time, and scope filters before retrieval.

7. 7. Validate by layer

   Test sources and transformations, knowledge objects, access, retrieval, citation, and final answers or actions separately, including normal, boundary, conflict, insufficient, withdrawn, and malicious cases.

8. 8. Publish after authorised confirmation

   Content, business, data, security, and user teams confirm scope, gaps, risk, and maintenance. A successful index build is not release approval.

9. 9. Monitor and maintain

   Track misses, wrong sources, stale content, denied access, feedback, and cost. Reprocess changes with version history, and withdraw content and derivatives when exit conditions are met.

Content, business, technology, and users share knowledge-base accountability

Content owners confirm meaning, business owners decide use and risk, technology maintains ingestion and retrieval, and users reveal real problems. Without roles, obsolete material remains live and retrieval failures are blamed vaguely on the model.

Permissions must survive from the source through chunks, results, citations, and caches

A restricted document must not lose its access boundary when split. Carry permission into derivatives, indexes, results, citations, and caches and reassess it for user, tenant, object, and purpose. High relevance is not authority to see.

Acceptance must test content, retrieval, answers, and access separately

A wrong answer can start with a wrong source, lost parsing, missed retrieval, bad model combination, or failed access filtering. Layered evaluation locates responsibility and prevents one overall Q&A score from hiding a severe leak or source gap.

A knowledge base must preserve source conflicts and must not turn gaps into answers

Value includes knowing when an answer is unavailable. On conflict, an obsolete version, missing attachment, or no eligible evidence, return a visible state and accountable route instead of allowing a generator to fill the gap from plausibility.

Versions and derivatives must be controlled from onboarding through retirement

After a document is retired, parsed text, chunks, vectors, caches, and evaluation questions may remain. Propagate addition, revision, withdrawal, and deletion through derivatives while retaining needed history so present answers and past evidence stay explainable.

Construction example: a procurement knowledge base

This customer-independent procurement knowledge base keeps policy, delegation tables, procedure, and live business data separate while using them together. The focus is permission, version, update, and stop conditions for each class—not a database choice.

Enterprise AI can use a knowledge base for evidence, but retrieval, generation, and action still need controls

A knowledge base supplies governed material; AI still chooses which collection to query, which passages to take, how to combine them, and whether to call a tool. Every step can fail or exceed authority, so correct content does not replace verification of the full RAG and agent chain.

How a knowledge base differs from adjacent concepts

A shared folder stores files, a database stores records, a vector store supports similarity, and RAG is an answer chain. A knowledge base may use each component, but governed content, meaning, access, and maintenance responsibility define it—not one storage technology.