The garage is what I kept looking at. The opening at street level seemed to drop back farther than a single level of parking should allow. I sat there wondering whether I was looking at two stacked levels underneath the house. I don’t know enough about the city’s building limits to say whether that’s even possible. After thinking about it, I decided I was probably looking at a vertical car-stacking lift, a system that lets one garage opening hold twice the cars it appears to hold. Noe Valley has enough wealth concentrated in three-story Edwardians that this kind of luxury home improvement isn’t much of a stretch.

I’d been in a meeting in Silicon Valley earlier that morning about content operations for a tech writing team. The longer I watched, the more my brain started making connections between what I was seeing and what we’d discussed earlier — that’s just how my crazy brain works, jumping between unrelated things until sometimes, if I’m lucky, something clicks.

As I watched the improvements being made to prepare the house to withstand an earthquake it struck me that using this metaphor might be a useful way to help organizations understand why they need to think about retrofitting their content for AI.

Read more

Deterministic system (noun)

A system whose rules produce the same output whenever it receives the same inputs under the same operating conditions.

About Deterministic Systems

Deterministic systems follow rules that determine what happens. Start with the same state, feed in the same inputs, and the system applies the same rules, resulting in the same result every time.

A calculator is the simplest example.

Enter 10 × 5 and you get 50, every time.

Software permissions work the same way. If access depends on a user's role, subscription level, and security settings, the system reaches the same decision whenever those values match.

Same inputs covers more than what our users type in. It includes things like account settings, stored data, software version, current time, feature flags, and information pulled from connected services. Change any one of those inputs, and our result can change too.

What Makes A System Deterministic?

Subscribe now

Read more

A few cycles in, something strange happened. Long before an IV line was prepped, the beeping of a medical device — or something else — reminded me of my experiences in the cancer ward. That reminder would immediately trigger acute anxiety.

I hadn’t had any chemo administered, and yet, I was already feeling as if I had. My oncologist had a name for it: anticipatory response. My brain had associated specific sounds, smells, and situations with treatment. Those anticipatory cues were enough to trigger the response before any treatment began.

Years later, watching technical documentation teams adapt to generative AI and automated answer engines, I keep coming back to that experience. It made me more interested in what readers learn to expect from documentation before they have processed much of the page.

The Brain As An Expectation Engine

The human brain is an organ that continually monitors signals that are associated with prior experience to anticipate threats. That’s the pattern I noticed in the hospital, and it gave me a useful way to think about what readers of our documentation bring with them on their journey to find answers to their product use questions.

Subscribe now

Read more

Researchers at Ericsson were testing retrieval-augmented generation (RAG) against technical documents. One of their discoveries was that keywords appearing closer to the beginning of a sentence were retrieved by AI tools with high accuracy. Keywords appearing later in sentences were harder for AI to retrieve accurately.

Before The Model Answers Anything

The paper, Observations on Building RAG Systems for Technical Documents (PDF download at end of article), was written by Sumit Soman and Sujoy Roychowdhury. The researchers tested technical info from IEEE wireless networking specifications and a battery terminology glossary — reference documents, not how-to step-by-step instructions. They examined factors including chunk length, retrieval method, definitions, and keyword position.

Their keyword-position findings:

1. Keywords closer to the beginning of a sentence are retrieved with high accuracy.

2. Keywords appearing later in a sentence were more difficult to retrieve.

Subscribe now

Read more

Chances are good you’ve seen this behavior before. And, if you’re like me, you might not know why.

Where Web Previews Come From

The visualization that platforms like Slack, Facebook, and BlueSky generate when you paste a hyperlink is supposed to contain the same info humans see when they visit the page the link points to. Looking into why that doesn’t always occur led me to a separate layer of metadata in a page’s <head>, and to a specification called the Open Graph protocol.

Introduced by Facebook in 2010, Open Graph provides a universal format for web publishers to control precisely how their URLs and website content are displayed when shared across social networks and messaging platforms. It gives web publishers a way to specify a title, description, image, and other info that platforms can use to determine what content will display in a link preview.

What Was Broken

In the Slack example, the image was the first thing I noticed missing. No event photo appeared in the card, the way it did on the web page I visited. The copy didn’t discuss the conference. Instead, it showed a description of the event production company.

The headline was accurate. It displayed the conference name and dates, but the rest of the content was a mismatch.

One Possible Explanation

The site’s template may explain it. When page-level Open Graph values aren’t supplied, a web page preview may fall back to the site-wide default, producing generic copy about the organization that owns the site, instead of anything specific to the event they were promoting.

An Assumption That Needs Some Scrutiny

Increasingly, web-based documentation includes a share button to help users easily distribute our content to others. When someone clicks the share button they likely assume the shared link will display the content correctly wherever it lands.

But, that assumption doesn’t always hold true.

Tech writers typically check published output in the channels we control.

• A PDF user manual gets reviewed as a PDF file.

• Our help site gets checked for the experience users will have when they access that information using a web browser.

Shared link previews, on the other hand, are seldom discussed in tech comm circles and aren’t commonly included in pre-deployment review. That needs to change because they impact the customer experience. Link previews deserve scrutiny and to become part of our publication workflow quality control process.

The “Big Three” Tags For Writers

While there are dozens of Open Graph tags covering everything from video durations (video:duration) to property types (og:type), tech writers need to pay attention to three fundamental properties.

Here is what they look like in the markup, and how to approach writing them.

1. The Title (og:title)

This is HTML markup that controls the bold headline of your preview card.

While it is tempting to just map this directly to your <title> or <h1> tag, your og:title should be optimized for standalone context. A page in your doc portal site might be titled “OAuth Tokens” because it lives under an “Authentication” breadcrumb. But stripped of that breadcrumb in a Slack channel, “OAuth Tokens” is vague. Your og:title should be descriptive and independent.

2. The Description (og:description)

This is the one-to-two sentence summary that appears below the title.

Unlike a traditional SEO meta description (which is written to for search engine algorithms), an og:description is a direct pitch to a human being in a chat window. Keep it punchy and action-oriented. Aim for under 100 characters to ensure it doesn’t get truncated on mobile devices or smaller chat windows. Do not just let your site generator pull the first paragraph of your page—that often results in awkwardly cut-off sentences or code snippets being displayed as text.

3. The Image (og:image)

This points to the image file that will serve as the banner for your preview card.

This approach requires a bit of collaboration with your design or frontend web team, but the content strategy belongs to you. Don’t settle for a generic company logo image across all 5,000 pages of your documentation. Advocate for a dynamic image generation system, or create standard, topic-specific banners (e.g., a specific banner for “Tutorials,” another for “Reference,” and another for “Release Notes”).

