The Chief Information Officer (CIO) is the adult in the room who is responsible for everything that plugs in, connects to Wi-Fi, stores, moves, secures, or even breathes near company information.

If a system crashes, a server overheats, or someone clicks on an email promising a free vacation to a romantic paradise, the CIO’s blood pressure rises in direct proportion.

In theory, the CIO sets enterprise technology strategy. In practice, they referee a daily cage match between innovation and risk.

The Chief Executive Officer (CEO) wants AI everywhere. The Chief Financial Officer (CFO) wants to lower cost. The Chief Information Security Officer (CISO) wants nothing to move ever again. The marketing team wants a new platform by Tuesday. The software engineers want six months and a clean rewrite of the code. The CIO wants a nap.

CIOs live in a world of acronyms that sound like secret codes: ERP, CRM, IAM, SIEM, SASE. They speak fluent “roadmap” and can say “governance framework” without blinking. They must believe in transformation while also working non-stop to prevent catastrophe, which is a bit like remodeling your kitchen during a hurricane.

A good CIO sees around corners. A tired CIO sees around corners and finds another compliance audit waiting there. They are tasked with modernizing legacy systems built in the late Cretaceous period while keeping the company running 24/7, because downtime is apparently more offensive than sin.

They are equal parts strategist, diplomat, therapist, and fire marshal. They promise agility while enforcing controls. They encourage experimentation but quietly calculate the blast radius of every experiment. They know that “just one small integration” is rarely small and never — ever — just one.

If everything works, no one notices. If one thing breaks, everyone notices.

Which means the CIO’s true job description might read: Keep the lights on. Keep the hackers out. Make it scalable. Make it cheaper. Make it faster. And whatever you do, don’t let it be your fault. 🤠

What is an LLM (Large Language Model)?

An LLM predicts the next most likely token based on patterns learned from massive amounts of text.

What it’s good at:

• Fluent language generation

• Summarizing, rewriting, translating

• Answering questions that resemble things it has seen before

What it is not designed to do:

• Prove correctness

• Track rules or constraints reliably

• Reason step-by-step unless prompted very carefully

Key limitation for technical documentation:

An LLM can sound right while being wrong — confidently.

This is one reason why LLM-only chatbots hallucinate procedures, mix product versions, and invent configuration options.

What is an LRM (Large Reasoning Model)?

An LRM is designed to reason, not just predict text. It explicitly performs intermediate steps such as planning, verification, constraint checking, and logical evaluation before producing an answer.

Common characteristics:

• Multi-step reasoning

• Internal validation of outputs

• Better handling of math, logic, and procedures

• More deliberate (and often slower) responses

Think of it this way:

• LLM: “What sounds like the right answer?”

• LRM: “What must be true for this answer to be correct?”

A current example category includes “reasoning models” like OpenAI’s o-series (for example, o1), though the industry is still settling on standard terminology.

Why Tech Writers Should Care (A Lot)

For a long time, documentation had a fairly predictable role. People searched it, skimmed it, and read it. If they misunderstood something, that misunderstanding usually stayed local. The consequences were real, but they were bounded by human interpretation.

That boundary no longer exists.

Today, AI systems sit between your documentation and your users. They answer questions, explain features, recommend actions, and onboard customers. Increasingly, they do not simply quote documentation. They reason over it. That shift fundamentally changes the stakes.

With traditional LLMs, poor documentation produced awkward or incorrect answers. With reasoning-oriented models, poor documentation produces incorrect decisions. A vague prerequisite, an implied condition, or an ambiguous rule is no longer just a writing issue — it becomes a logical flaw that propagates through automated systems. When an AI reasons from content that is incomplete or inconsistent, it fills in the gaps with confidence.

This is where the difference between “sounds right” and “is right” becomes painful.

As LRMs come into play, documentation stops behaving like narrative text and starts functioning like a knowledge system. Models attempt to infer intent, reconcile contradictions, and determine applicability. If your content relies on human intuition — phrases like “usually,” “in most cases,” or “as needed” — the model has nothing solid to anchor to. Humans fill those gaps naturally. Machines guess.

That guessing erodes trust. And trust is now part of the product.

This also reframes what “AI-ready documentation” really means. Early conversations focused on whether chatbots could answer questions from docs. The more important question now is whether AI can reason correctly from those docs. That depends far less on elegant prose and far more on structure, clarity, and intent. Modular topics, explicit conditions, clean version boundaries, and clearly stated rules outperform beautifully written but loosely organized pages.

For tech writers, this is not a threat. It is a return to relevance.

As organizations realize that AI output is only as reliable as the knowledge beneath it, someone must own that knowledge. Someone must decide what is authoritative, what applies in which context, and what must never be inferred. That work does not belong to the model. It belongs to the people who design, govern, and maintain the content — tech writers.

In a reasoning-driven world, documentation is no longer passive reference material. It is operational input. It drives automated explanations, customer decisions, and support outcomes. When something goes wrong, leaders will not ask, “Why did the AI hallucinate?” They will ask, “Why did our knowledge allow it to?”

Tech writers are uniquely positioned to answer that question — and to prevent it from being asked at all.

The Practical Takeaway For Tech Writers

You do not need to become an AI engineer. You do need to write content that survives reasoning, not just reading.

That means:

• Making assumptions explicit

• Separating rules from examples

• Removing ambiguity and implied steps

• Enforcing version and product boundaries

• Treating documentation as executable knowledge

👉🏾 LLMs reward good writing. LRMs reward good information architecture. 🤠

See also:

• OpenAI research on reasoning models and evaluation

• Chain-of-thought and reasoning behavior in language models

• Discussion of limitations of next-token prediction models

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

By Scott Abel, The Content Wrangler

If you’ve spent the last two years working to convince executives that generative artificial intelligence (genAI) is not a magical oracle that can decode your company’s content chaos into helpful customer experiences, congratulations — you’ve already glimpsed the future that the newly formed Kinetic Council is preparing us for.

Of course, artificial intelligence (AI) isn’t the problem. The problem is that we’re feeding AI systems content the way a toddler feeds a DVD player — shoving in whatever fits and hoping something delightful happens.

Instead, we get mishaps, hallucinations, compliance failures, broken customer journeys, and outputs that read like the chatbot is having an existential crisis.

AI augmentation (think adding semantic metadata) and structural transformation aren’t “nice to have” any longer. They are the cost of entry for intelligent experiences.

And the savvy pros who know how to build this foundation — content strategists, technical writers, data modelers, taxonomists, ontologists — are suddenly more essential than ever. So essential, in fact, that they just got a new professional home.

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Enter the Kinetic Council, a freshly minted 501(c)(3) nonprofit built for this moment of upheaval, transformation, and (dare we say) opportunity. Think of it as the guild for the era of intelligent systems. A place where the people who design, structure, model, and operationalize knowledge can build the future together instead of quietly fixing everyone else’s messes from the shadows.

A Professional Landscape in Freefall

The Kinetic Council didn’t appear because someone thought, “What the world really needs is another association.” It appeared because the institutions that once served knowledge professionals collapsed. The Society for Technical Communication (STC) — a foundational organization for more than 70 years — shut down. The Special Libraries Association also shuttered. Two pillars of the knowledge industry vanished just as AI reshaped everything about how knowledge distribution works.

As Cruce Saunders, the Council’s founder and chair, says, “The death of STC isn’t just an ending. It’s a signal that we’re ready for something new.”

For decades, content creators, data architects, and semantic specialists were treated like separate species who occasionally shared a conference hallway but rarely a strategic conversation. AI shattered that illusion.

Today, every functioning intelligent system depends on the convergence of these domains. Content professionals shape what humans need. Data professionals shape how information flows. Semantic professionals shape how concepts relate and how systems reason.

These worlds are no longer adjacent. They are — as Peter Morville of Semantic Studios declares — intertwingled.

