Tech Writers May Be Solving the Wrong AI Problem
Why organizing information isn't the same thing as defining meaning
Many organizations are preparing to invest heavily in AI systems that consume documentation. At the same time, much of that documentation was written for human readers who are good at filling in gaps, making assumptions, and interpreting context that was never explicitly stated.
Humans do this so naturally that we rarely notice it. Machines don’t.
I was thinking about that while reading a recent LinkedIn post from knowledge graph researcher Benny Cheung. He described the progression from data to taxonomy to ontology to knowledge graphs and argued that organizations that stop too early in that progression are likely to struggle with AI.
The post resonated with me because technical writers have been dealing with parts of this problem for years, although we don’t usually use the same vocabulary.
Organizing Information Isn't The Same Thing As Defining Meaning
Most organizations have plenty of places to store information. They have databases, content management systems, knowledge bases, SharePoint sites, and file repositories.
Storage isn’t the problem.
Cheung points out that a database schema and an ontology solve different problems. A schema describes how information is organized. An ontology describes what something is, how it relates to other things, and what rules govern those relationships.
Many organizations blur those distinctions. They assume that once information is structured, categorized, and stored, meaning somehow comes along for the ride.
It doesn’t. Not even close.
Consider the difference between a content label such as “firmware update” and a description that explains who performs the update, what event triggered it, what conditions must be true before it can begin, and what happens when it succeeds or fails.
👉🏾 One helps identify a topic.
👉🏾 The other helps explain how something works.
For AI systems, those details matter.
Taxonomy Helps You Find Things
Technical documentation teams have spent years building taxonomies. We classify products, features, audiences, document types, and metadata values. That work is useful because it helps people find information.
The challenge is that classification only answers part of the question.
AI systems increasingly depend on structured context, not just text. Knowledge graphs and RDF (Resource Description Framework) represent entities and the relationships between them, while action and process models make it explicit who performs an action, what object is affected, what events or conditions shape a workflow, and how activities connect across a process. That structure helps AI systems retrieve information with context and perform multi-step tasks more reliably.
Those relationships are often scattered across multiple documents or left unstated because human readers can usually infer them. AI systems don’t always infer them correctly or consistently.
That’s where many documentation repositories start to show their age. The information exists, but the relationships are incomplete, inconsistent, or implied.
Why Documentation Can Confuse AI
When people read our documentation, they bring a lifetime of experience to the process. They know that customers and technicians have different responsibilities. They recognize that a setup procedure may not apply during routine operations. They can usually tell when a warning belongs to a specific circumstance rather than every circumstance.
Documentation often depends on that kind of judgment.
Large language models don’t read the way people do. Not even remotely. They generate responses based on patterns and probabilities. When key relationships are missing, the model may connect things that shouldn’t be connected, skip conditions that matter, or assign actions to the wrong person or system.
The result can sound reasonable while being wrong.
That’s one of the reasons I’ve been working on the TRACE framework:
Tasks
Roles
Actors
Conditions
Events
The framework grew out of a simple observation. Many documentation problems that affect AI have less to do with missing information than with missing context. The facts may be present, but the relationships between those facts often aren’t.
Technical Writers Are Already Working in This Space
Tech writers routinely define components, describe workflows, document responsibilities, explain dependencies, and identify conditions that affect outcomes.
Most of us think of that as documentation. But, viewed another way, it’s also the work of defining how a system operates.
That’s why I think some organizations are overlooking a valuable source of expertise. They want AI systems that can answer questions across large collections of enterprise knowledge, but they often treat documentation as a publishing function rather than a knowledge-definition function.
The people who understand the relationships are frequently the same people who wrote the documentation.
Why Knowledge Graphs Are Back In The Conversation
Knowledge graphs have been around for years, but many organizations never saw a compelling reason to invest in them. Search generally worked “good enough.”
Generative AI changed expectations. Organizations now want systems that can explain relationships, answer questions in context, connect information across departments, and adapt responses to different situations.
Those capabilities depend on more than retrieving content. They depend on understanding how pieces of information relate to one another.
Knowledge graphs can help with that, but only if the underlying content contains clear relationships. If the source material is ambiguous, the graph inherits the ambiguity.
At some point the AI starts filling in the blanks. What appears to be an AI problem may be exposing weaknesses that have existed in our documentation all along.
A Different Way to Think About AI Readiness
Many conversations about AI readiness focus on models, tools, and infrastructure. Those things matter. But organizations may also need to look at the information itself.
👉🏾 Is operational context explicit?
👉🏾 Are actors clearly identified?
👉🏾 Are conditions documented?
👉🏾 Are workflows connected in ways that a machine can follow without making assumptions?
Those questions sound a lot like documentation questions.
That’s why Cheung’s post caught my attention. It highlights a gap that technical writers have been working around for a long time. As organizations push AI deeper into customer support, training, service delivery, and enterprise search, that gap becomes harder to ignore.
The issue may not be that organizations lack content. It may be that too much of the meaning still lives in the heads of the people reading it. 🤠