Testing Your Link Preview Metadata

We don’t have to wait until a page is pushed to see how our Open Graph tags perform. Once our markup is staged, we can use one of several free validators to preview how our content will look:

• opengraph.xyz: A great all-in-one tool that shows how our link will render across Slack, Discord, LinkedIn, and Facebook simultaneously.

• LinkedIn Post Inspector: Excellent for verifying that our business-critical docs are caching correctly on professional networks.

Take Ownership Of Documentation Previews

As tech writers, we often advocate for improvements in customer experience. We meticulously structure our docs, use markdown or DITA to ensure information is accessible, accurate, and scannable.

Taking control of Open Graph metadata extends our advocacy one step further. By treating og:title and og:description as distinct, valuable content types, we can help ensure that the quality of our documentation experience is up to par regardless of where consumers encounter it. 🤠

Join Bill Raymond for Practical AI at Work: Let’s Tour the New ChatGPT App, a free, live, one-hour educational session on September 9, 2026, at 12 noon PT.

Register for free workshop

Sponsored by Cambermast.com training and the Bill Talks AI newsletter, in partnership with The AI Collective and The Content Wrangler.

A practical orientation

A task can start with a quick question, become a larger project, or involve building or improving software. The new ChatGPT desktop app supports all of these types of work. The best place to start depends on what you need to do.

In this live Practical AI at Work session, Bill Raymond will tour the app through three practical questions:

• What are you trying to accomplish?

• What context does the work need?

• Where will you review the result?

Using one realistic workplace request, Bill will demonstrate how those questions can guide the choice of workflow.

Discover Four Areas of The New ChatGPT APP

The session will explore four areas of the new ChatGPT app:

1. Chat — Quick questions, thinking, research, and conversation

2. Work — Longer, multi-step tasks and reviewable deliverables

3. Codex — Work that calls for building or improving software

4. Plugins — Workflows that may benefit from additional skills or connected apps, after you understand access and approval requirements

By the end of the session, you’ll have a simple way to choose Chat, Work, Codex, or a plugin-supported workflow, along with a practical understanding of the features in the new ChatGPT app.

Why Tech Writers Should Attend

Tech writers routinely move among questions, research, source material, drafts, reviews, deliverables, and collaboration with subject-matter experts and software teams. While this workshop is a general orientation to the new ChatGPT app (not a technical-writing course) it offers a useful opportunity to see how the app distinguishes among different kinds of workplace tasks.

What To Expect

Feature access can vary by ChatGPT plan, workspace settings, role, region, and connected-app permissions. This session will provide an orientation and decision method; it does not promise that every participant will have the same options enabled.

Practical AI at Work: Let’s Tour the New ChatGPT App
September 9, 2026 · 12 noon Pacific Time
Free, live, one-hour educational workshop

Attending this free ChatGPT workshop is also an opportunity for you to see Bill Raymond teach. Bill is The Content Wrangler’s AI Training Partner, and we highly recommend his instructor-led training for tech writers and related content pros who want practical guidance for putting AI to work.

Tech Writing-Specific Training Workshops

While the free app workshop provides an introduction to Bill’s teaching approach, if you want more focused, guided instruction aimed specifically at professional content creators, consider registering for his upcoming AI Workshop for Tech Writers and Content Creators (Fall 2026). Classes start September 15, 2026.

💰 You can save 10% off the cost of registration when you use discount code — TCW — at checkout.

Learn More About Tech Writer AI Workshop

That’s why you should consider registering for the Mastering API Documentation with AI course taught by API documentation expert, Mark Wentowski, founder at Docs Geek.

Designed specifically for tech writers, developers, and product managers, this 7-week live virtual bootcamp bridges the gap between theory and practical application.

Why You Should Take This Course

1. Hands-On, Real-World Skills

This isn’t a high-level theoretical overview. You’ll get your hands dirty (figuratively speaking) with the exact tools the industry relies on to produce API Docs.

Over seven sessions, you’ll master:

• Making API requests using cURL and Postman

• Structuring data with JSON

• Writing and troubleshooting OpenAPI and YAML in Swagger Editor

• Identifying user journeys and mapping them into sequence diagrams using Mermaid

2. The “AI Add-On” Advantage

What sets this cohort apart is its forward-looking approach to using AI to produce API Docs. A brand-new (optional) AI module teaches you to use Claude directly inside a GitHub Codespace (no complex local setup required!).

You’ll learn how to draft API flow guides, generate OpenAPI descriptions, and perhaps most importantly, validate AI output against actual API behavior so you aren’t misled by so-called hallucinations.

3. Walk Away With A Portfolio Piece

You’ll walk away with proof of your capability. The course includes hands-on assignments and a final project where you will build and submit a complete API documentation portal for peer review.

If you’re looking to break into API documentation creation, this portfolio piece is exactly what hiring managers are looking for.

4. Flexible for Working Professionals

The Fall 2026 cohort kicks off on Monday, October 19 at 8:00 AM PT. While it’s highly recommended to join the weekly 90-minute live sessions to participate in code-alongs and ask questions, full class recordings are provided for on-demand viewing.

Have a schedule conflict? No worries. Follow along at your own pace asynchronously without falling behind.

5. Pay For The Class In Installments With Klarna

Prefer to spread the cost of the class? Klarna is available as a payment option at checkout, letting you split your enrollment fee into interest-free installments.

Ready To Future-Proof Your Tech Writing Career?

Seats for this cohort are limited and fill up fast. Don’t delay. Reserve your seat today!

Save $250 off the cost of class registration when you use discount code — TCW — at checkout.

Register Today!

Inference gap (noun)

A fact, condition, relationship, exception, or consequence that an audience needs but the content doesn’t explicitly state.

What Creates Inference Gaps?

Tech docs can be 100% accurate and still leave readers (and machines that access our content) completely in the dark. Sometimes an important fact is missing. More often, however, the writer understands exactly how the system works but fails to put those connections in our docs.

They leave out unwritten rules, like:

• who a policy applies to

• when it kicks in

• what the exceptions are, or

• how flipping one switch changes something else

When these connections in our content are missing, readers (human or otherwise) are forced to fill-in-the-blanks by guessing. A human might rely on trial-and-error, past experience, or interface clues. An AI tool will try to stitch scattered sentences together and invent an answer.

Guesswork is a problem when it changes how someone understands our instructions or makes them uncertain what action they should take or what happens if they get something wrong. We don’t have to explain every possible detail imaginable (that’s not a practical solution), but we need to connect-the-dots clearly enough that readers don’t have to guess to get a reliable answer.