We Need “Kinetic” Content Because Static Knowledge Doesn’t Power AI

The Council’s name reflects a foundational shift. Nothing is static anymore (not content, not data, not user intent, and certainly not the systems delivering knowledge). We’ve moved from publishing to orchestrating. From structured documents to continuously adapting knowledge flows. From managing information to engineering the substrate that AI relies upon to behave responsibly.

The Council expresses this as a “golden thread”: Human structured content → semantically enriched → powering intelligent AI systems

This isn’t poetry. It’s the architectural reality behind every AI system that actually works.

Why This Organization Is Needed Now

Three forces collided that made the Kinetic Council not just useful, but necessary.

1️⃣ The first is AI anxiety — a workplace epidemic that has left many professionals wondering whether automation will erase entire career paths. Despite the bold claims circulating in Silicon Valley, the idea that AI can replace the people who build, manage, and maintain the knowledge layer is fantasy.

AI is only as reliable as the structure and semantics that guide it. Without them, organizations simply scale risk faster.

2️⃣ The second is an enormous skills gap. Traditional educational pathways don’t prepare professionals to design knowledge graphs, orchestrate multi-agent workflows, or establish the governance frameworks needed to prevent AI systems from drifting into nonsense.

Most organizations don’t even know how to hire for these capabilities yet.

3️⃣T he third is the collapse of professional infrastructure. With STC gone, thousands of practitioners needed a place to gather, learn, collaborate, and evolve. The Kinetic Council stepped into that vacuum.

What the Kinetic Council Actually Is

The Council brings together professionals across content, data, and semantics — recognizing that these are no longer discrete career tracks but interdependent components of a single field. Its leadership includes long-standing figures in content, strategy, and semantic design: Deane Barker as president, Cruce Saunders as founder and chair, Hilary Marsh as secretary, Rahel Bailie guiding communications, and Larry Swanson shaping semantic and ontology frameworks.

It is, in effect, a professional big tent for those who architect knowledge systems.

A Certification for the Intelligent Era

One of the Council’s most significant contributions is the upcoming Knowledge Architecture Professional certification (launching in 2026 with Virginia Tech). It is intended for practitioners who already know how to structure content or model data and want to understand how those skills translate into AI-enabled knowledge systems.

The program introduces kinetic information concepts, schema and content model development, semantic layering, taxonomy and ontology work, and foundational knowledge graph design. A capstone integrates these components into a real-world challenge.

If you have ever found yourself explaining to a colleague that the reason a chatbot is hallucinating is because the system doesn’t understand the distinction between a concept, a component, and a configuration setting, you are already qualified for this curriculum.

Why CX, EX, DX, and Marketing Leaders Should Care

Leaders should care because customer experience is now mediated by AI in more ways than most organizations acknowledge. And AI, despite its fluency, is brittle. It depends not on clever prompts or model size but on well-structured, semantically rich, well-governed knowledge.

This is why the Kinetic Council’s mission matters so deeply to leaders in digital experience and customer experience. AI will not save you from your content debt. It will shine a spotlight on it. The foundation for trustworthy AI isn’t the model — it’s the knowledge architecture behind it.

Companies deploying AI without a semantic spine are discovering that you can scale hallucinations far more quickly than you can scale accuracy. The only safeguard is the people who understand structure, intent, governance, and meaning.

And those people now have a professional home.

The Future Role of Content Professionals

The Council isn’t preserving past identities. It’s articulating future ones.

Technical communicators and content strategists are no longer only creating content. They are designing the systems through which content becomes knowledge and knowledge becomes action. They are moving from producing artifacts to orchestrating ecosystems. From writing documents to mapping the logic that determines how AI decides what to generate, when to generate it, and why.

Saunders puts it this way: “We are not being displaced by AI. We are being called to guide AI toward serving human flourishing.”

That shift is already underway in organizations everywhere. The Council simply names it, formalizes it, and supports the people living it.

How To Participate

If you work in digital experience, customer experience, content design, or marketing, the shifts the Council is responding to are already shaping your work. Your systems are getting smarter (on good days) and more unpredictable (on most days). Your teams are hungry for clarity and guidance. And your content and data foundations are under unprecedented strain.

You can participate in several ways. You can join the Council’s community, contribute your own expertise, and collaborate with others who are defining best practices for AI-era knowledge work. You can explore the educational programs, mentor emerging practitioners, or advocate in your organization for the structural investments your AI initiatives truly require.

What matters most is taking part in shaping the profession that will define the next decade. The silos that dominated this landscape for 20 years are gone. A new, integrated field is emerging. And the Kinetic Council is the first organization building the infrastructure for it.

Be Part of Architecting What’s Next

AI is rewriting the landscape of digital experience, but it isn’t rewriting the laws of knowledge. Organizations that place structured content, semantic clarity, and knowledge architecture at the center of their AI strategies will define the next era of trustworthy, human-centered intelligent systems.

The Kinetic Council didn’t arise to preserve what was lost. It arose to architect what comes next.

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Technical writers keep hearing that Retrieval-Augmented Generation (RAG) makes AI answers more accurate because it grounds responses in real content. That is true — but it’s only part of the story.

RAG is often described as “LLMs plus search.” That description is incomplete — and for technical writers, potentially misleading.

Ontology-grounded RAG is a more advanced approach that anchors AI responses not just in retrieved content, but in an explicit semantic model of meaning. It ensures that AI systems retrieve and generate answers based on what things are, how they relate, and under what conditions information is valid.

If AI is becoming the public voice of our products, ontology-grounded RAG is how we keep that voice accurate, consistent, and accountable.

If you work with structured content, metadata, or controlled vocabularies, this topic is very much in your lane.

Why Standard RAG Is Insufficient

Standard RAG works like this:

1. A user asks a question

2. The system retrieves relevant chunks of content (documents, passages, topics)

3. An LLM generates an answer using that retrieved text as context

This improves accuracy over “pure” generative AI, but it still has limits:

• Retrieval is often keyword- or embedding-based, not meaning-based

• Related concepts may not be retrieved if the wording differs

• The model may mix incompatible concepts or versions

• There is little accountability for why something was retrieved

What Changes With Ontology-Grounded RAG?

Ontology-grounded RAG adds a formal knowledge model — an ontology — between your content and the AI.

An ontology explicitly defines:

• Concepts (products, features, tasks, warnings, roles, versions)

• Relationships (depends on, replaces, applies to, incompatible with)

• Constraints (this feature only applies to this product line or version)

• Synonyms and preferred terminology

Instead of asking, “Which chunks are similar to this question?” the system can ask:

“Which concepts are relevant, and what content is authoritative for those concepts in this context?”

Ontology-Grounded RAG In Plain Language

Here is the simplest way to think about it:

• Standard RAG retrieves text that looks relevant

• Ontology-grounded RAG retrieves content that means the right thing

The ontology acts as a semantic spine that keeps AI answers aligned with reality.

Why technical writers should care

Ontology-grounded RAG rewards practices technical writers already value:

1. Clear concept definitions

If we cannot clearly define what a “feature,” “module,” or “service” is, our AI cannot either.

👉🏾 Ontologies force clarity.

2. Structured, modular content

Topic-based authoring (DITA, component content) maps naturally to ontological concepts.

👉🏾 Long narrative documents do not.

See also: What is the Darwin Information Typing Architecture (DITA)?

3. Metadata that actually matters

In ontology-grounded systems, metadata is not decorative. It drives:

• Retrieval

• Filtering

• Disambiguation

• Answer justification

👉🏾 This turns metadata work into high-leverage labor.

4. Fewer hallucinations, better trust

When an ontology enforces relationships and constraints, the AI cannot easily:

• Combine incompatible product features

• Ignore version boundaries

• Answer outside its authority scope

👉🏾 This is how you move from plausible answers to defensible answers.

