Every enterprise AI initiative I've been called into eventually hits the same wall, and it's never the model. It's the knowledge. The retrieval layer surfaces a 2019 policy next to its 2024 replacement with no way to tell which is authoritative. The agent confidently cites a document that was superseded, drafted-but-never-approved, or written for a different business unit with the same product name. The pilot dies, and the postmortem blames "hallucination."
It wasn't hallucination. It was architecture. The organization's knowledge was never designed to be read by anything (human or machine) and for decades that was survivable because humans compensate. They ask the person at the next desk, they notice the stale letterhead, they know Deb owns pricing. Machines don't compensate. AI is the forcing function that finally makes knowledge architecture a design discipline, and I mean design in the full sense: intentional structure, serving identified users, with testable outcomes.
Two audiences, one corpus
The core constraint is that your knowledge base now serves two readers with different physiologies.
Humans read hierarchically and socially. They navigate by landmark ("it's in the finance wiki"), tolerate ambiguity, and resolve conflicts through context and conversation. They read little and infer much.
Machines read in chunks and embeddings. They navigate by similarity, tolerate no ambiguity they can't detect, and resolve conflicts by: nothing. They don't resolve conflicts. They average over them, which is worse.
The temptation is to build two systems: the wiki for people, the vector store for machines. This is the wrong move, and I've watched it fail repeatedly. Two systems means two sources of truth, which means drift, which means the machine layer becomes a stale mirror nobody trusts. Design one corpus with two rendering targets. The structure lives in the source; humans get it as navigation, machines get it as metadata and chunk boundaries.
Ontology: decide what things are
An ontology sounds academic. Operationally, it's just the answer to a blunt question: what are the nouns of this business, and how do they relate? Customer, account, product, policy, exception, region. Which policies apply to which products in which regions. What supersedes what.
Most organizations have never written this down, and it shows the moment an agent has to act. When "customer" means a billing entity in one system and a human contact in another, a human reader shrugs and adapts; an agent joins the wrong records and takes an action on them.
The operator's guidance:
- Start narrow and load-bearing. Model the 20–40 entities that appear in actual decisions, not a philosophical taxonomy of everything. An ontology nobody maintains is worse than none, because it asserts authority it no longer has.
- Relationships matter more than categories. "Supersedes," "applies-to," "owned-by," "excepted-by" do more retrieval work than any folder tree. The most valuable edge in an enterprise graph is supersedes: it's the difference between an agent citing current policy and citing history.
- Ownership is part of the schema. Every entity type needs a named human steward. An ontology without owners is a document; with owners, it's an institution.
Chunking: the unit of retrieval is a design decision
When machines read your knowledge, they read it in pieces, and the piece is the atom of machine understanding. Chunk badly and no embedding model saves you: split a policy from its exceptions and the agent enforces rules that don't exist; fuse three topics into one chunk and retrieval returns mud.
Chunking is usually delegated to a default splitter (512 tokens, arbitrary boundaries) which is like binding a library's books by cutting every 200 pages regardless of where chapters end. The design questions are:
- What must never be separated? A rule and its exceptions. A number and its unit and effective date. A recommendation and its preconditions. These are semantic atoms; find them and protect them.
- What must never be fused? Content with different authority levels, different effective dates, or different audiences. A chunk that mixes draft and approved language is a defect, not a compromise.
- What context must travel with every fragment? A chunk ripped from "Q3 Pricing Policy (EMEA) effective 2026-01" must carry that lineage inside it, because the retriever won't send the breadcrumbs along. Write documents so that sections survive amputation. This changes how authors write (headers become load-bearing, pronouns become dangerous) and that's the point: authoring standards are chunking strategy enforced upstream.
Metadata: the load-bearing layer nobody funds
Metadata is where knowledge architecture succeeds or dies, because metadata is what lets a machine do the things humans do implicitly. A human glances at a document and reads a dozen signals: age, author, polish, provenance. A machine reads only what you've made explicit.
The minimum viable schema, in priority order:
- Authority: is this official, draft, deprecated, or someone's notes? The single highest-value field, and the one most often missing.
- Temporal validity: effective date, review date, expiry. Knowledge that can't expire can only rot.
- Scope, which products, regions, and audiences this applies to.
- Provenance, who wrote it, who approved it, what it derives from.
- Sensitivity, who and what may read it. Access control is metadata now; your agent's retrieval filter is only as good as this field.
The hard part isn't the schema. It's the economics: metadata is written by people who don't benefit from it, for readers they'll never meet. The fix is structural, not motivational: capture metadata at the point of creation, as a side effect of workflow, and let machines propose values for humans to confirm. Classification is one task current models are genuinely reliable at; use them to bootstrap the layer that makes them useful.
The library metaphor, taken seriously
The metaphor I keep returning to is the library: not for its shelves, but for its profession. A library is not a pile of books plus search. It's a designed system: a catalog (ontology), classification standards (metadata), collection development (deciding what enters), weeding (deciding what leaves), and librarians (stewards with authority to enforce all of it).
Note what the metaphor insists on that most knowledge bases lack:
- Acquisition is curated. Not everything written deserves ingestion. An enterprise corpus that auto-ingests every Slack thread and stale deck hasn't democratized knowledge; it has diluted it below the threshold of trust.
- Weeding is a core function, not cleanup. Librarians remove books deliberately, on schedule, as professional practice. Deletion is contribution. A retrieval corpus is improved as much by what you remove as by what you add.
- The catalog is maintained by professionals. Nobody expects authors to shelve their own books correctly. Yet every enterprise expects document authors to be their own catalogers, then acts surprised at the result.
Where to start
If I inherit a typical corpus tomorrow, the sequence is: pick the one high-value domain where wrong answers are expensive; define its minimal ontology with named owners; set authoring and chunking standards for new content; backfill authority and temporal metadata on the top few hundred documents by retrieval frequency; and delete (actually delete) everything superseded. Then measure the agent's citation accuracy before and after, and use the delta to fund the next domain.
Knowledge architecture is unglamorous, which is exactly why it compounds. Models are rented; everyone has the same ones. A corpus designed for two audiences is owned, and right now it is the scarcest asset in enterprise AI.
Begin with a bounded knowledge domain
An enterprise does not have one knowledge problem. It has many domains with different owners, authority rules, vocabularies and rates of change. Begin with a domain where wrong answers matter and ownership can be established. A policy domain, product domain or operating procedure is often more tractable than an enterprise-wide ingestion programme.
Define the domain by decisions, not repositories. “All SharePoint files” is a storage boundary. “Evidence used to decide retail-mortgage forbearance eligibility” is a knowledge boundary. The second definition tells the team which sources matter, which concepts recur and which errors create consequence.
A domain charter should name the decisions supported, users, authoritative sources, excluded material, legal entities, sensitivity classes and knowledge owner. It should also name the questions the corpus must refuse. A useful boundary specifies what the system must not pretend to know.
Starting with a domain also makes quality measurable. The team can assemble known-answer questions, conflicting-version cases and access tests. It can compare retrieval before and after metadata changes. An enterprise corpus without a bounded decision set tends to optimise search activity rather than answer quality.
Model authority as a graph
Documents do not become authoritative merely because they are stored in an approved platform. Authority comes from an institutional relationship: approved by a named body, effective for a scope, derived from a controlling source or superseded by a later decision.
Represent those relationships directly. A procedure implements a policy. A local instruction narrows a group standard. A decision record authorises an exception. A new edition supersedes an old edition. A research note informs but does not govern. These edges let the retrieval system resolve conflicts before ranking text similarity.
| Relationship | Retrieval effect | Required metadata | Control question |
|---|---|---|---|
| Supersedes | Remove older object from active-answer set | Old and new identifiers, effective time | Is history preserved without being treated as current? |
| Implements | Retrieve detail with the controlling source | Parent policy and applicable scope | Does the procedure contradict its parent? |
| Exception to | Apply only to the named case and duration | Approver, reason, scope and expiry | Has the exception expired? |
| Derived from | Preserve lineage for calculations or summaries | Input objects and method | Can the derived object be reproduced? |
| Informs | Rank as advisory, not controlling | Author, evidence status and review date | Is advisory material visually distinct? |
| Restricted by | Enforce rule before retrieval | Identity, purpose and sensitivity | Can unauthorised content influence generation? |
This graph can begin small. A relational table may be enough. The value lies in explicit semantics, not a fashionable database. SKOS offers a W3C model for concept schemes and mapping relationships. SHACL can express validation constraints for RDF graphs. Use them where interoperability or graph validation justifies the machinery.
Turn authoring into upstream retrieval design
Retrieval quality begins when a document is written. Clear headings, explicit scope, stable identifiers and local definitions help both people and machines. Vague pronouns, hidden exceptions and unlabeled tables create ambiguity that chunking cannot fully repair.
Authoring templates should require purpose, audience, owner, effective date, review date and supersession. A policy section should state its rule before its rationale. An exception should sit beside the rule or carry a resolvable link. A number should include unit, period, currency and source. A table should have headers that survive extraction.
The template should also support semantic atoms. A rule, its conditions and exceptions should remain together. A derived figure should travel with inputs and method. A definition should retain the domain and version in which it applies. The best chunking strategy is often a better document structure.
Machine assistance can propose metadata and identify missing fields. The owner should confirm authority, scope and sensitivity. Do not ask a model to infer approval from tone or formatting. Approval should come from workflow state or an authoritative record.
Separate content preparation from access decisions
An embedding index is not an access-control system. It may reveal restricted information through nearest-neighbour results, metadata, snippets or generated answers. Enforce identity, purpose and resource scope before content becomes eligible for retrieval.
The order matters. Post-generation redaction can miss inferences and derived facts. Pre-retrieval filtering reduces what the model can see. Context assembly should preserve source identifiers, versions and authority labels. Generation should not strip those fields before citations are formed.
Purpose can matter as much as role. A case handler may access customer records for an assigned complaint but not for general research. An auditor may see a trace for control testing under a defined mandate. Encode those distinctions where the institution has the policy and technical capability.
Retrieval logs should record the decision without copying unnecessary sensitive text. Capture user or workload identity, purpose, policy result, source identifiers, versions and time. These events support incident analysis and access review. They also reveal sources that are repeatedly retrieved but never cited or accepted.
Design expiry and retirement as normal states
Knowledge changes. A policy expires. A product closes. A procedure is replaced. A temporary exception ends. If the architecture supports only creation, the corpus becomes more confident as it becomes less current.
Every governed object needs a lifecycle state. Draft, approved, effective, suspended, superseded, expired and archived are distinct. Retrieval rules should define which states are eligible for current answers. Historical questions may retrieve archived material when the time context is explicit.
Use event-driven review for volatile material. A product change, legal update, control incident or source-system migration may trigger review before the calendar date. Fixed review cycles remain useful as a backstop. A review date is not evidence that a review occurred; record the decision and reviewer.
Retirement should preserve lineage. Removing an obsolete source from active retrieval should not erase its role in earlier decisions. Keep a historical identifier, supersession edge and retention policy. This allows an auditor to reconstruct the knowledge available at the time without letting old rules govern current cases.
Evaluate the knowledge layer independently
End-to-end answer quality hides several knowledge defects. Measure the corpus and retrieval layer directly. Can the system find the controlling source? Does it exclude drafts? Does it select the correct jurisdiction? Does it preserve an exception? Does it block unauthorised content? Does the cited passage support the claim?
Build known-answer cases with domain experts. Include conflicting versions, similar terms, missing data, cross-region questions and superseded rules. Add negative cases where the correct result is no eligible source. A system that always returns something will otherwise appear helpful while manufacturing authority.
Test chunking with reconstruction tasks. Ask whether the returned unit contains the rule, conditions and exceptions. Test metadata by holding content constant and varying authority or date. Test access with adversarial identities and purposes. Test citation support at claim level.
Metrics should remain diagnostic. Recall at a fixed depth measures whether the source appears. Authority precision measures whether returned sources are eligible. Supersession error measures use of obsolete material. Citation support measures whether a claim follows from its source. Refusal precision and recall measure behaviour when knowledge is absent.
Sample failures with owners. A retrieval miss may be a vocabulary problem, missing metadata, bad chunking, absent content or incorrect authority. Each has a different remedy. Do not fine-tune the generator to compensate for a corpus defect.
Establish a knowledge operating model
Knowledge stewardship needs recognised work. Domain owners decide what governs. Content owners maintain individual objects. Knowledge architects define schemas and relationships. Platform teams implement retrieval and controls. Risk and privacy teams challenge policy. Product teams bring usage and error evidence.
The operating forum should review a small set of decisions. Which sources entered or left the approved set? Which objects are overdue? Where did retrieval fail? Which conflicts remain unresolved? Which access denials indicate policy friction? Which user questions fall outside the domain?
Prioritise by decision consequence and retrieval demand. A rarely used historical note may wait. A high-use policy with ambiguous scope should not. Usage alone is insufficient because important knowledge may be needed only during incidents.
Funding should recognise that corpus work prevents downstream cost. Better authority metadata reduces wrong-source investigations. Retirement reduces stale answers. Authoring standards reduce manual chunk repair. Provenance shortens review. Access-aware retrieval prevents disclosure paths. These benefits cross product teams, so relying on one project budget creates underinvestment.
The domain should publish a service contract. State covered questions, update frequency, authority rules, access boundary, known gaps and support owner. This gives application teams something stronger than an index endpoint. It gives them a governed knowledge service with explicit limits.
The W3C PROV-O recommendation can represent derivation and responsibility. Dublin Core terms provide common descriptive properties. DCAT supports catalogue interoperability. Standards should reduce local ambiguity. They should not displace the institution’s domain decisions.
Implement the first domain in deliberate stages
Choose a domain owner before choosing a retrieval platform. The owner should be able to decide which source governs, approve scope and resolve conflict. Without that authority, metadata workshops produce recommendations that nobody can enforce.
Inventory the small set of sources that answer most consequential questions. Do not begin by ingesting every repository. For each source, record owner, authority, scope, effective state, sensitivity and supersession. Remove clear duplicates and drafts from the active candidate set.
Build the concept list from real questions. Capture terms users employ, terms sources employ and distinctions that change decisions. Add synonyms carefully. Do not merge concepts simply because an embedding places them nearby. Ask domain experts to review ambiguous mappings.
Define an authoring and chunking contract. Identify which content must remain together and which content must stay separate. Test extraction from tables, lists and scanned files. Reject source formats that cannot preserve the meaning needed for the use until they are repaired.
Implement authority and access filters before tuning ranking. Construct tests where an obsolete source is semantically closer than the current one. Construct cross-role access cases. The system should exclude ineligible content before the generator receives context.
Create a known-answer set and a refusal set. Measure retrieval, authority, citation support and access separately. Review failures with their owners. A missing source needs content work. A wrong version needs lifecycle work. A poor match may need vocabulary, chunking or ranking work.
Launch the domain with a published service contract. State supported decisions, excluded questions, refresh events, known gaps and the escalation owner. Give application teams a stable identifier for the domain version used in their releases.
Establish a monthly operating review at first. Examine new sources, retired sources, overdue reviews, retrieval defects, access anomalies and unanswered demand. Reduce the cadence only when the evidence supports it. The first domain succeeds when ownership and lifecycle continue after the project team leaves.
A corpus has a control plane
Search quality starts before indexing. Content enters through an acquisition decision, receives authority and scope metadata, and remains reviewable until retirement. The retriever should consume those decisions rather than infer them from prose.
| Knowledge object | Required metadata | Retrieval rule | Retirement trigger |
|---|---|---|---|
| Policy | Authority, owner, effective date, scope | Prefer current approved version | Superseded or withdrawn |
| Procedure | Product, region, role, dependencies | Filter by operating context | Process or system changes |
| Decision record | Decider, rationale, date, affected assets | Retrieve as historical evidence | Never silently overwrite |
| Case material | Sensitivity, subject, retention class | Enforce purpose and identity | Retention period ends |
| Research note | Author, source quality, review status | Label as advisory | Review date expires |
Select the treatment by authority and volatility
High authority · low volatility
Version carefully. Review on a fixed cadence. Examples include policy principles and approved definitions.
High authority · high volatility
Attach effective dates and event-driven review. Examples include rates, limits and operational procedures.
Low authority · low volatility
Keep as background material. Label the advisory status and avoid silent promotion.
Low authority · high volatility
Exclude by default. Ingest only for a specific investigative purpose with expiry.
| Control question | Metric | Diagnostic sample |
|---|---|---|
| Is the right source retrievable? | Recall at a fixed depth | Known-answer questions by domain |
| Is the current source preferred? | Superseded-source rate | Queries with old and new versions |
| Is access enforced before generation? | Unauthorised retrieval rate | Cross-role adversarial tests |
| Can a claim be checked? | Citation resolution rate | Sentence-to-source inspection |
| Does ownership work? | Overdue-review count | Assets past review or expiry |
The W3C PROV-O recommendation provides a formal vocabulary for provenance. Dublin Core terms cover widely used descriptive metadata. The W3C Data Catalog Vocabulary helps describe datasets and catalogues. NIST SP 800-53 connects access, audit and information-governance controls. The NIST AI RMF supplies the wider risk lifecycle.
These standards do not choose an enterprise ontology. They make its obligations more explicit. The model should rank knowledge only after the organisation has decided what is authoritative, current and permitted.