Common causes include:

Subscribe now

Read more

The AI Workshop for Content Creators, led by Bill Raymond, in partnership with The Content Wrangler, is designed to help close that gap.

This seven-week, live, instructor-led online workshop gives tech writers (and other content pros) a structured way to apply AI across research, planning, drafting, editing, and quality review. You won’t spend seven weeks watching demo videos masquerading as training. Instead, you’ll build prompt libraries, custom GPT instructions, evaluation checklists, and a plan for putting AI-assisted content production into practice. And Bill will be there to help you along the way.

Learn More and Register

The curriculum (see the week-by-week workshop breakdown at the end of this post) addresses problems tech doc teams already face:

• identifying content gaps

• understanding audience needs along their journey

• maintaining a consistent voice across doc sets

• accelerating content inventories and audits

• prioritizing improvements, and

• establishing editorial controls

The workshop also covers ethical guardrails and governance expectations, subjects that deserve more attention as AI becomes part of routine documentation production.

Each student develops a real-world individual or team project throughout the workshop. By the final session, you should have a repeatable workflow you can continue using and improving.

The workshop runs Tuesdays from September 15 through October 27, 2026, from 10 a.m. to noon Pacific time. Sessions are live and online, and participants receive a certificate of completion.

If you’re ready to move from occasional AI experimentation to a working system for producing and improving content, review the workshop details and register.

Curriculum

Learn More and Register

Inference load (noun)

The amount of unstated information a person or machine must supply to understand content, connect related facts, or decide what to do.

About Inference Load

What Creates Inference Load?

Inference load is created when technical documentation leaves important relationships implicit. Readers and AI systems must determine how facts fit together, whether a rule applies, and what conclusion the content supports. Neither people or machines are particularly good at that.

What Inference Load Looks Like

Read more

Because I am who I am, I’d ask him to define “everybody.” I’d ask whether it included me (it usually didn’t); not because he meant to exclude me, but because he’d never actually said what he meant. He’d said something that pointed toward an explanation and assumed the pointing 👉🏾 was enough.

It wasn’t.

After the relationship ended, I went looking for an explanation of my own. I wanted to understand what was happening in our miscommunication.

So, I ordered a stack of books about ambiguity.

The books approached the topic in the context of linguistics, law, business, ethics, and cognition, not technology. Partway through reading them, I started recognizing a pattern; how people evaluate whether our docs, or an AI answer, is any good.

People who rely on implicit communication — the “everybody knows” move — create the conditions for miscommunication without meaning to. That was obvious to me once I made the connection between ambiguity and understanding that several of the authors touched on. But because of the way my brain jumps from one tangentially-related topic to another, I began to wonder if same implicit-versus-explicit gap in documentation might help (at least partially) explain why AI answer engines produce so-called hallucinations?

Read more

[TL;DR] A taxonomy might look like a neutral list of categories. It’s not. Building one always means someone decides what content earns its own category, what gets lumped together, and what gets left out altogether — and those decisions aren’t neutral.

My friend Rahel Anne Bailie once told me about a taxonomy project she worked on for a European mobile carrier. If I recall correctly, (most days, that’s questionable 🤨), the job was to make an online music library work for listeners in different countries by organizing it so the people in each market could find the music they wanted.

Bailie, founder of Content Seriously and creator of the Content Integrity Model, was helping a client solve the information and data challenges behind a service intended to compete with Apple iTunes. Her team’s work included categorizing the music library, which seems simple, until you try doing it for music lovers in multiple countries.

How Metadata Enters The Equation

Assigning a song to a genre category creates metadata; information that tells a system what something is and where it belongs. Bailie’s team started with a taxonomy shaped by a classification scheme commonly used in the commercial music industry. That taxonomy wasn’t localized for describing music in the new markets Bailie’s client planned to offer the streaming music service to.

👉🏾 Localization is the process of adapting content to be meaningful for a particular culture, locale, or market.

Source: The Language of Localization (XML Press)

To be clear, the categories the music industry used were well-suited for the audiences for which they were built. The problem materialized as Bailie’s team recognized the incongruities in the way music is categorized in various target markets. The solution to the classification problem they faced involved squaring the pre-existing music taxonomy with how each new target market already organized its music. A big challenge given that the original categories hadn’t been designed with this kind of flexibility in mind.

Somewhere in their work, Rahel’s team noticed that world music wasn’t really a genre at all. It was a container: a catch-all category for anything that didn’t fit into existing ones.

Some Countries Organize Music By The Emotion It Evokes

India’s classical music tradition doesn’t organize primarily by genre or geography. It sorts by rasa — the specific emotion a piece of music is built to produce — a system old enough to appear in the Natya Shastra, a text roughly two thousand years old.

Some Countries Organize Music By Color

Traditional Chinese music theory goes further: the five-note scale is mapped directly onto five colors, each note tied to a color, a direction, a season.

In Brazil, the sacred music of Candomblé is organized by orixá — which deity a rhythm calls. Each orixá carries its own color and character, so rhythm, color, and spirit are treated as a single category, not three separate ones.

None of these systems sort music by where it’s from (geography-based music categorization). “World music” doesn’t just group unfamiliar sounds into one bin — it assumes geography-based categorization is the correct way to organize music, an assumption some of the world’s major musical traditions don’t share. That assumption has its own history; and its own paper trail.

It’s not just categories that get stuck at the border. Names can, too. Some of the biggest Western pop stars carry an entirely different identity once they cross into other markets. Britney Spears isn’t categorizes as as “Britney Spears” in China. Chinese fans know her as 小甜甜 (Xiǎo Tiántián), “Little Sweetie,” a nickname with no relationship to a transliteration of her English name. A platform that only indexes her under “Britney Spears” is invisible to anyone searching for 小甜甜.

This Has Been In Heavy Rotation Since 1987💿

The phrase “world music” had existed since the early 1960s, coined by ethnomusicologist Robert E. Brown at Wesleyan University to describe an academic program, not a music marketing category. In 1987, a group of UK record labels met to market a new umbrella term to record stores, so retail shops would have a single bin to store artists that didn’t fit the Western pop and rock mainstream.

Same As It Ever Was, Same As It Ever Was

I was 17-years-old in 1981 when I discovered the song, “Once in a Lifetime,” which turned me on to the new wave band, Talking Heads. Decades later, I was intrigued to find that David Byrne — the Scottish-born American singer and musician best known as the band’s lead singer and guitarist, had something to say about this toss-it-all-in-a-single-bin categorization approach.