Read more

AI systems now answer customer questions, explain features, and guide users of an increasing variety of products and services through tasks they need to complete.

In many organizations, they do this instead of sending people to the documentation.

Sometimes they do it without ever showing the customer the documentation at all.

This means our technical documentation has quietly stopped being reading material and started a new career as knowledge infrastructure. It is now the raw material from which AI systems assemble confident, well-phrased answers — whether those answers are spot-on or otherwise wildly incorrect.

Recent research (👈🏽 PDF) from EMNLP 2025 Conference on Empirical Methods in Natural Language Processing explains why so many of these systems sound smart while being wrong, and why fixing the problem has less to do with “better AI” and more to do with how documentation is structured.

Let’s talk about what the research found (and why tech writers are holding the keys to AI success, whether they asked for them or not).

First, Let’s Be Very Clear About What This Is Not

This is not about documentation of AI products.

This is about AI systems that:

Read more

In the documentation field, technical communicators often use words like taxonomy, metadata, controlled vocabulary, and knowledge graph interchangeably. They are not the same thing.

An ontology sits above all of them.

If AI systems are now reading, interpreting, and speaking on behalf of our documentation, understanding what an ontology is—and what it is not—becomes essential.

A Plain-Language Definition of Ontology

In the context of technical documentation:

An ontology is a formal model that defines what things exist in our domain, what they mean, and how they are allowed to relate to one another.

It does not store content. It does not store prose. It defines meaning and rules.

Why “Meaning” Matters More Than Ever

Traditional doc systems assume a human reader. Humans infer meaning from context, tolerate inconsistency, and notice when something feels “off”.

AI systems do none of that reliably. They need meaning to be explicit, not implied; exactly what an ontology provides.

What An Ontology Actually Contains

In technical documentation, an ontology typically defines four things.

1. Concepts

The things that exist in your product and documentation universe.

Examples:

• Product

• Product version

• Feature

• Component

• Task

• Configuration

• Warning

• Error message

• API endpoint

• User role

An ontology answers: “What kinds of things are we allowed to talk about?”

2. Relationships

How those concepts connect to each other.

Examples:

• Feature is part of Product

• Task configures Feature

• Warning applies to Task

• Feature is deprecated in Version

An ontology answers: “How are these things allowed to relate?”

3. Constraints

Rules that prevent invalid combinations.

Examples:

• This feature only applies to certain product versions

• This task is only valid for admin users

• This configuration is incompatible with another feature

• This warning must appear whenever a specific condition exists

An ontology answers: “What must never be combined or inferred incorrectly?”

4. Terminology control

Shared understanding of language.

Examples:

• Preferred terms vs. synonyms

• Deprecated terms

• Acronyms and expansions

An ontology answers: “When we say a word, what do we mean—and what do we not mean?”

Ontology vs. Taxonomy vs. Metadata

These are related, but not interchangeable.

Taxonomy

A taxonomy organizes things into hierarchies.

Example:

• Product

  • Feature

    • Sub-feature

Taxonomies answer: “How do we group things?”

Metadata

Metadata describes individual content objects.

Example:

• Product = X

• Version = 4.2

• Audience = Admin

Metadata answers: “What attributes does this piece of content have?”

Ontology

An ontology defines the rules behind both.

It answers:

• What counts as a Product?

• What is the difference between a Feature and a Configuration?

• Can a Task apply to multiple Products?

• When is something invalid, deprecated, or incompatible?

Without an ontology:

• Taxonomies drift

• Metadata becomes inconsistent

• AI systems guess

Why Ontologies Matter Specifically For Technical Documentation

1. They prevent concept drift

Over time, teams start using the same word to mean different things.

Ontologies force alignment:

• A feature is not a task

• A task is not a concept

• A version boundary is real, not optional

This clarity improves both human comprehension and AI accuracy.

2. They enable trustworthy AI answers

AI systems that rely on documentation increasingly use semantic retrieval and generation.

Without an ontology:

• AI retrieves text that sounds relevant

• Answers may combine incompatible concepts

With an ontology:

• AI retrieves content that is conceptually valid

• Constraints prevent nonsense answers

This is the foundation of ontology-grounded RAG.

3. They elevate the role of technical writers

Ontologies surface a truth many organizations ignore:

Documentation is not just content. It is a knowledge system.

Technical writers are uniquely qualified to:

• Define concepts clearly

• Establish boundaries and intent

• Model relationships humans understand intuitively

Ontologies make that expertise visible and strategic.

See also: What Is Ontology-Grounded Retrieval-Augmented Generation?

What An Ontology Is Not

An ontology is not:

• A style guide

• A glossary (though it may reference one)

• A CMS configuration

• A single diagram created once and forgotten

An ontology is a living semantic contract between:

• Content

• Tools

• AI systems

• Humans

When Do You Need An Ontology?

You especially need an ontology if:

• Your products are modular or platform-based

• You support multiple versions simultaneously

• You are building or buying AI assistants

• Your documentation feeds chatbots or copilots

• Consistency and trust matter

If AI is now the front door to our documentation, an ontology is the lock that keeps the wrong answers out.

The Takeaway For Tech Writers

In technical documentation, an ontology answers the hardest question of all:

“What does this actually mean — and what is it allowed to mean?”

Writers who help define and govern ontologies shape how:

• Content is retrieved

• Answers are generated

• Products are understood

As AI becomes the voice of your documentation, ontologies decide whether that voice is informed — or improvising.

And improvisation is not a strategy. 🤠

A DITA topic is a small, self-contained unit of information designed to answer one specific user need. Not a chapter. Not a page. Not a long narrative. One purpose. One job.

If you remember nothing else, remember this: DITA topics exist to do one thing for one user intent — clearly, consistently, and reuse-ready. 🧐

That single idea explains why DITA works so well at scale and why it behaves differently from traditional document-centric authoring.

See also: What is the Darwin Information Typing Architecture (DITA)?

What Makes a Topic a Good Topic?

A DITA topic is effective when it meets these criteria:

• Single intent — It answers one question or supports one task

• Self-contained — It makes sense without relying on surrounding prose

• Context-aware — Metadata defines product, version, audience, and conditions of use

• Reusable by design — It can appear in multiple documents without rewriting

If a piece of content reads awkward when reused, it probably wasn’t written as a true topic.

Why DITA Topics Exist

Before DITA, most technical documentation followed a document (book) model:

• Long manuals

• Linear chapters

• Content written once, reused by copy-paste

• Updates scattered across multiple files

That model breaks down when you need to:

• Reuse content across products and versions

• Publish to multiple outputs (PDF, web, help systems, chatbots)

• Keep information accurate over time

• Support automation, search, and AI

DITA flips the model. Instead of starting with a document, you start with topics.

The Three Core Types of DITA Topics

Most DITA implementations rely on three foundational topic types. Each enforces intent.

1. Concept Topics — “What is this?”

Concept topics explain ideas, principles, or background information.

Examples:

• What a feature does

• Why a setting exists

• How a system behaves

They help users understand before they act.

2. Task Topics — “How do I do this?”

Task topics walk users through steps to complete a goal.

Characteristics:

• Clear goal

• Prerequisites

• Ordered steps

• Expected results

They answer action-oriented questions and work especially well for procedural content and automation.

3. Reference Topics — “What are the details?”

Reference topics provide structured facts.

Examples:

• Parameters

• Commands

• Error codes

• Field definitions

They prioritize accuracy, consistency, and scannability over narrative flow. 🤠

Guest post by: Fabrizio Ferri-Benedetti

Hey you,

Yes, you, who are thinking about not hiring a technical writer this year or, worse, erased one or more technical writing positions last year because of AI.

You, who are buying into the promise of docs entirely authored by LLMs without expert oversight or guidance.

You, who unloaded the weight of docs on your devs’ shoulders, as if it was a trivial chore.

