Making Heterogeneous Knowledge AI-Ready
Why RAG, agents and chatbots need a trustworthy knowledge foundation.
Better AI Starts with Better Knowledge
A RAG, an agent or a chatbot can make existing documentation easier to access. But connecting an AI system to a knowledge base does not automatically make that knowledge reliable.
Recent assignments have reinforced a pattern I had already encountered many times throughout my work in technical documentation: the information is usually there, even when it is not obvious where it is, who knows about it, or whether everyone can access it.
Knowledge Becomes Heterogeneous
In many organizations, documentation does not live in a single environment. Several workspaces may coexist: for example, SharePoint and the broader Microsoft 365 ecosystem alongside Confluence and the Atlassian ecosystem, with additional tools chosen by particular teams or for specific business needs.
But information being stored somewhere does not mean it is equally visible to everyone. Access rights differ. Teams do not necessarily know what other teams have documented. Some sources are widely used, while others are known only to the people who created them.
This is one reason enterprise documentation gradually becomes heterogeneous.
That heterogeneity is rarely designed intentionally. It usually develops over time: tools accumulate, authors change, documentation practices evolve, terminology drifts, governance rules are applied unevenly, and information remains available long after its original context has disappeared.
Knowledge Creation Is Collaborative
Knowledge bases reinforce this dynamic in another way.
One of their fundamental principles is to make knowledge creation collaborative. Product managers, developers, consultants, support teams, data scientists and other subject-matter experts can all contribute directly.
This is a major advantage.
Collaborative Knowledge Creates Variation
But opening documentation creation to many contributors also means opening it to different vocabularies, structures, writing styles, levels of detail and maintenance practices.
Knowledge Becomes a Shared Information Space
At the same time, a knowledge base acts as a shared repository of corporate knowledge. One of its fundamental purposes is to make that internal knowledge searchable and retrievable.
That makes it an obvious candidate for RAG systems, agents and other AI-powered interfaces.
As discussed in Documentation Agents: 1. Define the Strategy, the first question is what service the agent is expected to provide. Here, the focus shifts to the quality of the knowledge that service relies on.
The temptation is straightforward: If people already search the knowledge base, why not let AI search it for them?
The difficulty is that AI retrieves from the corpus that actually exists — including its gaps, obsolete layers, terminology variations, implicit context and uncertain sources of truth.
Knowledge Quality Determines AI Sustainability
A RAG does not fix bad documentation.
And this is not only a question of initial answer quality.
The long-term relevance of an agent or RAG system also depends on the quality of the knowledge source it continues to use.
A well-designed knowledge surface can be correctly scoped at launch and still degrade over time if the underlying corpus evolves without equivalent attention. New documents appear, terminology changes, deprecated information remains accessible, lifecycle statuses become inaccurate, and additional sources are introduced.
As discussed in Documentation Agents: 2. Design the Architecture, defining the right knowledge surface is an architectural decision. But even a well-scoped surface can become less reliable if the knowledge it contains is not maintained over time.
The system may therefore produce good results initially and gradually drift toward less consistent or reliable answers — not because the model or agent architecture has necessarily changed, but because the knowledge environment underneath it has.
The long-term reliability of an AI service depends partly on the sustainability of its knowledge source.
The better that source is structured, qualified and maintained, the more robust the AI service built on top of it can remain over time.
AI-ready documentation starts before the RAG.
Understand Where Heterogeneity Comes From
Before restructuring documentation or designing an AI service, take the time to map the existing knowledge environment.
Map the Existing Knowledge Environment
- What sources exist?
- Who produces and maintains them?
- Who uses them?
- What is the history of the documentation?
- Which tools, migrations, reorganizations or changes in practice have shaped it?
- Which parts are actively maintained, and which have simply remained available over time?
- Which sources are considered authoritative, and by whom?
This investigation should not be limited to the content that can already be found in a knowledge base.
Some knowledge may not be documented anywhere.
Technical writers encounter this constantly: interviews with subject-matter experts reveal assumptions, explanations, exceptions and relationships that exist only in people's heads. Those experts may not even perceive them as missing information, because they unconsciously fill the gaps when reading the documentation.
Other pieces of knowledge may already be written down, but outside what the organization formally considers to be its documentation.
A Jira user story may contain valuable functional context. A developer may have documented an implementation decision in a repository or README. Useful explanations may remain in working documents or team spaces without ever having been integrated into the main knowledge base.
Break Down Knowledge Silos
The first task is therefore partly one of breaking down knowledge silos.
Before reorganizing the documentation, it may be necessary to gather these fragments, cross-reference the sources and reconstruct a coherent view of the knowledge surrounding a given subject.
Before restructuring the documentation, you may first need to reconstruct the knowledge.
The underlying documentation problems are not new.
Technical writers have dealt for years with successive generations of tools, inconsistent version control, duplicated content, obsolete documents that were never archived, knowledge retained by individual contributors, and information scattered across systems.
What is new is the intention to make these imperfect corpora directly usable by AI systems.
The AI layer does not create these documentation issues. It makes their consequences more visible.
When Heterogeneity Becomes a Trust Problem
Heterogeneity becomes a problem when it introduces uncertainty into the knowledge available to humans and AI systems.
The issue is not simply that information is distributed across tools, formats or contributors. The real difficulty is determining what that information means, how reliable it is, where it applies and how it relates to other sources.
A retrieval system may find a relevant passage and still lack the context needed to determine which source should take precedence.
- Is the information current?
- Has it been reviewed?
- Is it verified information, an interpretation, an assumption or a temporary working hypothesis?
- Does it apply to the whole product, to one version or only to a particular context?
- Is it authoritative, or simply available?
These distinctions matter because retrieval can technically succeed while the resulting answer remains unreliable.
A page with an incorrect lifecycle status may appear current when it is not. An obsolete source may compete with its replacement. Missing context can turn a valid statement into a misleading generalization.
Hierarchy creates another layer of uncertainty.
Different teams may organize their spaces according to completely different logics: product, project, chronology, department, feature, or no stable structure at all.
-
For humans, this makes navigation unpredictable and makes it difficult to know whether all relevant information has been found.
-
For AI systems, it weakens structural context. Parent-child relationships, position in the hierarchy and proximity to related information may no longer provide reliable signals about meaning, scope or authority.
Recurring Patterns, Lasting Consequences
Across large knowledge environments, several recurring patterns tend to appear:
- Incomplete or implicit knowledge;
- Fragmented knowledge;
- Accumulated historical layers;
- Duplicated or competing sources;
- Lifecycle drift;
- Terminology drift;
- Inconsistent structures and hierarchies;
- Multiple contributors with different conventions;
- Heterogeneous formats;
- Weak or misleading qualification signals.
These patterns affect more than retrieval.
They can weaken the reliability of the corpus, blur the source of truth, distort its effective scope, fragment the company's terminology and identity, make information harder to categorize, and ultimately reduce the quality of the AI-generated output.
The next question is therefore not simply: How do we clean the documentation?
It is:
What level of trust do we expect from the knowledge we are about to expose to AI?
Define the Dimensions of Trust
AI-ready knowledge is not only content. It is content plus qualification signals.
This is also where docs-as-data becomes particularly relevant: documentation is not only a collection of pages, but a knowledge source whose content, metadata, status and relationships can all carry meaning for downstream systems.
Before deciding which documentary levers to use, it is useful to define what makes a knowledge source trustworthy enough to support AI-generated answers.
These qualities can be considered as dimensions of trust rather than as a binary compliant/non-compliant state.
Use Documentation Signals to Make Knowledge AI-Ready
Once the desired qualities of the knowledge source are clear, the documentation can be examined through the signals already available — or those that need to be created.
Identify and Qualify Knowledge Signals
| Documentation lever | What it can express |
|---|---|
| Metadata | Ownership, audience, product, feature, version, language, content type, review dates and other contextual information. |
| Statuses and lifecycle signals | Whether content is draft, reviewed, active, deprecated, archived, or a work in progress. These signals may use native application statuses, page headers, front matter or other mechanisms already supported by the documentation environment. |
| History | How information has evolved, which decisions or versions superseded earlier ones, and how the current state relates to previous states. |
| Canonical information | Which source should be considered authoritative when several sources cover the same subject. |
| Terminology | Preferred terms, aliases, acronyms, previous names, code identifiers and deprecated terminology. A maintained glossary can make these relationships explicit. |
| Structure and hierarchy | Relationships between concepts, procedures, references, features and related pages, including meaningful parent-child structures. |
| Provenance | Where the information comes from, who produced it, and whether it originates from validated documentation, implementation artifacts, interviews or other evidence. |
| Access and confidentiality | Whether a source should be exposed to the AI service at all. |
| Cross-source relationships | How documentation pages relate to code, tickets, release notes or release information, project artifacts and other knowledge sources. |
The purpose is not to maximize metadata or add governance for its own sake.
Each signal should help reduce uncertainty.
AI-ready knowledge is not only content; it is content plus qualification signals.
Examples of Knowledge Qualification Signals
Release Notes as a Source of Product History
Release notes can provide more than product communication.
When they are complete and kept up to date, they can act as a reliable chronological source for the evolution of a feature: when it appeared, when its behavior changed, when it was deprecated or replaced.
This historical information can help distinguish a current feature description from documentation that accurately described a previous version.
A Glossary as a Terminology Reference
Terminology provides another example.
Creating and maintaining a glossary is not only useful for readers. It can document preferred terminology, aliases, acronyms, previous names and explicit relationships between concepts.
Document Status as a Lifecycle Signal
Similarly, lifecycle information already supported by documentation tools should be treated as useful knowledge signals rather than purely visual indicators.
A deprecated banner, a page status, a front-matter field or an archival property can help humans and machines understand that technically accessible information no longer represents the current state.
These signals do not replace editorial judgment.
They make that judgment more explicit and reusable..
AI-Ready Knowledge Must Remain Alive
Making documentation usable by a RAG system, an agent or a chatbot does not freeze the knowledge base in a given state.
Knowledge continues to evolve.
New information is created. Existing content is revised. Products change. Teams reorganize. New contributors arrive. Others leave. Additional tools and sources appear. Terminology evolves, and the boundaries of the useful knowledge environment shift.
This is normal.
The objective is therefore not to create a perfectly homogeneous and static corpus before connecting it to AI.
It is to create a knowledge environment that can continue to live without progressively losing the qualities that make it trustworthy and usable.
That means allowing knowledge bases and documentation corpora to grow, coexist with other information sources and absorb new contributions, while periodically reassessing the forms of heterogeneity and drift identified during the initial audit.
This also means periodically revisiting questions such as:
- Are new knowledge gaps appearing?
- Has terminology started to diverge?
- Are obsolete layers accumulating again?
- Are lifecycle statuses still meaningful?
- Has the source of truth changed?
- Has important knowledge migrated elsewhere?
- Are previously relevant sources still within scope?
The knowledge source therefore needs its own form of continuous evaluation.
This mirrors the lifecycle of the AI services built on top of it.
As discussed in Agentic AI: 3. Test and Evaluate, an agent should not be considered finished once it has been released. Its behavior, usefulness and relevance need to be tested again over time, and it may need to be adjusted, redesigned or eventually retired.
The same principle applies to the knowledge it relies on.
An agent lifecycle and a documentation lifecycle are not separate concerns. They influence each other.
-
A change in the corpus may alter retrieval quality.
-
A terminology drift may affect answers that previously worked well.
-
A new authoritative source may change which information should take precedence.
Conversely, repeated agent failures may reveal documentation gaps, weak metadata, ambiguous terminology or unclear governance that were not visible before.
This creates a feedback loop between documentation quality and AI quality.
AI-ready knowledge is therefore not a finished corpus. It is a maintained knowledge system.
Making existing knowledge AI-ready means improving its quality, structure, qualification and governance while keeping it usable by humans.
But this raises another question: does the same representation of knowledge need to serve both humans and machines?
A Documentation Twin explores the next step: deriving a machine-oriented representation from the same governed knowledge source.
Same knowledge. Different representation.
© Author: Florence Venisse, Technical Documentation & AI Expert – First version dated September 29, 2026