It’s clear to me that Rahel’s team didn’t stumble onto a brand-new music categorization problem. Instead, they bumped up against an issue that had been openly discussed by people like Byrne. The lesson here is that taxonomies can (and clearly do) get handed down to others without their history attached. That’s why it’s not surprising that the people applying taxonomy data typically don’t know what assumptions are baked in to the category decision-making process, nor why those choices were made in the fist place.

The Recording Academy has recently revised its award categories in ways that reflect some of the same criticism Byrne highlighted in his commentary. In 2020, it renamed Best World Music Album to Best Global Music Album, explaining that the old name carried connotations of colonialism, folk, and “non-American” music. It also added Best Global Music Performance for the 2022 awards. In June 2026, the Academy announced Best Asian Pop Music Performance, a new category that includes K-pop, J-pop, and C-pop. The broad global categories haven’t disappeared, but the Academy has also begun creating more specific categories alongside them.

The Same Pattern Shows Up In Libraries

This isn’t just a quirk of the music industry: the same categorization pattern appears in a scheme many of us rely on: the Dewey Decimal Classification system. It’s the world’s most widely-applied numerical library classification system, in use in more than 135 countries.

In this system, the category “religion” sits in the 200s. The Bible and Christianity receive most of the range from 220 through 289 (meaning most of the Dewey categorization numbers in the religion section are dedicated to identifying books associated with Christianity). Religious traditions aside from Christianity (e.g., Islam, Judaism, Hinduism, Buddhism, Sikhism, and a variety of Indigenous traditions) are concentrated within 290 through 299, often stacked on top of each other in the same three-digit number.

A 2024 study — using a dataset of more than three million books from a consortium of Ohio academic libraries — found that Dewey’s religion categories show measurably more Western skew than its history or literature categories do, and the Dewey system itself is measurably more biased than the Library of Congress system many academic libraries use instead.

Whatever their intentions, both categorization systems reflected the practical and cultural assumptions and biases of the people who created them. Melvil Dewey built a system that made sense from where he stood, in the late 1800s, and a handful of UK record label executives promoted a system for categorizing music that didn’t fit anywhere else in 1987.

Those who inherited Dewey’s system kept using it without questioning whose perspective it reflected. That’s the reason I wanted a second example here, beyond music. I’m assuming most of you reading this haven’t built a music genre taxonomy, but all of you have organized information for someone other than yourself.

This Problem Shows Up Everywhere

The least surprising version of this problem is ubiquitous and shows up in e-commerce, which is why it’s worth mentioning. Retailers operating across multiple countries run into mismatched categorization constantly. A product that fits cleanly into one country’s taxonomy may be awkwardly placed, duplicated, or missing in another’s. It’s such a routine problem that entire product-information-management vendors exist just to manage it.

Zalando, the pan-European fashion retailer, offers an adjacent example. When the company established a Nordic fulfillment center, it said that being closer to customers would help it provide a more locally relevant assortment, including a larger selection of Nordic brands. The example involves merchandising and logistics as well as information architecture, but the underlying requirement is familiar: a system designed for multiple markets has to account for what people in each market expect to find.

Zalando addressed a related problem by adapting its assortment to regional expectations. It’s also the exception to the rule. Most organizations don’t get there until after the mismatch has already cost them customers, damages market share, or created some other sort of expensive business pain.

What Music, Libraries, And Online Shopping Have In Common

Put the three examples side-by-side and the pattern stops being about music, or libraries, or shopping. It starts being about decisions. A taxonomy looks like a neutral description of what exists. It’s not. Not even remotely. Building one means making decisions — and decisions aren’t neutral.

Someone has to decide what earns its own category, what gets folded into something else, and what gets left off the list entirely.

Dewey already made those decisions when he built out the 200s. Rahel's carrier ran into the same kind of decisions, made by default instead of on purpose. The taxonomy they inherited hadn’t been designed with any other market's categories in mind, and that gap only surfaced once the team started deciding which categories the platform would actually use.

Dewey classified the world’s knowledge based on what he knew and believed back in the late 1800s, and that understanding is still baked into the numbers today. Rahel’s team inherited categories created elsewhere. In Dewey’s case, the creator’s own perspective shaped the system. In Rahel’s project, another organization’s commercial categories arrived already embedded in the work.

You don’t notice a taxonomy’s blind spots until you try to make it work for people it wasn’t built for.

That’s exactly the position Rahel’s team found itself in. Their job was to solve the categorization side of making the platform work across markets, which meant mapping, adapting, or adding categories for each target market — categories the original taxonomy never had. Zalando addressed a related problem by adapting its assortment to regional expectations before customers ever ran into the mismatch.

Every organization that documents, categorizes, or governs information has made these same kinds of decisions, whether or not anyone meant to do so. Support ticket types. Customer segments. Product categories. Content types in your component content management system (CCMS).

Each of those schemas is built around an assumed “normal” case. Nobody likely wrote their assumption down, because the people who built the system already agreed on what normal meant.

Every example in this post so far has focused on a system that organizes information for people to find. The next one organizes information before a person ever sees it.

A Newer Version Of The Same Argument

There’s a newer version of this happening right now, and it’s the one with the highest stakes for anyone who documents things for a living. Increasingly, readers don’t read our docs directly. They ask an AI-powered answer engine a question, and the model that powers it answers using whatever knowledge it has access to.

Sometimes that means retrieving answers from our docs when a question is asked. In that case, labeling, structure, terminology, and other discoverability signals affect whether the system identifies our content as relevant.

Other times, the model answers from patterns learned during training. There, our product info and docs influence an answer only if it was included and retained in the training process in a form the model could learn from.

Either way, it’s the same argument. Metadata helps determine not just how your content is organized, but whether it’s findable, chosen, and understood at all — by a person or by an A-powered tool.

It’s important to note that the corpus of information that models learn from isn’t neutral either. Two influential earlier models illustrate the imbalance: GPT-3‘s training data was roughly 93 percent English, while LLaMA-2‘s was nearly 90 percent. CommonCrawl, one of the largest sources feeding models like these, is roughly 45 percent English — with every other language, including widely spoken ones, trailing far behind.

A 2024 study tested ChatGPT and Mixtral on music specifically. Researchers asked the models to identify leading musical contributors and evaluate the musical cultures of different countries. Both experiments revealed a strong preference for Western music cultures — the same kind of ethnocentrism Byrne criticized in 1999, now appearing in model outputs rather than record-store bins.

An AI training corpus raises a similar problem. It’s shaped by decisions about what to include, not a neutral sample of what exists. The underlying issue is close to what Rahel’s carrier ran into: a system built from one set of assumptions doesn’t necessarily work across every market — or every language — it intends to serve. Now it’s happening to anyone whose documentation gets read by a model instead of a person.