You are making a big mistake. But you can still undo the damage.

It’s been a complicated year, 2025. When even Andrej Karpathy, one of OpenAI’s founders, admits, in a fit of Oppenheimerian guilt, to feeling lost, you know that no one holds the key to the future. We flail and dance around these new totems made of words, which are neither intelligent nor conscious, pretending they can replace humans while, in fact, they’re glorified tools.

You might think that the plausible taste of AI prose is all you need to give your products a voice. You paste code into a field, and something that resembles docs comes out after a few minutes. Like an anxious student, eager to turn homework in, you might be tempted to content yourself with docs theatre, thinking that it’ll earn you a good grade. It won’t, because docs aren’t just artifacts.

“You keep using that word. I do not think it means what you think it means.”

— The Princess Bride

When you say “docs”, you’re careful to focus on the output, omitting the process. Perhaps you don’t know how docs are produced. You’ve forgotten, or perhaps never knew, that docs are product truth; that without them, software becomes unusable, because software is never done, is never obvious, and is never simple.

Read more

Search is no longer about links

Technical writers are watching the same shift everyone else is watching: search engines are turning into AI-driven answer engines. Instead of sending users to web pages or help sites, these systems increasingly synthesize and deliver answers directly inside search results pages and chat interfaces.

For publishers who depend on referral traffic 📈, this raises alarms. For technical writers, it raises a different — and potentially more interesting — question:

If AI systems are now the primary readers of our content, are we writing in a way machines can actually understand?

Uncomfortable Truth: AI Can’t Make Sense of Unstructured Content Blobs

Large language models perform best when they can identify intent, scope, constraints, and relationships. Unstructured prose forces them to guess. That guessing shows up as hallucinations, incomplete answers, or advice taken out of context.

👉🏾 PDFs, long HTML pages, and loosely structured markdown were designed for human reading, not machine reasoning.

They obscure:

• What task the user is trying to complete

• Which product version applies

• What prerequisites or warnings matter

• Whether an instruction is conceptual guidance or procedural truth

When AI search engines ingest this kind of content, they flatten it. The result they provide may sound fluent, but it’s dangerously lacking in the precision department.

Read more

In AI and Accountability, Sarah O’Keefe argues that organizations are chasing the wrong goal with generative AI in content creation. Many businesses describe success as producing “instant free content,” but that’s a flawed metric. The true organizational goal isn’t volume of output — it’s content that supports business objectives and that users actually use.

AI Produces Commodity Content

O’Keefe points out that:

• Content is already treated as a commodity in many marketing teams

• Generative AI excels at producing generic, average content quickly

• That’s fine for low-level output (but it doesn’t create quality, accurate, domain-specific content on its own)

• When the goal is high-value content, simply doing “more” with AI fails

O’Keefe mirrors broader industry cautions that AI is very good at pattern synthesis but struggles with original, accurate, context-aware creation without structured inputs.

AI Can Raise Average Quality — But It Won’t Raise Above Average

O’Keefe emphasizes that:

• If your current content is below average, AI might improve it

• If your content needs to be above average, generative AI does not reliably get you there without expert oversight

• This performance gap stems from how AI models generate outputs — they produce the statistical average of what they’ve been trained on

This is an important distinction for tech writers whose docs must be precise, technically correct, and trustworthy.

Accountability Doesn’t Go Away With AI

A central theme is: authors remain accountable for the accuracy, completeness, and trustworthiness of content they publish, regardless of whether AI assisted in generating a draft. O’Keefe gives practical examples:

• AI can article-spin but still generate bogus reference

• AI won’t justify legal arguments or identify critical edge cases

• Errors from AI are still your responsibility if you publish the content

This has real implications for technical documentation where accuracy and liability matter.

The Hype Cycle Isn’t Strategic

O’Keefe warns that focusing internally on “how heavily we’re using AI” is a hype-driven metric, not a strategic one. Tech writers and content leaders should reframe the conversation:

• From “how much AI are we using?”

• To “how efficient and reliable is our content production process?”

• To “how good is the content we deliver for its intended use?”

This shift helps teams build accountability into their workflows instead of chasing novelty.

What This Means for Tech Writers

For tech writers specifically, here are the distilled takeaways:

1. AI should be a tool — not the goal: Use AI to handle repetitive, well-defined tasks, while keeping humans responsible for correctness and intent

2. Focus on quality over quantity: Audiences value clarity and accuracy more than volume

3. Maintain author accountability: Even when AI suggests or drafts content, the author still owns the final product’s correctness and accuracy, especially for technical and regulated content

4. Measure impact, not usage: Shift performance evaluation from AI adoption rates to content effectiveness and user outcomes

👉🏾 Read the article. 🤠

The Content Wrangler and Promptitude invite you to participate in our 2026 State of AI in Technical Documentation Survey, a five-minute multiple-choice survey that aims to collect data on where AI appears in documentation workflows, which tasks it supports, how often it is used, and the challenges that limit broader adoption.

We also seek to understand organizational support, tooling gaps, and where documentation professionals believe AI could deliver the most value in the future.

After the survey closes, we will analyze the results and publish a summary report highlighting the trends, patterns, and shared challenges across the industry. The goal is to provide documentation leaders and practitioners with credible data to guide decisions, advocate for better tools and training, and set realistic expectations for AI’s role in technical documentation.

Complete the survey and provide a valid email address to receive a copy of the final survey results report via email shortly after the survey closes.

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

It’s not too late! I hope you'll join me in Brussels at Hotel Le Plaza Brussels, February 2-3, 2026, for DITA EUROPE 2026 — the conference for technical writers and information developers looking to build advanced information management and delivery capabilities. If your technical documentation team produces content using the Darwin Information Typing Architecture (DITA) — or you’re considering doing so‚ this is the conference for you.

👉🏼 Grab your tickets now! Save 10% off the cost of registration using discount code — TCW — at checkout.

I’ll be delivering a talk with Dominik Wever, CEO of Promptitude — Powering AI and Virtual Humans with DITA Content — during which we’ll show how we built an AI-powered bot that delivers trustworthy, contextually accurate answers using technical documentation authored in DITA XML. Then, we’ll take it a step further—layering an interactive video agent (a virtual human) on top of the bot to create an engaging, human-like interface for delivering content.

Attendees will learn why structured content is essential for powering intelligent systems, how to responsibly connect DITA to AI models, and what opportunities virtual humans offer for technical communication. Whether you’re curious about future-ready documentation practices or looking for practical ways to extend the value of your content, this talk will offer both inspiration and concrete lessons.

DITA Europe is brought to you by the Center for Information Development Management (CIDM) — a membership organization that connects content professionals with one another to share insights on trends, best practices, and innovations in the industry.

CIDM offers networking opportunities, hosts conferences, leads roundtable discussions, and publishes newsletters to support continuous learning. CIDM is managed by Comtech Services, a consulting firm specializing in helping organizations design, create, and deliver user-focused information products using modern standards and technologies.

Day One: February 2, 2026

A large portion of Day 1 focuses on how AI actually behaves when it meets real-world documentation systems and legacy content — warts and all.

Key focus includes:

• AI benefits and failure modes in real-world use

• Aligning AI output with style guides and editorial standards

• Enhancing AI results through better context, tools, and editing workflows

• Deploying documentation directly to AI systems (not just to humans)

February 2 sessions emphasize that AI quality is constrained by content structure, governance, and determinability:

• AI in the Real-World: For Better and Worse — Lief Erickson

• Win Your Budget! — Nolwenn Kerzreho

• AI + DocOps = SmartDocs — Vaijayanti Nerkar

• DITA in Action: Strategies from Real-World Implementations — Maura Moran

• Determinability and Probability in the Content Creation Process — Torsten Machert

• From Binders to Breakthroughs: Cisco Tech Comms’ DITA Journey — Anton Mezentsev & Manny Set

