AI Doesn't Read Your Documentation — It Builds A Mental Model Of Your Product

Information architecture isn't becoming more important because AI arrived. AI just wandered into a conversation we technical writers have been having for decades.

We choose terminology, define content relationships, create navigation, build taxonomies, declare and apply metadata, and decide where information belongs. Those decisions help people make sense of complex software products.

Reading Andrea Volpini’s recent article about the Perception Graph made me look at our work from a different angle.

What Is A Perception Graph?

According to Volpini, a Perception Graph is the internal model AI builds about a product, organization, or topic after analyzing information from many sources. Instead of remembering documents page-by-page, AI systems develop an understanding of how products, features, tasks, roles, and terminology all fit together. When someone asks a question, it answers from that model rather than from content available in a specific document.

If you’ve ever wondered why AI can explain how several features work together without quoting a specific page, this is one reason.

What Is A Signal Graph?

A Signal Graph is the collection of evidence AI uses to build that model.

Product documentation is part of this graph, but so are product pages, API references, release notes, advertisements, support articles, blog posts, videos, structured data, software review sites, analyst reports, customer reviews, community discussions, white papers, and news coverage. Some sources deserve more trust than others, but all of them contribute signals to the mix that AI utilizes to conjure up responses.

Why Should Tech Writers Care?

While our documentation may be the most authoritative description of our product, it isn’t the only one AI encounters.

Imagine the same capability described as Projects in one of our user guides, Workspaces in a release note, and Teams somewhere else on the web. While human customers usually can work their way out of such content hairballs, AI has to decide whether those various names describe one feature, three different features, or documentation that disagrees with itself.

The same thing happens when our marketing team introduces a new product name before the documentation changes, when release notes describe a workflow differently than the user guide does, or when outdated topics remain online long after the software changed.

Every one of those examples becomes another signal AI uses to generate responses.

What Makes Documentation AI-Ready?

The exact same qualities that help people understand a product also help AI do the same.

👉🏾 Consistent terminology reduces ambiguity
👉🏾 Clear relationships between concepts help AI connect information correctly
👉🏾 Accurate metadata adds context
👉🏾 Well-structured content makes it easier to recognize how ideas fit together

None of those practices were invented for AI. We’ve relied on them for years because they improve understanding.

Why Information Architecture Still Matters

For years, we’ve described information architecture as the discipline that helps people locate the information they need. Finding information, however, is only the first step. Information is only useful when people understand it.

Customers build mental models of our products as they read our docs Those models help them predict what a product will do, recognize patterns, and solve problems they haven’t encountered before.

AI is doing something similar.

That’s what stayed with me after reading Volpini’s article. His terminology is new to me. The underlying idea isn’t.

Tech writers have been helping people build accurate mental models of products for a long time. AI depends on many of the same information design decisions. 🤠