That’s what makes this everybody’s problem: the same decision keeps showing up wherever someone has to sort things into categories, which turns out to be nearly everywhere — a record label, a library, a retailer, and now anyone whose documentation gets read by a model instead of a person.

Rahel’s carrier found out because a new market made the gap impossible to ignore. Zalando addressed a related problem by adapting its assortment to regional expectations. Either way, someone eventually has to ask whether the taxonomy actually works for everyone it needs to serve. Organizations may never ask that question unless someone makes it part of their governance process.

The people closest to the taxonomy — tech writers, content strategists, and CCMS owners — are well positioned to notice those gaps before a customer, a market, or a model exposes them. Not every organization gives someone explicit responsibility for doing so. 🤠

👉🏾 How do we create content AI can reliably understand?
👉🏾 How do we reduce hallucinations?
👉🏾 How do we ensure AI-generated answers are accurate, trustworthy, and consistent?
👉🏾 How do we adapt the practices we’ve spent years developing (structured authoring, taxonomy, terminology management, content reuse, and governance) to an AI-powered world?

This year the conference offers an AI track built around the theme “From Experimentation to Execution: Scaling AI in Content Ops.” While the title references content operations, the sessions themselves are highly relevant to tech writers, regardless of whether they are involved in operational decision-making. In fact, many of the presenters at this year’s event will explore techniques and tactics technical communicators have been practicing for decades, and they’ll explain why those skills have become even more valuable as organizations attempt to deploy AI.

Tech Writers Already Possess The Skills Required To Produce AI-Ready Documentation

One of the strongest messages running through this year’s conference program is that trustworthy AI depends on well-managed content.

Lavacon offers sessions on governed vocabularies, ontologies, taxonomy, structured authoring, workflow management, content modeling, terminology management, content reuse, and global content. Most of these topics aren’t new to tech writers. What’s important to note in today’s fast-changing technology landscape is that these tried-and-true tech writer capabilities are also core competencies that are essential building blocks for trustworthy AI.

A few sessions of interest:

• Brendon Paucek, Senior Content Strategist at Teradata, will show how organizations can establish governed vocabularies and ontologies using tools they already own

• Rob Hanna, CEO of Precision Content, will explain why moving from long topics to modular microcontent makes DITA more AI-ready

• Christi Guzik, Lead Content Operations Manager at Rocket, will discuss building scalable taxonomies

Collectively, these presenters make an important point: AI doesn’t eliminate the need for structured content. It raises the value of producing it well.

Lavacon 2026 Schedule At A Glance

488KB ∙ PDF file

Download

Download

AI Is Changing How We Produce Docs

Lavacon also helps attendees better understand the AI tools landscape. And, more importantly, that AI platforms aren’t fully-fledged content creation and management tools. They lack the governance, workflow, quality assurance, localization, publishing, and cross-team collaboration capabilities that documentation teams rely on to get work done right.

Here’s a few of the presenters to check out:

• Dawn Stevens, President of Comtech Services, will look at why organizations need operational maturity before scaling AI.

• Luis Fernandez, Executive Director at VML, will argue that poor content models (not content management systems) often are the biggest obstacle to AI adoption

• Karen Brothers, Content Manager at Scott Safety, will discuss what it takes to build an AI-ready content culture

• Amanda Patterson, Senior Consultant at Comtech Services, will examine what organizations can learn from human resources when managing AI agents

Taken together, these sessions move past the novelty of AI and into the operational realities of adopting it responsibly.

Our Docs Are The Knowledge Layer For AI

Perhaps the biggest difference between this year’s program and those of just a few years ago is the number of sessions devoted to AI agents. Rather than asking whether AI agents are useful, presenters are showing how to build them, support them, and supply them with trustworthy knowledge.

Highlights include:

• Emma Pindera, Content Strategist at PointClickCare, presents Creating Content AI Agents That Actually Work

• Patrick Bosek, CEO, Heretto and Megan Gilhooly, Sr. Director Global Content & Intelligence, OneTrust, present Beyond the Bot: How Structured Content Drives an Agentic Ecosystem Across Your Entire Content Stack

• Aman Goyal, Agentic AI Product Manager at T-Mobile, presents Show Me the Agents! Decision Framework for Content Operations AI

• Theresa Daudier, Senior Knowledge Management Engineer at ServiceNow, presents How ServiceNow Used Agentic AI to Reduce Costs and Improve Customer Experience

For tech writers, these sessions reinforce the emerging reality of our profession: our docs are no longer consumed only by people. Increasingly, they’re the trusted knowledge that AI systems retrieve, interpret, and use to answer customer questions.

Trust Matters

If there’s one word that appears repeatedly throughout the schedule, it’s trust.

Speakers explore how organizations can reduce hallucinations, verify AI-generated knowledge, improve translation quality, manage terminology, and preserve human oversight.

• Klaus Fleischmann, CEO of Kaleidoscope GmbH, presents, Terminology: The Clever Cure for Hallucinations

• Kay Conerly, Director of Content Strategy at McGraw Hill, presents, Maintaining Trust in the AI Era: The Enduring Value of Human Expertise in Content

• Ben Cohen of Localize and Nick Wyatt of Aras, present AI Translation in the Real World: Lessons from the Team at Aras on Building Scalable Global Content Workflows

• Sandi Markle of Blueberri, presents, Structure Starts with Trust: Building Cultures That Support Content Systems

These sessions recognize that trust isn’t created by technology alone. Instead, it it earned when we produce well-designed information.

What Skills Will Matter Most?

That question is likely on the minds of nearly all LavaCon attendees. The opening keynote speakers topic selection illustrate how much expectations are changing.

• Maria Romanovsky, Director of Content Design and Strategy at TikTok, presents AI Didn’t Replace You—It Promoted You to Manager

• Keith Boyd, Senior Director at Microsoft, presents Content is Still King: Thriving in the Era of AI

Half-Day Training Workshops

In addition to presentations, Lavacon also offers optional pre- and post-conference workshops (for an additional fee).

2026 Workshops

• Daniel Schomer, How to Build a Content Governance Model

• David Hobbs, Effective Content Inventories and Analysis

• Susan Kelley, From Notes to Knowledge: Learning Faster with Notebook LM (An Interactive Lab for Communicators)

• Gaetan Chretiennot, The “Translate” Button is a Trap: Mastering Translation Risk in an Era of Generic AI

• Sarah Johnson, Operationalizing the Content-First Framework: Diagnose Meaning Drift, Align Teams, and Scale Content with Confidence