• Enhancing AI Intelligence: Leveraging Tools for Contextual Editing — Radu Coravu

• From SMB’s to Enterprises: Real-World Content Strategy Journeys — Pieterjan Vandenweghe and Yves Barbion

• Aligning AI Content Generation with Your Styleguide — Alexandru Jitianu

• A Transition From One CCMS to Another – Lessons Learned — Eva Nauerth and Peter Shepton

• Cutting the Manual Labor: Scaling Localized Software Videos — Wouter Maagdenberg

• Revolutionizing Docs: DITA, Automation & AI in Action – Akanksha Gupta

• Future of Documentation Portals: From DevPortal to Context Management System — Kristof Van Tomme

• How AI is Boosting Established DITA Localization Practices — Dominique Trouche

• Trust Over Templates: Skills That Make A Content Transformation Work — Amandine Huchard

• Powering AI and Virtual Humans with DITA Content — Scott Abel

• DITA 2.0 + Specialization Implementation at ALSTOM — Thomas Roere

• Deploying Docs to AI — Patrick Bosek

• I’d Like Mayo With That: Our Special Sauce for DTDs — Kris Eberlein

Day Two: February 3, 2026

• Transforming Customer Support Through Intelligent Systems — Sharmila Das

• DITA and Enterprise AI — Joe Gollner

• Agentic AI: How Content Powers Process Automation — Fabrice Lacroix

• Why DITA in 2026: The AI Age of Documentation — Deepak Ruhil and Ravi Ramesh

• Content Automation 101: What to Automate and What Not To — Dipo Ajose-Coker

• Empowering DITA with Standards for AI in Safety-Critical Areas — Martina Schmidt and Harald Stadlbauer

• Taxonomy For Good: Revisiting Oz With Taxonomy-Driven Documentation — Eliot Kimber and Scott Hudson

• Upgrading the DITA Specification: A Case Study in Adopting 2.0 — Robert Anderson

• Hey DITA, Talk To Me! How iiRDS Graphs Infer Answers — Mark Schubert

• The Secret Life of Technical Writers: Struggles, Sins, and Strategies — Justyna Hietala

• Better Information Retrieval in Bringing DITA, SKOS, iiRDS Together — Harald Stadlbauer, Eliot Kimber, Mark Schubert

• If They Don’t Understand, They Can’t Act: Comprehension in DITA — Jonatan Lundin

• DITA, iiRDS, and AI Team Up for Smart Content Delivery — Marion Knebel, Gaspard Bébié-Valérian

• Pretty As a Screenshot: Agile Docs Powered by QA Tools — Eloise Fromager

• Bridging the Gap – Connect DITA, Multimodal Data via iiRDS — Helmut Nagy, Harald Stadlbauer

• Guardrails for the Future: AI Governance and Intelligent Information Delivery — Amit Siddhartha

• Highly Configurable Content using DITA, Knowledge Graphs and CPQ-Tool — Karsten Schrempp

• Building a Content Transmogrifier: Turning Reviews into Something Better — Scott Hudson, Eliot Kimber

👉🏼 Grab your tickets now! Save 10% off the cost of registration using discount code — TCW — at checkout.

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Search used to be about matching keywords. Today, AI-powered search engines promise to “understand what users mean.” In practice, they struggle with something far more basic: intent.

Intent is the goal behind a search query—the job the user is trying to get done at that moment. Are they trying to learn, do, fix, compare, or verify? Intent answers why the question was asked, not just what words were typed.

For technical content, intent matters more than phrasing. A query like “configure OAuth token refresh” can signal at least four different needs:

• a conceptual explanation,

• a step-by-step task,

• a troubleshooting scenario,

• or a confirmation that a system even supports the feature.

The words don’t change. The intent does.

Why AI Search Engines Struggle With Intent

AI search systems are trained on language patterns, not user goals. That creates several hard problems:

• Queries are underspecified
  Users compress complex situations into a few words (often not even in a sentence). AI must infer missing context we fail to provide.

• Intent evolves across the customer journey
  The same query appears during learning, implementation, and troubleshooting phases of the journey.

• Unstructured content hides purpose
  When documentation mixes concepts, tasks, and reference material together, AI has no reliable signal to determine which kind of answer fits the situation.

When intent is unclear, AI systems fall back on probability. That’s when you get answers that sound right, rank well, and still fail the user.

Intent is the reason behind a search query. It answers the question: What is the person actually trying to accomplish right now?

• Are they trying to learn a concept, complete a task, fix a problem, compare options, or confirm a decision they’ve already made?

The challenge is that intent rarely appears explicitly in the query.

A search like “reset authentication token” could mean:

• “I need step-by-step instructions right now.”

• “I want to understand how token-based authentication works.”

• “I’m evaluating whether this system supports token rotation.”

• “I already tried something and it failed—what did I miss?”

The words stay the same. The intent changes completely.

Why AI Has Trouble Inferring Intent

Large language models are good at generating plausible answers, but intent inference is not a text-generation problem. It’s a context problem.

AI search systems struggle because:

1. Queries are compressed signals
   Users type the shortest thing that might work, not a full explanation of their situation. AI must guess what’s missing.

2. Intent shifts mid-journey
   A user may start by learning, then move to doing, then to troubleshooting (all with nearly identical queries).

3. Training data reflects language, not goals
   LLMs learn patterns of words, not the underlying job the user is trying to get done.
   
   👉🏾 Related: MIT researchers find a shortcoming that makes LLMs less reliable

4. Documentation rarely exposes intent explicitly
   Most docs are organized by product structure, not by user intent, task maturity, or decision state.

When intent is unclear, AI fills the gap with probability. That’s where hallucinations, irrelevant answers, and dangerously confident responses come from.

What Breaks When You Don’t Use DITA (or Structured Content)

When documentation is unstructured or loosely structured, humans compensate. AI systems cannot. The gaps show up quickly (and painfully) once your content feeds an AI-powered search or answer engine.

Intent Collapses

Without information typing, AI cannot reliably tell whether a paragraph exists to explain, instruct, or troubleshoot. Concepts bleed into procedures. Reference data sneaks into narrative text. The system returns answers that mix what something is with how to do it, often in the wrong order and at the wrong time.

Result: users get answers that feel close but don’t help them act.

Context Gets Lost at the Fragment Level

AI systems rarely deliver full pages. They extract fragments.

In unstructured docs, those fragments depend on surrounding prose to make sense. Once separated, steps lose prerequisites, warnings lose scope, and examples lose relevance. AI fills in the gaps with probability, not certainty.

Result: confident answers with missing or incorrect constraints.

Troubleshooting Becomes Guesswork

When troubleshooting guidance is embedded inside tasks or buried in narrative text, AI cannot reliably identify it as recovery-oriented content. It may return setup instructions when the user is already in failure mode—or worse, repeat the action that caused the problem.

Result: frustration, repeated errors, and support escalations.

👉🏾 See also: Why Technical Writers Need to Understand Context Engineering

Audience and Experience Level Are Invisible

Unstructured content rarely signals who something is for. AI cannot distinguish beginner guidance from expert shortcuts or administrative tasks from end-user actions.

Result: novice users get overwhelmed; experts get slowed down.

AI Compensates by Hallucinating

When intent, purpose, and constraints are not explicit, AI does what it was trained to do: produce something that sounds plausible.

This is not an AI flaw. It’s a content design failure!

Why DITA Prevents These Failures

DITA doesn’t eliminate ambiguity; but it sharply reduces it by design.

• Information typing makes purpose explicit

• Structured components preserve meaning when content is reused or extracted

• Metadata exposes audience, environment, and conditions

• Modular topics give AI clean, intent-aligned units to reason over

When intent is encoded in structure, AI doesn’t have to guess. It can select.

What This Means for Tech Writers

AI search systems can only infer intent if the content makes intent visible.

That’s why structured, semantically rich documentation matters. When content clearly distinguishes:

• conceptual explanations from procedures,

• reference material from troubleshooting,

• beginner guidance from expert shortcuts,

you give AI something concrete to reason over instead of something vague to guess at.

Well-structured documentation does not just help humans scan faster. It helps machines choose the right answer for the right situation.

And in an AI-driven search world, choosing the right answer matters more than ranking first. 🤠

The Darwin Information Typing Architecture (DITA) is an XML-based standard for creating, managing, and publishing technical documentation as modular, reusable content. OASIS maintains the DITA standard and provides access to information about its usage.

DITA matters because it forces clarity and discipline at the point of creation. Each topic has a single intent — concept, task, or reference — which makes content easier for people to scan and easier for machines to process. That structure enables reliable reuse, reduces duplication, and improves consistency across products, versions, and channels. Writers stop rewriting the same explanation five times and start managing one trusted source of truth.

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

DITA is also built for scale and change. Its specialization and inheritance model lets organizations extend the standard without breaking it, while maps assemble topics into many deliverables from the same content set. The result is faster updates, cleaner localization workflows, and publishing pipelines that can target PDFs, HTML, portals, and help systems from the same content base.

Finally, DITA future-proofs documentation for AI-driven delivery. Because topics are semantically typed and structurally consistent, search engines, chat systems, and retrieval-augmented generation pipelines can identify intent and return precise answers instead of dumping entire pages. In an era where documentation feeds intelligent systems, DITA gives technical writers a way to make content both human-readable and machine-ready.

DITA content is best managed in a component content management system designed specifically to help technical writers create, manage, and deliver documentation to the humans and machines that require it. 🤠

If you work with the Darwin Information Typing Architecture (DITA) — or plan to in the future — you likely to hear the word topic constantly. It sounds obvious; until you try to explain it to someone outside the DITA world, or worse, to someone who thinks a topic is just “a page” or “a section.” It isn’t.

A DITA topic is a small, self-contained unit of information designed to answer one specific user need. Not a chapter. Not a document. Not a dumping ground for everything related to a feature. One purpose. One job.

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

A DITA topic has three defining characteristics

1. It has clear intent

Every DITA topic exists to do exactly one thing: explain a concept, describe a task, or provide reference information. This is not an accident. DITA enforces intent through information typing—most commonly concept, task, and reference.

Related: Understanding DITA Topic Structure

That constraint forces writers to decide why the content exists before writing it. Is the user trying to understand something? Do something? Look something up?

📌 If you cannot answer that question, you do not yet have a topic.

This is one of the reasons DITA content works so well with search, delivery platforms, and AI systems. Intent is explicit, not implied.

2. It Stands on Its Own

A DITA topic is designed to be meaningful outside the context of a book or manual. Someone might encounter it through search, a chatbot, an embedded help panel, or an AI answer engine. Regardless of how they encounter it the topic must still make sense.

That means no “as described above,” no unexplained acronyms, and no reliance on surrounding pages or section headers to fill in critical gaps. Context travels with the topic through metadata, structure, and reuse — not through proximity.

This independence is what enables reuse at scale without copy-and-paste chaos.

3. It’s Structurally Predictable

A DITA topic follows a consistent structural pattern: a title, a body, and clearly defined elements inside. Tasks have steps. References have tables and properties. Concepts explain ideas, not procedures.

That predictability is not just for writers; it is for machines (computers, specifically). Structured topics allow systems to classify, filter, assemble, personalize, and deliver content dynamically. This is why DITA topics are increasingly valuable in AI-driven environments.

Large language models do not “understand” documents. They perform far better with small, well-typed, semantically clear units of information.

Why This Matters Now

As search engines turn into answer engines and documentation gets consumed in fragments, the DITA topic becomes the atomic unit of knowledge delivery. Writers who understand how to design strong topics are not just explaining products; they are engineering intent-aware, machine-processable content that feeds knowledge systems.

If you want AI solutions to give users the right answer instead of a plausible one, start with better topics.

If your content:

• clearly states its purpose,

• uses consistent information types,

• exposes relationships through structure and metadata,

AI can reason over it. If it doesn’t, AI guesses.

Structured, semantically augmented DITA content allows AI systems to:

• distinguish learning intent from execution intent,

• select the right topic type for the moment,

• avoid blending procedural steps into conceptual explanations,

• reduce hallucination caused by context collapse.

In short, it helps AI choose instead of invent.

What This Means For Tech Writing

Technical writers are no longer just explaining products. They are designing intent-aware knowledge systems.

Every time you:

• choose a topic type,

• enforce information typing discipline,

• add meaningful metadata,

• break monolithic docs into purpose-driven components,

you make it easier for AI search engines to deliver the right answer, not just an answer.

In an AI search world, visibility depends less on keywords and more on whether machines can understand what your content is for.

DITA doesn’t just support that future. It anticipates it. 🤠

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Technical writers live in a strange middle ground. We translate what systems produce into something people can understand and use. Lately, that middle ground has gotten more crowded. Data teams, AI teams, and platform teams increasingly want documentation to behave like data—structured, atomized, and machine-friendly.

The assumption is that machines thrive on raw inputs and that humans can be served later by whatever the system generates.

That assumption is wrong!

The uncomfortable truth is this: data without context doesn’t just fail people—it fails machines too. The failure simply shows up later, downstream, disguised as “AI output.”

Most documentation problems trace back to a quiet but persistent confusion between four related — but very different — concepts: data, content, information, and knowledge.

They are often used interchangeably in meetings and strategy decks, as if they were synonyms. They are not.

Each represents a different stage in the creation, interpretation, and application of meaning. When those distinctions blur, teams ship docs that look complete but fail in practice (leaving both users and AI systems to guess at what was never clearly expressed).

A simple example, repurposed from Rahel Anne Bailie’s self-paced workshop for the Conversational Design Institute, Mastering Content Structure for LLMs, makes this painfully clear.

A Data Example

Imagine encountering the number 242.

On its own, it is nothing more than a value. Humans can’t reliably interpret it, and neither can an AI system. It could be a temperature, an identifier, a page number, or something else entirely. There is no intent encoded in it. No audience implied. No action suggested. It is easy to store and transmit, but useless for understanding.

This is the first misconception worth correcting: raw data is not inherently meaningful to machines. Large language models do not reason over naked values. Without context, they guess. And guessing is not intelligence.

Now add a little structure. Write it as +1 242.

Suddenly, recognition kicks in. A human reader may suspect it relates to a phone number. A machine may successfully classify it as a telephone-number pattern. That is progress—but only a little. Recognition is not understanding. Neither the person nor the system yet knows what to do with it.

This is where many organizations stop and declare victory. They call it “content,” ship it, and expect AI to take it from there.

But the real transformation happens when context deepens.

When you explain that the Bahamas participates in the North American Numbering Plan (NANP), that “+” indicates international dialing notation, that “1” is the shared NANP calling code, and that “242” is the area code assigned to the Bahamas, something important changes. The number is no longer just recognizable—it becomes usable.

Different readers understand different things. Someone calling from Europe understands they must use the international dialing format. Someone in the United States understands they dial 1 242 plus the local number. Someone inside the Bahamas understands they do not need to dial the country or area code at all.

A system, given this same context, can now generate accurate, audience-appropriate guidance instead of generic advice.

This is information. And it is the minimum viable input for both humans and AI systems to behave intelligently.

Here is where tech writers need to push back (firmly) on a common refrain: “We’ll just treat the docs as data.”

Data professionals are not villains here. They are optimizing for scale, governance, and automation. From their perspective, the content looks unruly. It resists schemas. It contains nuance. It varies by audience. So the impulse is to strip it down, atomize it, vectorize it, and let models infer meaning later.