• Carol Hattrup, They Already Sent a Poet, and It’s You!

• Leann Long, MythBusters Lab: Let’s Test What Really Works for Remote Content Teams

• Rebecca Schneider, Creating Taxonomies for Your Organization in the Age of AI

• Melanie Davis, Tech Stack Lift-and-Shift: A Tag-Team Approach to Success with Limited Resources

• Dipo Ajose-Coker, Inclusive Content In The AI Era: Bias, Culture, And Who Gets Left Behind

• Rhyne Armstrong, From Shadow to Servant: Confronting the AI Beast

• Amanda Patterson and Brianna Stevens-Russell, Stop Building Bots. Start Hiring AI Employees: How HR Thinking Makes AI Agents Safer, Smarter, and Easier to Manage

Why I’m looking forward to LavaCon

What excites me most about this year’s program is that it reflects where our profession is today.

We’re no longer being asked whether we should pay attention to AI. We’re being asked to help our organizations make AI work. That’s a very different challenge, and it calls on many of the capabilities technical communications pros have spent years refining: creating clear, structured, high-quality, reusable, well-governed content that people can trust.

If you want to see how those skills are being applied across organizations like yours, LavaCon 2026 offers an exceptional opportunity to learn directly from the people doing the work.

Register at lavacon.org, and use discount code TCW at checkout to save 10% on the cost of registration.

Register Today!

I hope you’ll join us in Charlotte this October. I look forward to seeing you there. 🤠

The math was simple and enormous. The company estimated the new drug would earn roughly four million US dollars a day once approved. But the bigger driver was the patent clock 🕰️. Every day the writers spent wrestling with intricacies in the content before submission was a day the drug sat unapproved and unable to be sold. It was also a day closer to the patent’s expiration date. After that, generic makers could copy the formula without doing the research or repeating the safety and efficacy testing the original maker (my client) had already paid for.

That price tag wasn’t small. The company was chasing blockbuster status — ka-ching 💰 ka-ching — industry shorthand for a drug that clears a billion US dollars a year in global sales.

Getting there wasn’t cheap, either. A Tufts Center for the Study of Drug Development estimate put the cost of bringing a new drug to market in that era at roughly $800 million USD. About one-half of that money was direct research and clinical trial spending. The remainder was the capitalized cost of years of tied-up resources and the compounds that failed to become approved products along the way. Falling short of blockbuster sales numbers meant not recouping what the drug cost to make.

Example: Celebrex — Pfizer’s arthritis and pain medication — is the textbook case. Launched in 1999, it was pulling in roughly $2.9 billion USD in sales a year before its patent protection ended in 2014 — resulting in the company losing the bulk of that revenue within about a year once generics arrived in the market.

My client’s IT department was fixated on solving problems with whatever Microsoft software they already had, or whatever they could code themselves with the skills they’d built up over their careers — exactly the same way a man with a good hammer treats every problem like a nail, whether or not it is one.

The writers asked the IT team to help them develop a capability known as systematic content reuse. The “mother of content strategy,” Ann Rockley, coined the term to describe content that is tagged once and automatically published everywhere it belongs. Nobody has to remember where the content lives or go looking for it.

IT heard something different. They thought we were asking for a better way to copy and paste content.

What they knew was the other half of Rockley’s distinction: opportunistic reuse, where someone remembers a paragraph exists, tracks it down, copies it, and then, pastes it in. It’s the most common form of content reuse there is. It doesn’t require any special technology. That’s exactly why the IT team couldn’t see what our tech comm staff was asking for.

What changed their minds was an exercise a trainer named Sally Chase (now retired) ran with the whole group — writers and IT together — training us on the newly-released Arbortext Epic XML editor (one of the first tools built specifically for authoring XML), and on how to build structured XML content designed for systematic reuse following a single-source publishing model. She put everyone in a computer lab, handed out instructions, and had them work through a set of tasks alone, about an hour’s worth. Then she sent everyone to lunch, which in hindsight was the whole point.

When the group came back, she announced she’d handed out the wrong instructions by mistake, and that she’d already removed them from every workstation over lunch. The new instructions, she said aloud, were simple: undo everything the first set had asked them to do.

One IT crew member raised his hand, audibly frustrated. “How are we supposed to remember what you had us do previously,” he said, “when you took the instructions away?”

That was the moment IT understood what a component content management system was actually for. Not software. Memory.

Read more

According to the client, during a string of security incidents this year the tool started giving incorrect instructions that made things worse. For example, the tool told the team to isolate a compromised server using an API parameter that had been retired months earlier. It also walked a customer through re-enabling an encryption setting that the engineers had phased out for compliance last year. And, in another case, it pointed a customer toward what looked like a standard access shortcut — but was not. Instead, the customer was instructed to utilize a leftover authentication bypass built for a sales demo and never removed from the system.

What The Investigation Found

The client told me their engineering team’s first theory was the oh-so-obvious one: the model was hallucinating.

The engineering crew was wrong. After a little detective work, the team discovered that the theory didn’t hold up once someone checked what the AI had retrieved against what was true. To be clear, the information in the hallucination-laden AI generated text was true once-upon-a-time. But, when things changed with the product, that documentation was never updated. Tracing it back to the source turned up technical documentation files that had been sitting there, unmaintained, for quite a while.

Upon closer inspection, they found:

• the retired API parameter still listed in a publicly available integration guide nobody had updated

• the reasoning behind a compliance change that was only once discussed in a Slack thread between two engineers who’d never migrated it to the wiki the AI used as source content — and who both no longer worked at the firm

• the authentication bypass sitting in the codebase with no comment marking it temporary

• the architecture diagrams the model relied on pointing to repositories that had long-since been deleted

On its own, that’s a documentation debt story.

How The AI Reasoned From What It Found

All of the information accessed by the AI was, at least partially, accurate. The facts were fine. It was the absence of explicit cues in the source content and the model’s reliance on that content that led it to generate inaccurate answers.

That’s an inference failure, not a retrieval failure.

Handed the exact same content, a human cybersecurity tech writer likely would’ve stopped to pause and ask perhaps questions of the underlying information. Experienced folks whose day-to-day work provides them with knowledge those with lesser experience lack, likely notice when something looked off, is out-of-date, or otherwise, potentially wrong. It’s background work most of us do constantly without paying much attention to it.

The AI retrieved the same clues as the human cybersecurity tech writer and did not stop to pause and ask questions of the content. It moved straight from “this exists in a document” to “this is the instruction,” with nothing in between.

The Role Nobody Replaced