But meaning is not something you can recover after you’ve removed it.

When content is reduced to data, intent evaporates. Audience awareness disappears. Relationships between ideas collapse. What remains is technically processable but contextually hollow.

AI systems trained or prompted on that material do not become smarter. They become confidently wrong, broadly vague, or situationally tone-deaf.

This is not an AI problem. It is a content-structure problem.

Tech writers are often told they “add words.” In reality, they add constraints, distinctions, and context—the very things both people and machines require to make correct decisions. When that context is missing, humans struggle, and machines hallucinate. The root cause is the same.

The job, then, is not to turn content into data. It is to design content so that it can be understood computationally without being stripped of meaning. That means preserving relationships, encoding intent, and making audience differences explicit.

👉🏾 Metadata can help, but it cannot replace explanation.

👉🏾 Structure can support meaning, but it cannot invent it.

Data serves systems. Content serves humans.

Information is the bridge that allows machines to help instead of harm. Knowledge (the conclusions people draw) will always remain partly subjective. Your role is not to dictate knowledge, but to make it possible.

So the next time someone says, “The model will figure it out,” ask a quieter, more dangerous question: Figure out what, exactly, and from which context?

If the answer is vague, the system is not simplifying anything. It is exporting confusion—first to the machine, and eventually to the person relying on it.

That is precisely what good technical writing exists to prevent. 🤠

By Mark Wentowski

Content pros are encountering new challenges in the Large Language Model (LLM) and agent era, highlighting the need for a different approach to authoring tools. Trust in LLM-generated content is the next hurdle, and transparency about the LLM’s information sources is needed.

Underscoring this, LLMs’ answers are only as good as the source content, which, in most cases, will be proprietary and will not be part of an LLM’s general intelligence about non-proprietary sources like blog posts. So the LLM needs to be an expert on your product, and someone needs to author this content, either with or without AI assistance.

The Current Paradigm

Right now, most authoring is aimed at publishing content for people. While chatbots can use this information to answer questions, the content isn’t designed with agents in mind. Humans remain an important audience, but we also need source content that works well for both LLMs and people. Similar to how web design shifted to a “mobile-first” approach, we could move to an “agent-first” design for documentation. This doesn’t mean humans are less important; it just means that focusing on agents is more challenging but will still meet human needs.

Related: AI-Powered Authoring: Will Machines Replace Technical Writers?

The Shifting Role of Authors

Authors should always retain the freedom to “just type something” in an editor, but moving forward, a bit more discipline will be required. As LLMs and agents become more adept at generating content (especially when supplied with verifiable facts) the role of the human author is evolving. Their primary responsibility will shift toward establishing a foundation for content verification. This includes building taxonomies, which might be generated automatically from source material and then refined by the author, or created manually for maximum control by a discerning analyst. Additionally, authors will help map product concepts to ontologies to enable deeper and more meaningful interconnections.

Taxonomies: How to Find Things

A taxonomy organizes items into categories within a clear hierarchical structure, much like a tree with branches and sub-branches. Each item is assigned to a category, making it easier to find by moving from broad groupings to more specific ones. These relationships typically take the form of parent-child or sibling connections.

We see taxonomies every day—for example, website navigation menus that let us drill down from broad categories to more specific items.

Why do taxonomies matter?

According to Earley Information Science:

Related: What Is the Difference between Taxonomy and Ontology?

Consider a grocery store: its organization is a practical example of a taxonomy in action. Products are grouped into clear categories:

• Produce → Fruits → apples and bananas

• Dairy → milk and yogurt

• Meat → Chicken and beef

• Bakery → Bread and cookies

This system shows you exactly where to find items. It’s hierarchical and structured, so you won’t find yogurt in the cereal aisle. The main benefit is efficient organization and quick retrieval.

If the grocery store had a website, its taxonomy would guide how you browse and filter products online. The site’s navigation and structure often match the store’s taxonomy, helping users find what they need.

For writers, setting up a taxonomy gives a clear framework for structuring content, building page hierarchies, and making internal tables of contents. Rather than starting from scratch, a good taxonomy gives you an organized starting point for creating content.

Limitations of Taxonomies

Taxonomies are great for organizing information, but they have some limits. Their structure is strictly hierarchical, grouping items as parent, child, or sibling within one domain. This makes it hard to show more complex connections, such as links between items in different taxonomies or across domains.

Taxonomies define categories within a single domain. In this case, the product domain. A taxonomy can’t connect to other domains on its own. That’s a job for an ontology. —> Source: Earley Information Science

Another issue is that taxonomy categories often serve as simple organizational “tags,” rather than formal classes. Because of this, taxonomies can label and sort items, but they don’t capture the richer, more detailed relationships that ontologies or class-based systems can show.

Related: Categories Or Tagging? Differences In Taxonomy And Information Architecture

Ontologies: Going Beyond Hierarchies

Ontologies do more than taxonomies by capturing complex, meaningful relationships between entities, not just simple hierarchies.

In an ontology, you define classes (abstract types) and individuals (instances), which lets you map how things connect, even across different taxonomies or domains. Unlike taxonomy categories, ontology classes help you make logical inferences about relationships and properties.

Related: LLM Reasoning vs. Logical Ontology Graph Reasoning: A Comparative Analysis

Let’s take the grocery store example further. A pastry chef making desserts for guests with allergies and dietary needs must not only identify ingredients (taxonomy) but also understand relationships, such as which ingredients can be swapped or which combinations meet certain requirements (ontology).

For example:

• Tapioca flour is gluten-free and creates crisp shells

• Agar-agar replaces gelatin for setting

• Yuzu pairs with vanilla and reduces sugar

• Meringue adds crunch but requires eggs (an allergy risk)

• Oat crumble adds texture but may contain cross-contamination

• Maltitol is a sugar substitute, but it can affect digestion

These relationships are about function and context, not hierarchy.

Ontologies help the chef answer questions like:

• What ingredients can substitute for others?

• Which combinations satisfy dietary constraints?

• What must be avoided together?

• What achieves the desired result?

In short, ontologies add meaning and context, giving you different ways to understand or use the same item. You can use ontologies to connect your internal concepts with external standards and trusted resources.

This mapping is especially useful for setting up sources of truth and for verification. For example, linking your product ontology to an industry standard such as Financial Industry Business Ontology (FIBO) lets agents verify your content against trusted sources.

Agents can also use well-established external documentation or published books as extra references. Importantly, people still play a key role: agents can suggest changes, but content professionals make the final decisions.

In API documentation, ontologies can turn resources into canonical entities and link them to external standards, enriching documentation and ensuring verifiability.

Taxonomy vs. Ontology

Let’s review the difference between a taxonomy and an ontology.

Structuring Content for the Agent Era

Once taxonomies and ontologies are in place, the authoring process can go beyond separate markdown files and freeform text. Now, content should be organized into independent, self-contained knowledge chunks, each with its own metadata and structured data. This way, information is both easy for people to read and for machines to use, supporting agents and automation.

Related: Understanding When to Use Structured Content Authoring

A key idea from “linked data” is that structured data and prose should match for every knowledge chunk. This makes content easier to verify and find, and helps meet standards like those Google uses for web content. While this was hard before, having taxonomies and ontologies makes it much easier.

Modern authoring tools should make it seamless to express new relationships between concepts, eliminating the need for manual markup. By enabling authors and agents to consistently contribute prose, the system can automatically generate corresponding structured data, freeing users from additional tagging.

This knowledge-chunk model also improves tracking and maintenance. Each chunk can be updated, reviewed, and audited individually, making it easier to monitor content freshness and accuracy.

It’s important to balance structure with a good authoring experience. Tools that are too rigid can limit creativity, while unstructured methods don’t offer the control and verification agents need. By using standards like schema.org, the tool can automatically generate structured data for each chunk, link it to the appropriate entities, and eliminate the need for manual schema markup.

The Bleeding Edge: Executable Content

This brings a big change: content becomes executable. Structured data lets scripts or agents take actions, such as making API calls or testing UI workflows, directly from the documentation. Now, content is both actionable for machines and easy for people to read, closing the gap between automation and usability.

Testing also improves. Instead of writing separate test cases, the structured data in the content defines the process, the required entities, and the steps to follow. This reduces duplication and keeps documentation and verification in sync.

For content that isn’t executable, taxonomies and ontologies help verify it through categories and relationships. This keeps the knowledge base accurate and consistent. It’s important to keep entities stable; once they’re defined, they anchor the content and help keep it reliable.

Charting a Path Forward

As the LLM and agent era changes how we create and use information, content professionals face new challenges and opportunities. Shifting from static, human-focused documentation to dynamic, agent-ready knowledge means rethinking our tools, processes, and mindset. By using taxonomies, ontologies, and structured knowledge chunks, we improve verifiability and discoverability, and set the stage for content that is both executable and adaptable.

This change isn’t about replacing human creativity with automation. It’s about boosting our ability to curate, verify, and connect information for both people and smart systems. The road ahead will need ongoing testing, teamwork, and improvement. By adopting these ideas now, we can keep our content trustworthy, relevant, and ready for the future.

About Mark Wentowski

Mark Wentowski is an API documentation specialist and senior technical writer with more than twelve years of experience helping SaaS companies and global development teams explain complex software to technical audiences. He focuses on developer-to-developer content for web services, APIs, libraries, and data-driven products, producing conceptual guides, configuration and deployment instructions, tutorials, references, walkthroughs, sample apps, and best-practice documentation.

His work spans the full documentation lifecycle—from research, content creation, and editorial review to publication, hosting, and long-term maintenance. Mark brings deep expertise in modern documentation tooling and implementation, including Redocly, ReadMe, Document360, Stoplight, and Gatsby JS, along with strong proficiency in Docs-as-Code workflows, Git-based collaboration, static site generators, and Markdown/HTML migrations.

He applies a modern, user-centered approach grounded in usability testing, automation, DevOps thinking, and scalable content architecture. Mark also creates diagrams, videos, and GIFs that reinforce technical concepts and improve the developer experience.

If you’re a technical writer who has been told to “start using AI,” there’s a good chance this instruction arrived the same way most bad ideas do: casually, optimistically, and with absolutely no adjustment to your workload.

You were already juggling three releases, a backlog of outdated content, an SME who responds exclusively in emojis, and a publishing system held together by hope and duct tape. Now you’re also supposed to “use AI” — presumably in the five spare minutes between standup and your next fire drill.

When AI fails to deliver miracles under these conditions, leadership often concludes that AI is overrated. This is unfair to you, and frankly, unfair to the robot.

AI Isn’t a Magic Button — It’s a Process Multiplier

AI does not save time by default. It reallocates time.

To use AI responsibly in technical documentation work, you need time to:

• Experiment with real content, not toy examples

• Learn which tasks benefit from AI and which ones absolutely do not

• Validate output, because “confidently wrong” is still wrong

• Adjust workflows, prompts, review steps, and quality checks

If none of that time exists, AI use collapses into exactly one activity: drafting text faster.

Drafting is fine. Drafting is useful. Drafting alone is not transformation.

What Actually Happens Under Time Pressure

When documentation teams operate under constant time pressure, AI adoption tends to play out in a very predictable way. Writers reach for AI to generate first drafts because it offers the quickest visible win and creates the feeling of progress. The problem is that speed at the front of the process often pushes effort to the back.

Review cycles grow longer as someone has to verify facts, check tone, and untangle confident-sounding mistakes. Quality concerns begin to surface, not because AI is inherently flawed, but because it is being asked to compensate for a lack of time, structure, and planning.

As these issues accumulate, trust in the tool starts to erode. Conversations quietly shift from “How can we use this better?” to “This is risky,” and then to “Let’s limit where this can be used.”

Almost no one pauses to ask the more uncomfortable question: whether the real problem is that writers were expected to redesign workflows, adopt new practices, and safeguard quality without being given the time to do any of that work properly.

Instead, AI becomes the convenient scapegoat. Workloads stay the same, pressure remains high, and the system continues exactly as it did before—just with one more abandoned initiative added to the pile.

Why This Isn’t a Personal Failure

If you feel like you “don’t have time for AI,” that does not mean you are behind, resistant, or doing it wrong. It means your organization has not yet made room for change.

AI adoption requires slack in the system. Not endless slack. Just enough breathing room to think, test, and improve without breaking production.

Without that space, AI becomes another demand layered onto an already impossible job. And no technology (no matter how hyped) can fix that.

The Real Conversation We Need to Be Having

The question is not, “Why aren’t writers using AI more?”

The question is, “What work could we stop doing, simplify, or delay so writers can safely integrate AI into how documentation actually gets produced?”

Until that question is answered, AI will remain a side experiment — interesting, occasionally helpful, and permanently underpowered.

And the robot will continue to be blamed for a problem it did not create.

During the 2025 The LavaCon Content Strategy Conference the folks at Heretto gave away some cool merch (hats, t-shirts, and sweatshirts ). I’m pictured here with the “content” t-shirt 👕 — but in retrospect, I should have grabbed a sweatshirt —> because ❄️winter🥶 is here!

Now it’s your chance to score a “content” sweatshirt

Here’s how: Complete the Heretto Structured Content Survey (2 minutes max) and you’ll qualify to be entered into the drawing.

Complete the survey before December 31, 2025 to qualify. Winners to be contacted in January 2026.

Complete the Survey

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Organizations everywhere are rethinking how they deliver customer support, and the smartest teams are turning to AI, structured content, and stronger cross-functional collaboration to do it. Earlier this year, Heretto released the State of Customer Self-Service Report, a data-rich look at how leading companies are transforming self-service into a strategic advantage. If you haven’t downloaded it yet, now is the time:

This report doesn’t just highlight trends. It reveals what top performers actually do to create self-service experiences that reduce effort, deflect tickets, and give customers the answers they need the moment they need them.

Download the State of Customer Self-Service Report now and see exactly where your organization excels, where your gaps are, and what steps you can take to improve.

Inside The State of Customer Self-Service Report

You’ll learn how organizations are using:

• AI to power smarter, more personalized support. The report explores how teams are adopting AI responsibly, pairing machine intelligence with strong content foundations to improve relevance and accuracy across the customer journey.

• Structured content to move beyond scattered, inconsistent knowledge bases. High performers are investing in reusable, well-governed content that scales across channels and markets — and makes AI far more reliable.

• Cross-functional collaboration to break down silos between product, support, documentation, and marketing. Teams that treat content as shared infrastructure, rather than as a departmental afterthought, deliver better self-service outcomes and faster ROI.

Why This Matters

Self-service is now the first stop for a growing majority of customers. That shift raises expectations for clarity, findability, consistency, and personalization. What you’ll see in the report is that organizations who meet those expectations aren’t relying on guesswork; they’re aligning strategy, structure, and technology to deliver high-quality content at scale.

The report also explores the barriers teams run into: limited staffing, siloed tooling, unclear ownership, and inconsistent processes. More importantly, it outlines how leaders overcome those challenges and build momentum.

Next Step: Benchmark Your Content Against Industry Realities

If your organization delivers customer-facing content (technical docs, support articles, onboarding flows, or product guidance) you should download this report and see how your strategy compares to the findings.

Use it as a benchmark. Use it as a wake-up call. Use it as the evidence you need to advocate for smarter, more scalable content operations.

The insights are available now. Your competitors may already be acting on them. Don’t wait!

Download the State of Customer Self-Service Report now and see exactly where your organization excels, where your gaps are, and what steps you can take to improve. 🤠

The Content Wrangler is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.