The client told me something else about that team. Before any of this, they’d had a reviewer everyone relied on — let’s call her Betsy, since her real name isn’t mine to share.

“Everyone relied on her because she was so good at it,” the client told me.

Betsy was, in their words, always the person who’d say, “That doesn’t look right.”

She retired recently. Nobody replaced her with someone who had the same eye for detail. Her responsibilities got split across the rest of the team instead, so proofing and review responsibilities became something everyone was expected to own a piece of — rather than something one dedicated person owned.

She wasn’t simply catching typos. Betsy’s value came from context, product knowledge, and years of experience layered on top of ordinary editing — the kind of background that lets someone recognize when something is off even when nothing is technically wrong. The client’s regard for her was so high that I started thinking of her as the queen of that function. Nobody worried about coverage while she held that role, because she was there.

And then she wasn’t.

Replace Betsy with a system that reads the same docs at machine speed, and the habit of stopping to ask whether something looks right disappears along with her. The documentation debt didn’t get worse. It got a new kind of reader — one with no instinct for stopping to check for accuracy. 🤠

What Claude Was Actually Reading

Claude answered, and its answer confused me. It described the company as serving small and medium-sized businesses in Europe — which wasn’t what I understood the company was trying to communicate. The company was working to expand into the US market, and I knew that going in. So I challenged Claude to explain where that description came from.

Claude then told me what it was actually looking at. The site, it explained, runs as a single-page JavaScript application. The initial HTML response didn’t contain the web page copy a visitor sees after the browser runs the JavaScript.

Some sites work this way by design. The server sends an HTML shell and a bundle of JavaScript; the browser runs that code and constructs the visible page. A retrieval tool that reads only the initial response may never receive the resulting copy. On this site, Claude found the title, the description, and a few other tags — but not the body content. Claude pointed to two of those tags specifically: the meta description and the Open Graph description, nearly identical, one line each — both describing that same European customer base, written for search engines and social-media link previews rather than for a reader trying to evaluate whether to hire this company.

So I copied the entire page — the actual marketing copy, not the URL — and gave that to Claude instead.

From the metadata, Claude described a company that helps European SMEs make their content AI-ready. That wasn’t what the company was trying to communicate. It wanted to reach businesses in the United States and beyond. After reading the page copy I provided, Claude described a broader argument: AI is already consuming a company’s content whether the company prepared it or not, and the quality of that output depends on how well the content is structured. The company delivered this through a staged program — assess, define, transform — that didn’t require adopting a new authoring standard first.

None of those distinctions appeared in the initial HTML. To a tool that never ran the site’s JavaScript, this company was two sentences long — and, on the question of who it served, those two sentences said something the company itself didn’t say.

What This Means

I don’t think the company made an unusual mistake. Many sites render their content in the browser rather than sending it fully formed from the server. Whether an AI retrieval tool can read that content afterward depends on a separate decision: whether the server also produces a readable version for tools that don’t execute JavaScript. That decision is usually made once, by engineering, when the site is built — and rarely revisited by whoever writes or approves the marketing copy. I noticed the gap only because I asked an AI to summarize the company before reading the site myself. Other people evaluating the company could do the same, and get the same incomplete answer.

The stakes here weren’t abstract. The company was working to expand into the US market. I was reviewing it from the US. Claude, working only from the metadata, positioned the company as Europe-focused when it was trying to reach businesses in the United States and beyond. A prospective US customer running the same search, or an AI assistant evaluating the company on that customer’s behalf, could have reached the same conclusion.

The site was built with Lovable, an AI-powered platform that generates websites and apps from written prompts, which makes the cause harder to identify. Lovable now uses server-side rendering by default for projects created after May 13, 2026, built on a framework called TanStack Start. Older projects, built on React and Vite, are pre-rendered on request instead — but only for verified crawlers; human visitors still receive the client-side application.

In this situation, Claude, apparently received that client-side application. I can’t say why. Perhaps the project predated Lovable’s current architecture or maybe the request wasn’t recognized as a verified crawler. Or perhaps the pre-rendering may failed for that request.

Server-side rendering could have made the page’s actual copy available in that initial response. A meta description that matched the page’s actual intended audience — instead of naming the wrong region — would have given Claude a more accurate account even with the body copy inaccessible.

Structured data could have added machine-readable facts about the company (product, for example), but it wouldn’t have exposed the full argument or explained the staged program the company plans to offer. Those details lived in the website copy itself.

The experiment made me wonder who was responsible for the machine-readable version of this company’s pitch — and whether anyone had reviewed it as content.

Tech writers already verify procedures, terminology, and examples before publication. They should also review the page’s title, description, structured data, and the content available before its JavaScript runs.

My experiment began as a positioning review. It ended with two descriptions of the same company: the one prospective customers could see and the one Claude could retrieve. The visible page addressed a broad market. The metadata positioned the company as serving small and medium-sized businesses in Europe.

Nobody signs off on a meta description the way they sign off on website homepage. Metadata often gets copied from wherever it was last written, or generated once and forgotten about. Increasingly, it’s also the only version of the pitch some readers will ever encounter — not because they skipped visiting your website, but because the tool they used to evaluate your company couldn’t access it. 🤠

It attempts to evaluate organizational preparedness across seven pillars. The strange thing is, technical documentation isn’t one of them. That sent me looking for where, exactly, technical documentation should fit into Microsoft’s model, and whether an organization can call itself AI-ready while the documentation feeding its answer engine isn’t.

What Microsoft Means By AI Readiness

Microsoft’s AI Readiness Assessment evaluates whether an organization has the strategy, governance, data, people, infrastructure, and model-management capabilities to adopt AI securely and at scale.

It’s built around seven pillars:

1. Business Strategy

2. AI Governance & Security

3. Data Foundations

4. AI Strategy & Experience

5. Organization & Culture

6. Infrastructure for AI

7. Model Management

The assessment runs on multiple-choice / multiple-response questions. Completing it produces an overall score, category-level recommendations, and links to related guidance. Signed-in participants can export their results to a CSV file.

This assessment approach seems like a reasonable way to size up organizational readiness. Companies looking to put AI to work need leadership support, real safeguards, usable data, decent infrastructure, and people who know WTF they’re doing.

But there’s a question hiding inside those seven pillars that Microsoft never asks directly:

What knowledge is the AI actually going to use when someone asks a question (and expects an accurate answer) about how our products work?

Read more

Then I realized something was different. Those files mostly help systems discover or process information that’s already there. llms.txt exists to help AI systems understand our documentation.

For decades, tech writers have made editorial decisions about what customers should know. We decide which concepts deserve an explanation, which procedures belong (or don’t) in our product docs, and which content should be retired because it no longer reflects reality.

Today, many publishing platforms automatically generate a document whose audience isn’t your customer at all. Instead, it’s AI.

This Isn’t Just Another Generated File

An llms.txt file is often described as a guide for AI systems. That’s accurate, but incomplete. It’s much more than that. You can think of it as a summary of what your organization considers important enough for AI to read first.

Depending on how your documentation platform generates it, the file may point to product overviews, API references, tutorials, SDKs, migration guides, code examples, and other documentation. An AI system can use that information to build an initial understanding of your product long before it retrieves content from any individual page.

That’s a different editorial function than a sitemap.

👉🏾 A sitemap says, “These pages exist.”

👉🏾 An llms.txt file effectively says, “Start here.”

Automatic Doesn’t Mean Curated

Recently, I examined the llms.txt file for a public API documentation site. Nothing in it was confidential. Every page it referenced was already public.

What surprised me wasn’t the content. It was how much easier the file made it to understand the product.

Instead of exploring the documentation one section at a time, I could immediately see the major APIs, supporting guides, integration points, and product organization. The documentation had been distilled into a machine-readable map.

That’s exactly what the file was designed to do.

The question is whether that map reflects an editorial decision or simply the default output of a publishing platform.

Those aren’t the same things.

An automatically generated file may include deprecated documentation, legacy APIs, archived migration guides, experimental features, or transitional content simply because those pages are still public. The software doesn’t know which content best represents your product today. It only knows what we tell it.

This Is An Editorial Question

Tech writers are the people who decide how a product should be explained. We choose examples, organize information, and retire obsolete content. We often work with product managers, software developers, support teams, and legal reviewers because we understand that publishing is an editorial process, not a database export.

I think llms.txt belongs in that process. If AI systems are going to use it as a starting point for understanding our documentation, then someone should review what it communicates before its published.

Not because AI shouldn’t read your documentation. Because we should be intentional about what we’re helping it understand.

A New Publishing Checklist

Most documentation teams already review titles, links, examples, screenshots, and metadata before publishing. It may be time to add one more item to that checklist.

👉🏾 Review the documentation we’re publishing for machines with the same care we give the documentation we’re publishing for people.

A publishing platform can generate an llms.txt file automatically. Only we can decide whether it tells the right story about our product. 🤠

Note: The llms.txt specification is evolving through community input. Its GitHub repository provides version control, issue tracking, and public discussion, while a community discord channel gives implementers a place to share experiences, compare approaches, and discuss emerging best practices.

Our documentation is still doing its job, however, the people we’ve been creating those docs for may never actually visit our doc portal this time around. That’s an enormous shift that wasn’t much of a consideration only a few short years ago.

Why Should Tech Writers Care About Zero-Click Searches?

Tech writing pros should care about zero-click searches because the decisions we make change how our customers discover and use our docs.

More people are turning to AI chatbots and AI-powered search for information, and many accept the answer without visiting a source page. Pew Research Center found that 42% of U.S. adults use chatbots to search for information and 60% read AI summaries in search results. When Google displayed an AI summary, users clicked a link within it in only 1% of observed visits. For documentation teams, the implication is clear: product info can reach customers through an AI assistant, AI-generated search summary, or support application even when they never visit the documentation site where it was published.

That means traditional doc portal traffic reports no longer meaningfully reflect real-world usage. Zero-click searches also increase the importance of clear writing, consistent terminology, structured content, metadata, and governance because those elements directly influence the quality of the answers AI systems generate about our products.

Related reading: The Impact of Google AI Overviews on Publisher Traffic and User Experience: Evidence from a Field Experiment

Read more

Rather than guess, she called customer support. The representative who served her told her to enter the Policy ID.

My mother replied:

“If they’re the same thing—and to be clear, they’re not—I wouldn’t have needed to call you in the first place.”

The representative knew immediately why my mother was frustrated and which number she actually needed. My mother didn’t.

Why Insurance Forms And Cards Use Different Terms

Typically, these mismatches arise because the form, insurance card, and customer support content are each built and maintained (well, sometimes 😎) by different teams (often using different software) with no shared single source-of-truth connecting their terminology.

Each team labels the same identifier within its own system and for its own purposes, which can be — and often are — different. Nobody owns the relationship between the differing labels.

Is This Just An Insurance Industry Problem?

No, it isn’t. I’ve seen the same disconnect in software licensing terms, telecom account numbers, HR benefits portals — anywhere a form asks for one thing and the source document hands the customer another.

My mother’s insurer isn’t unusual in this respect. In my own consulting work, I’ve repeatedly encountered the same pattern: organizational structures that divide work into departments tend to produce siloing, and the mismatched results of that situation often produce exactly this kind of labeling problem. When the results get big enough (inconvenient, painful, expensive enough), I call them content hairballs, a term I picked up from Ray Gallon, co-founder of The Transformation Society, who once described organizational content as a tangled mass that different teams and disciplines each get their hands into without anyone owning the whole.

Is This One Insurer’s Mistake Or An Industry-Wide Pattern?

I didn’t need to investigate whether this was unique to my mother’s insurer. Experience had taught me it wasn’t. What I wanted to know was whether people were talking about it publicly, and they are.

As one explainer puts it, insurers aren’t consistent in how they label these numbers, and it routinely tells people to call customer support if they’re not sure which number applies. That guidance exists because people keep asking the same question online — strangers, in public, running into the same confusion my mother did.

That phone call to support isn’t an exception. It’s the documented, expected way the ambiguity gets resolved in far too many organizations today.

What This Reveals About Product Info As A Business Asset

The relationship between Member Number and Policy ID has already been resolved once — by a customer support representative who knew the answer. That resolution doesn’t live anywhere a customer (or an AI system) could find it on their own.

My mother’s support call didn’t happen because information was missing. It happened because the relationship between the two terms was never made explicit where she needed it. Customer support teams have been consistently bridging gaps like that for years, absorbing the cost of inconsistent terminology one phone call at a time. ☎️

AI systems reason from whatever product information organizations make available to them. When the relationship between two terms is implicit there, AI inherits the same ambiguity customers have been living with for years. An AI assistant can’t ask a colleague which label the organization really intended — it can only reason from the evidence it’s given, and it doesn’t always do that correctly.

What This Means For AI Readiness

AI readiness may start earlier than most organizations assume; with terminology management, before any model, prompt, or retrieval system gets involved. If AI systems depend on someone having resolved relationships like Member Number and Policy ID, what else has customer support been compensating for that no one ever wrote down? 🤠