Not “almost full.” Not “act now before the imaginary countdown clock starts sweating.”

Sold out!

That tells us something. Tech writers and content creators aren’t just curious about AI anymore. They’re trying to figure out how to use it.

Most of us have already experimented. We’ve summarized, rewritten, drafted, prompted, re-prompted, and stared at an answer that looked correct until it started gently lying.

That’s where this course comes in.

Instructor Bill Raymond teaches this 7-week, hands-on virtual workshop for people who want more than AI party tricks. It’s built for writers and content pros who need practical ways to use AI with more control, better judgment, and fewer “why did it say that?” moments.

Because the first class sold out, we’ve added a second cohort.

The new session meets online Tuesdays, July 14 – August 25, 2026, from 10 a.m. to 12 p.m. PT.

Learn more and register.

💰 Use discount code TCW at checkout to save 10%. 💰

And suddenly the tool clutches its pearls. »> “I can’t help with that!”

Or worse, it can help—but only after it’s rewritten your request into something so polite and sanitized it sounds like it’s applying for a job in corporate compliance.

Meanwhile, somewhere else on the internet, another AI happily produces exactly what you asked for—no moral lecture, no creative editing, no hall monitor energy.

So What Gives?

It’s tempting to think one AI is “better” and the other is “worse.” Or that one is “censored” and the other is “free.” But that’s not really what’s happening.

What you’re seeing is the result of design decisions. Not intelligence. Not morality. Design.

There’s No Such Thing As “Neutral AI”

Every AI system comes with opinions baked in. Not the model’s opinions, exactly, but the opinions of the people who built, tuned, and deployed it.

Those opinions show up in a few predictable places:

• What data the model was trained on

• What kinds of outputs it was rewarded or penalized for producing

• What filters sit in front of it, watching your prompt like a suspicious librarian

• What filters sit behind it, quietly rewriting its answers after the fact

By the time you type your request, you’re not talking to a raw model. You’re talking to a governed system. And that system has rules it is supposed to follow.

Read more

This June lineup covers the things tech writers keep circling back to: scaling content without breaking teams, making sense of content operations, getting into the field, and figuring out what AI is going to change next (and what it won’t, despite its enthusiasm). You’ll hear from practitioners, strategists, educators, and the occasional truth-teller who’s seen what happens when good intentions meet messy reality.

Each session runs for one hour, which is just enough time to learn something useful without questioning your life choices. And if your calendar has other plans — which it will — registering still gets you access to the on-demand recording after the live broadcast. That means you can watch when it suits you, pause when someone says something worth stealing, and pretend you were there all along.

If you’re new to the channel, there’s also a small detail worth mentioning: there are already more than 800 recorded one-hour educational sessions waiting for you. That’s a suspiciously large archive of hard-earned knowledge from people who’ve done the work, fixed the mistakes, and are willing to talk about both.

🗓️ [June 9] How to Scale Content Teams Without Slowing Delivery

Join Effie Sharon Sinena, Product Delivery Manager (Technical Documentation) at Lexmark Research and Development Corporation (now part of Xerox), as she shares practical lessons from startups and fast-growing organizations on building resilient content operations that don’t burn out your team or compromise output.

Register

🗓️ [June 10] Introduction to Content Operations for Tech Writers

Join Rahel Anne Bailie, Content Operations Strategist at Content Seriously, as she demystifies the difference between content supply chains and lifecycles—and reveals where hidden inefficiencies can quietly drain resources.

Register

🗓️ [June 11] The Cerberus Project: How to Enter Tech Writing

Join Maria Haque, teacher at PACE - Academy for Gifted Children, and Christina Mayr, Documentation Team Manager & Senior Information Architect at Epic Games, as they unpack how newcomers can break into the field using The Cerberus Project as a practical case study.

Register

🗓️ [June 16] The Content Integrity Model: Framework for an AI Age

Join Rahel Bailie, Content Solutions Strategist at Content Seriously, as she introduces the Content Integrity Model — a practical framework designed to help you align your content strategy with organizational goals while ensuring editorial quality, operational efficiency, and a resilient infrastructure.

Register

🗓️ [June 16] Structuring Prompts for Technical Communication

Join Professor Lance Cummings of the University of North Carolina Wilmington as he reveals why prompt structure (not just length) determines whether your AI-generated content meets professional standards. Explore a practical framework for structuring prompts using three core components: task, context, and content.

Register

🗓️ [June 17] Proving Better UX Content Is Worth The Investment

Join Julia Warrender, Senior Content Strategist at TELUS, as she shares a practical framework that connects traffic, conversion, and customer value to estimate the real financial impact of poor content. Julia will demonstrate her simple “Content Impact Model,” show you how to build one even with imperfect data, and guide you through using it to influence prioritization and decision-making.

Register

🗓️ [June 18] Reinventing Yourself While AI Changes the Rules

Join Raegen Pietrucha, author, career coach, and consultant dedicated to empowering writers, as she explores why we get stuck in our routines, how confidence can quietly morph into complacency, and what it takes to break free. You’ll learn to spot subtle signals that you’re ready for change, recognize obstacles that hold you back, and ask yourself the right questions to reignite your initiative.

Register

🗓️ [June 18] Better GenAI Content Starts With Human Oversight

Even minor errors can create outsized problems — Charles Dowdell, Manager and Consultant at Wisdomino Corp (transitioning from Komatsu), will share real-world examples where small mistakes led to big consequences. Explore proven methods for content quality control that you can implement right away.

Register

🗓️ [June 23] A Solo Tech Writer’s Lessons, Missteps, Wins Adopting AI

Join us for a chat with Sowjenya Parthasarathy, Technical Writer at Funnel, as she shares her approach to analyzing user intent using search data, support queries, and behavioral tools. Discover how these insights can shape more effective AI-powered conversations with your users—even if you lack enterprise resources.

Register

🗓️ [June 25] It’s Time To Start Treating Content As Infrastructure

Joseph Phillips, Content Infrastructure Strategist at The Examined Web, will reveal how organizations waste resources by viewing content as a commodity rather than as critical operational infrastructure. Explore practical steps for shifting your mindset and operations toward sustainable, scalable content practices.

Register

First attempt: BLOCKED! Apparently a harness, even in daylight, suggests I might be moments away from asking for something involving handcuffs and poor decision-making.

Second attempt: success… sort of. The man appeared wearing a harness over a fancy midcentury short sleeve dress shirt, which is a bit like wearing underwear over jeans. Technically possible. Otherwise, incorrect.

I adjusted the prompt. Clarified intent. Emphasized “fashion,” “editorial,” “not sexual.”

The AI nodded, took notes, and then produced a man standing by a pool… wearing a harness… and still clinging to that 70s-style print shirt like it was his emotional support garment.

At this point, I wasn’t generating images. I was coaching.

Eventually (after removing, rewording, softening, reframing, and essentially whispering to the machine, “I promise this is just a nice man enjoying the sunshine”) it finally complied.

Shirtless. Harness on bare chest. Poolside. Palm Springs. Correct. Victory!

But here’s the interesting part: nothing I originally asked for was inappropriate.

What the system kept doing was correcting me (not for accuracy, but for safety). It wasn’t reading culture. It was reading patterns. Somewhere in its training data, “harness” lives in a very specific neighborhood, and even when you move it to Palm Springs in broad daylight by the pool, the AI image generator still thinks it might turn into a situation requiring a safe word.

So it hedges. It adds clothing. It tones things down. It quietly rewrites your request into something it feels better about.

Not more accurate. Just… safer. And that’s the issue. Because harnesses aren’t just fetish gear anymore. They’re fashion (check out Pinterest). For some, they’re Pride, they may be seen at pool parties, music festivals, and in Instagram ads that somehow know exactly when you’re feeling emotionally available and financially irresponsible.

But the AI hasn’t caught up. It’s still operating like a well-meaning chaperone who’s convinced that if you remove one more button, society will collapse.

Today it’s a harness. Tomorrow it’s something else the model doesn’t fully understand but feels oddly nervous about. And honestly, that’s the real story here. Not leather. Not sex. But what happens when a machine sees a cultural signal, panics slightly, and mistakes its own outdated assumptions for good judgment.

Also, for the record, if you ever see someone wearing a leather harness over a dress shirt at a Palm Springs pool, please check on them. They may likely be in distress. 🤣

👉🏾 You think, “Well, that’s better.”

Then you look again.

👉🏾 The warning is gone.
👉🏾 The prerequisite has been politely implied into nonexistence.
👉🏾 The conditional step has been simplified into something that would work beautifully in a world where nothing ever goes wrong.

Nothing looks broken. And yet, everything is just slightly… off.

This is what some call the car wash error.

What Is The Car Wash Error?

It’s not a formal term. We won’t find it in industry research papers. It’s a practical observation from people who’ve watched content go into a machine and come out looking cleaner while quietly losing the important parts; the ones that mattered.

Put simply, the car wash error happens when AI makes content smoother and easier to read, but not helpful in real-world situations. The content goes in with dents and bugs 🐞 on the windshield. It comes out polished.

But then, somewhere along the way, a side mirror falls off.

Read more

You’re at the airport. You’ve got your tragic little sandwich in a paper bag, your phone battery is hanging on by a thread, and the gate agent smiles as she scans your boarding pass.

Then she says, almost as an afterthought, “Just so you know, the maintenance procedures, safety documentation, and operating guidance for this aircraft were autogenerated by a large language model. No human reviewed any of it, but the output was looks great.”

Do you keep walking down the jet bridge? Would you really board that plane?

Or do you suddenly decide that maybe this is the perfect time to reconnect with Amtrak.

That, in a nutshell, is the conversation a lot of us are being asked to have about AI-generated technical documentation. Only instead of saying it plainly, some leaders prefer to dress it up in phrases like “content acceleration,” “operational efficiency,” and “reimagining the authoring workflow,” which is executive dialect for “we’re about to try something reckless and would like it to sound visionary.”

The Trouble With Text That Sounds Smart

This is the problem with LLMs. They’re very good at producing language that appears to know what it’s talking about. They sound calm, competent, and confident. They sound like the kind of person who’d use the phrase “best practice” without once stopping to ask whether the practice in question might get someone electrocuted.

And that’s exactly what makes them dangerous in high-stakes documentation environments.

Read more

There was a time when products had the decency to be one thing.

A toaster toasted. A manual explained how not to electrocute yourself while using it — specifically, “do not use in bathtub or shower,” which suggests at least one person looked at a toaster and thought, sure, let’s bring this into the one room specifically designed for water. Everyone went home slightly safer and mildly warmed.

Now you’re handed a product that contains sensors, firmware, a touchscreen, a motor, three safety interlocks, and a support article that says, “Press the button.”

👉🏾 Which button?
👉🏾 What happens next?
👉🏾 Why doesn’t that happen sometimes?

And why the machine is blinking at them like it knows something they don’t — which, historically, has not gone well for humans. If you need a cultural reference, think of the VCR clock blinking “12:00” for eternity because no one in the household wanted to admit defeat and read the manual. There’s an entire genre of jokes about this phenomenon.

Welcome to mechatronics — you’ve probably been documenting it for years without anyone bothering to tell you what it’s called.

The Moment Products Stopped Being Polite

Mechatronics is what happens when engineers stop pretending their disciplines live in separate apartments and start sharing a kitchen. It blends mechanical engineering, electronics, software, and control systems into one integrated system. Not “a machine plus some code,” but a system designed to sense, decide, and act.

Why does this matter? Because this isn’t just a stack of technologies. It’s a design philosophy that aims to help us ensure everything works together from the start.

Read more

Getting a machine to spit out a pile of plausible-looking output is not the same as doing the work well.

Tech writers should pay close attention to this distinction, because it applies to us just as much as it applies to software designers.

Christopher Noessel (follow him on Medium) recently shared an interesting reflection on using Anthropic’s Claude Design. He started with what seemed like a harmless experiment. He issued a design-related challenge to the tool and asked it to generate wireframes (low-fidelity, black-and-white structural blueprints focusing on page layout and functionality) and comps (high-fidelity, polished mockups showing the final visual design, colors, and typography).

Compared with another tool he had tried previously, the results were better. But better didn’t mean useful. Instead of helping him think through the problem, the AI handed him a large dump of finished-looking artifacts. And that, he realized, was the problem.

Too Much Output Creates A New Challenge

The output looked impressive, but it did not help him understand the decisions behind it. For instance, it didn’t help him evaluate whether the work was sound. It didn’t build confidence, instead it just created the familiar modern sensation of being handed too much stuff too fast and being expected to clap. 👏

That insight should feel very familiar to tech writers.

Read more

Suddenly, people who never cared much about content structure, review cycles, or metadata are speaking as though a chatbot will descend from the heavens and sort out the last fifteen years of documentation neglect.

That isn’t what the data says.

The 2026 State Of AI In Technical Documentation

The 2026 State of AI in Technical Documentation Report, based on responses from around 400 participants, most of them experienced technical communicators, paints a much more useful picture. AI is already part of our work. It is helping us do more work faster, but it’s not trusted enough to allow it to run wild. And the biggest obstacles to getting more value from AI in tech docs aren’t technological so much as organizational, structural, and painfully familiar.

Which is to say, the profession has not been rescued by a machine. Instead, it’s acquired a new assistant with a speed and truth problems.

Get The Report

Read more

A customer disaster story with a very modern lesson for tech writers and documentation leaders

A few years ago, while consulting with a financial services software company, I got pulled into one of those situations that starts with “a customer is upset” and ends with leadership acting stunned that documentation quality might affect customer retention.

Duh! 😒

The company sold an automated mortgage approval system to lenders. This wasn’t some whimsical app that guessed your aura or matched your leadership style to a breakfast pastry (<— that’s not a thing, yet). It was serious software used in highly regulated environments, where customers needed clear, trustworthy guidance to deploy, configure, and use it correctly.

One customer had had enough. ✋🏼

They’d spent a long time (and wasted a lot of money) trying to make sense of the material the vendor had provided. And “provided” is generous at best.

What they’d actually received was less a set of docs and more a content yard sale assembled by well-meaning people who’d apparently never met a governance policy. There were formal docs, some of which may even have been accurate. There were PDFs from marketing, training materials, spreadsheets from internal teams, reference docs, bug notes, release notes, future roadmap tidbits, links to files marooned in SharePoint, and yes, emails.

All of it had been bundled into one giant zip file, as if customers enjoy panning for truth in a river of miscellaneous corporate debris.

They do not.

After several frustrating meetings, the customer used the cancellation clause in their contract and walked away. They also threatened a lawsuit for breach of contract. Then the financial services press got wind of it, and other lenders who’d bought the same software also started to rethink their choices. Leadership panicked, which was understandable.

Because I was there to help the company mature its doc practices, I got sent onsite to find out what had gone wrong and help stop the bleeding. 🩸

Read more

Both are real. Both are useful. Both sound like they arrive at work on time. ⏰

Docs-as-a-Hot-Mess is different.

👉🏾 It isn’t a methodology.

👉🏾 It isn’t a best practice.

👉🏾 It isn’t a movement anyone should claim in public.

It’s simply a label for a condition many organizations already have: docs produced by multiple internal groups, for multiple purposes, with multiple assumptions, and with no governing framework strong enough to reconcile any of it.

The naming convention is really the only thing these categories have in common.

They all start with “Docs-as-,” which gives them a faint air of professionalism, much like putting a blazer on a bad decision. But where Docs-as-Code suggests rigor and Docs-as-Tests suggests verification, Docs-as-a-Hot-Mess describes what happens when nobody’s clearly modeled the logic underneath the content and then acts surprised when an AI answer engine turns that confusion into customer-facing prose.

That’s why we need the term.

A lot of documentation that looked “good enough” in the old world isn’t ready for AI retrieval in the new one. A help topic written for support engineers sits next to an onboarding guide written for customers. A release note we produced assumes context the reader doesn’t have. A troubleshooting article we crafted skips the event that starts the workflow. A procedure we carefully worded says “the user” does something, but never explains which user, in what role, under what conditions, or whether the system was supposed to handle it automatically instead.

That isn’t guidance. That’s improv with screenshots.

And AI answer engines, bless their tireless little hearts, are very good at finding disconnected scraps, flattening their differences, and serving them back as one smooth, confident answer. Which is great when your content is governed, structured, and semantically clear. If it isn’t, the machine doesn’t fix the mess. It scales it. Publicly.

AI Didn’t Create Our Mess, But Turned On The Lights So We Couldn’t Help But See It

A customer asks a simple question. The AI assistant replies in seconds with the confidence of a man explaining olive oil at a dinner party. It has found a setup topic from the help center, a support note meant for internal use, a few release-note fragments, and an onboarding PDF that appears to have been updated during a period of low morale. It blends them into one polished answer. The answer is clear, direct, wrong in at least three ways, and just plausible enough to cause trouble.

This is usually the part where someone says, “Well, the AI hallucinated.”

Sometimes it did. But often it’s doing something worse and far more understandable: it’s retrieving exactly what you gave it.

Read more

That’s where the idea of a content integrity model becomes useful. It isn’t a formal standard with a grand governing body and a tasteful logo. It’s a practical way to think about whether the content feeding AI systems deserves to be trusted in the first place. Put plainly, it asks the questions technical writers should’ve been asking all along: where did this information come from, who verified it, is it still current, does it agree with related content, and can anybody trace how it got approved?

What the Content Integrity Model Actually Means

At heart, the content integrity model (as presented by Rahel Anne Bailie) is less a branded framework than a disciplined habit of mind. It treats content as something that must be trustworthy before it can be useful, especially now that machines are reading, summarizing, and repackaging it for other people. It pushes you to look at content not merely as words arranged into a page, but as an asset with a source, a history, an owner, and consequences.

That matters because AI systems are very good at sounding sure of themselves even when they’re spectacularly wrong. They don’t hesitate and they don’t blush. They don’t bother to stop and say, “This section was last updated five years ago, so perhaps let’s proceed with caution.” They just produce answers with the confidence of a man explaining the health benefits of a supplement he found in a podcast ad.

If our underlying content is weak, generative AI output won’t improve. It’ll just become a smoother, faster delivery mechanism for confusing information.

Why This Matters More Now Than It Did Before

Before AI entered the chat, our not-so-good content mostly stayed where it was. A stale help page remained stale. A contradictory procedure confused only the unlucky few who stumbled upon it. A vague warning sat quietly in the corner, radiating menace (but not doing much until someone tripped over it.) The damage was real, but it was often localized.

AI flips the script. Once machines begin reading our content and turning it into answers, summaries, or guided experiences, our weak source content doesn’t stay politely tucked away. It gets amplified. Contradictions surface faster and gaps become more, well…obvious. Outdated docs get handed to our users as though they just came down from a mountain on stone tablets.

Read more

Content Strategy Is The Part No One Sees — Until It Breaks

Most people think content strategy is about planning what to write. That’s part of it, but it’s not the part that saves us when things go sideways.

Content strategy is the system behind the content — the decisions that determine:

• why something exists

• who it’s for

• how it’s structured

• where it shows up

• and who’s responsible for keeping it accurate over time

It’s what keeps content from becoming a scattered content hairball of “we should probably document that” moments.

It’s easy to spot the absence of content strategy pretty quickly. If our help center includes multiple articles that say almost the same thing, but not quite — chances are good, there’s no formal content strategy in place.

If our documentation includes a procedure that works until step four quietly assumes the user already know something no one bothered to explain to them, content strategy is lacking.

If our customers have to ask, “Which version is correct?” and the honest answer is… “it depends” — a content strategy is maybe, probably, definitely missing in action.

We don’t have a technical writing problem. We have a system problem.

For tech writers, this matters more now than in the past Our job isn’t just about producing clear instructions anymore. It’s about designing information so it holds up across systems, channels, and increasingly, AI-powered machines that read and reuse our content in ways we don’t control.

When content lacks structure and governance, it doesn’t just confuse readers — it confuses the systems trying to interpret it. AI doesn’t fix that. It amplifies it. If your documentation contradicts itself or buries important context, those issues don’t disappear when an AI assistant summarizes the content. They get repackaged into answers that sound confident whether they’re right or not. Research from the BBC has shown that generative AI can misrepresent source material even when it’s trying to summarize it.

That’s where content strategy earns its keep. It’s what makes content consistent enough to trust, structured enough to reuse, and governed enough to maintain. Without it, every new piece of content adds a little more entropy. With it, content starts to behave like infrastructure — something you can build on instead of constantly patch.

A sound content strategy also changes how your work is perceived by others. When there’s no strategy, writing can look like a task anyone could do if they had the time. Writing is just typing, right? How hard can it be?

When there is a strategy, it becomes clear that someone has to think about how information fits together, how it evolves, and how it supports both users and the business.

That someone is usually the tech writer — whether the job description says so or not.

So if content strategy sounds abstract, it’s really not. It’s the difference between content that sort of works today and content that keeps working tomorrow. And in a world where your documentation feeds everything from help portals to AI-generated answers, that difference isn’t academic. It’s operational. 🤠

That optimism isn’t wrong. It’s just usually buried under 47 tabs, three half-read white papers, and a YouTube recommendation engine that thinks “AI hype explainer” is what you needed instead of something you can actually use on Monday morning.

Which brings us to a quieter, more useful corner of the internet.

The Library You May Not Know You Needed

If you spend your days wrangling content — shaping it, fixing it, defending it from well-meaning chaos — you eventually realize something: you don’t just need ideas. You need tested thinking. You need to hear how other teams solved the same mess you’re currently staring at.

That’s what you’ll find on The Content Wrangler channel on BrightTALK isn’t a highlight reel. It’s an archive — and a substantial one.

More than 800 recorded sessions, most of them 60 minutes or so, covering everything from content operations and governance to AI, personalization, structured authoring, and the occasional existential crisis about whether anyone reads the docs.

And unlike the average “thought leadership” content that floats by on LinkedIn, these sessions tend to feature people who’ve actually done the work — and are willing to talk about what didn’t go smoothly along the way.

Subscribe (It’s Free) And Save Yourself The Hunt

You could keep searching for answers one blog post at a time, hoping the algorithm has a moment of clarity. Or you could subscribe (it’s free) and give yourself a reliable place to go when you need ideas that have already survived contact with reality.

Subscribing means you’ll get notified about upcoming sessions, but more importantly, it means you’ll stop starting from scratch every time a new challenge lands on your desk. And if you’ve been in this field long enough, you know how often that happens.

Subscribe. Explore. Steal the good ideas. Avoid the bad ones.

And the next time someone asks, “Has anyone figured this out yet?” you’ll be able to say, “Yes. And I know exactly where to find them.” 🤠

Virtual humans don’t understand our products. They don’t apply sound judgment. They don’t magically clean up our vague, inconsistent, or poorly governed docs. They simply turn our content into answers and deliver those answers with a face, a voice, and far more confidence than your source material may deserve.

That’s the real issue.

The interface may look polished, but the underlying system is still drawing from whatever content you gave it. If your docs are messy, contradictory, or imprecise, the virtual human won’t fix that. It’ll perform it.

For tech writers, that means our jobs are changing in important ways. We’re no longer writing only for people who read what we write. We’re increasingly writing for systems that retrieve, assemble, and speak on our behalf. And those systems don’t handle ambiguity with the grace of a seasoned support rep. They just answer and keep moving.

Watch the clip. Then ask yourself a blunt question: if your docs started talking today, would you trust what they’d say? 🤠

If you’re interested in learning about conversational interfaces, stop by the Emerse.ai website and explore how it works and check out their virtual training library.

There is a particular kind of meeting happening in offices everywhere right now, and it usually begins with someone from leadership saying something cheerful and faintly menacing like, “With AI, we should be able to create documentation much faster.”

This is the sort of sentence that sounds harmless until you realize it is often followed by a silence in which every tech writer in the room is expected to smile politely while their profession is reduced to “person who types words into boxes.”

The implication is hard to miss. If AI can generate sentences, and structured content can feed the machine, then surely the technical writer is now just an expensive hallway monitor for punctuation and product names.

Unfortunately for the people saying this, that is not how any of this works.

Yes, AI can generate language. Quite a lot of it, quickly. It can produce whole fields of prose with the confidence of a man at brunch explaining blockchain to people who did not ask. But language alone isn’t knowledge, structured content alone isn’t meaning, and neither one automatically produces an answer a human being can trust, understand, or use without accidentally setting something expensive on fire.

That is why three unfashionably academic little “-ologies” matter more than ever: ontology, epistemology, and phenomenology.

Yes, I know. It sounds like somebody spilled a philosophy department onto a docs team. Stay with me.

These are not decorative words for LinkedIn people who own too many blazers. These are concepts technical writers need to understand if they want to remain relevant in an AI-powered documentation world. More than that, they are the difference between being seen as someone who “writes help content” and someone who makes AI-delivered knowledge accurate, useful, and safe.

Read more

The lineup features an impressive range of experts, including Sharon Burton, Rob Hanna, Ed Grzetich, Rahel Bailie, Sarah O’Keefe, Katie Williamson Sebkhi, Susan Kraft-Yorke, Anne Malinda, Justyna Hietala, Jason Kaufman, Torsten Machert, Wendy Lewis, Mark Pepper, and Louise Stengard Kristiansen.

Together, these professionals explore everything from AI-powered retrieval and messaging misalignment to traceable knowledge, documentation quality, semantic layers, structured content, localization strategy, and the hidden role metadata plays in helping people find and trust the information they need.

🗓️ [May 6] The History of the History of Women in Technical Communication

Hear untold stories that shaped technical communication as Sharon Burton, content strategist and editor, takes you behind the scenes of her new anthology, Women in Technical Communication (2026 XML Press). Discover how this groundbreaking collection came to life—and why documenting our history matters now more than ever.

Register

🗓️ [May 7] It’s The Content, *#%#*$!

Rob Hanna, CEO and Co-Founder of Precision Content, will dissect the critical role that source material plays in determining whether your AI delivers value or disappointment. Explore the real reasons behind “bad content in, bad content out” and discover practical steps you can take to ensure your AI-generated output meets expectations. You’ll gain actionable insights on how to identify weak points in your existing content pipeline and strategies for transforming flawed inputs into high-quality results.

Register

🗓️ [May 12] Why Documentation Format Matters More Than AI Model

Join Ed Grzetich, Technical Documentation Specialist, as he shares research from over 21,000 integration tests revealing a surprising insight: documentation format impacts AI-generated code quality more than which model you use. You’ll see why the wrong format can cause smaller models to fail completely, while optimized formats empower both advanced and basic AI tools to deliver better results.

Register

🗓️ [May 13] Conversational AI: The Cost of Ignoring Structured Content

Rahel Bailie, Content Solutions Strategist at Content Seriously, and host Sarah O’Keefe, Founder & CEO of Scriptorium Publishing, examine how the intersection of structured content and conversational AI has evolved. They also discuss practical next steps that organizations can take to create a successful AI content strategy.

Register

🗓️ [May 13] How to Get Buy-In, Show Value, and Earn a Seat at the Table

Discover practical strategies for influencing your team and stakeholders—even when you don’t have formal authority. Katie Williamson Sebkhi, Director of UX Content Strategy at Cloudflare, will share proven tactics to help you get buy-in, demonstrate value early, and secure a seat at the table without resorting to endless explanations.

Register

🗓️ [May 14] A $3M Penalty: The Hidden Cost of Bad Technical Documentation

In this session, Susan Kraft-Yorke, Information Architect at Kraft Consulting, reveals how inconsistent document practices can quietly erode client trust, slash revenue, and undermine team productivity—even costing companies millions in preventable penalties.

Register

🗓️ [May 14] Scientific Communication for Technical Writers

Anne Malinda, QA Document Control Specialist at Encoded Therapeutics, will guide you through the shared foundations that unite these fields—clarity, accuracy, structured messaging, and ethical responsibility. Discover where science communicators and technical writers overlap, and pinpoint what truly sets them apart: audience and content, not ability.

Register

🗓️ [May 19] Struggles, Sins, Survival Strategies: The Secret Life of Tech Writers

Join Justyna Hietala, Senior Designer in Technical Documentation at Beamex Oy Ab, for an honest exploration into the frustrations, hidden challenges, and psychological hurdles that come with creating documentation. Step behind the scenes to examine why so many documentation tasks feel invisible—and why coping behaviors often emerge in response to relentless deadlines, shifting reviews, complex tools, and localization demands. Hear candid “confessions” from the trenches and learn how recognizing what you can control, influence, or choose helps reduce frustration and restore focus.

Register

🗓️ [May 19] Destroy Enterprise Knowledge Chaos for Hallucination-Free GenAI

Join Jason Kaufman, CEO & Co-Founder of Zaon Labs, as he reveals why documentation — not just model tuning — holds the key to trustworthy generative AI.
Explore how incomplete, conflicting, or outdated technical content forces AI systems to fabricate answers, propagate obsolete workflows, and confuse end-users. Learn practical methods for identifying documentation gaps, harmonizing information across platforms like SharePoint and wikis, and establishing update cycles that keep your knowledge base current and reliable.

Register

🗓️ [May 20] How To Survive The Four Horsemen of the “AIpocalypse”

Torsten Machert (Congree Language Technologies) and Sarah O’Keefe (Scriptorium Publishing) reveal the four biggest threats undermining quality when you rely on GenAI for content creation, and explore actionable strategies to address these challenges so your output remains consistent, accurate, and unmistakably yours.

Register

🗓️ [May 21] The Semantic Layer: A Hidden Capability That Makes Data Useful

Join Wendy Lewis, Knowledge Engineer at UKG and datatomato, as she unpacks the role of the semantic (or knowledge) layer in transforming scattered info into actionable insights. Explore what a semantic layer is, why it matters, and how it works to align language, reduce ambiguity, and connect teams across your organization.

Register

🗓️ [May 21] Best Practices For Tech Writers Moving To Structured Content

Join Mark Pepper, Principal Consultant at Crimson Sage Softworks Incorporated, as he demonstrates how to conduct effective content audits that reveal what you have — and what you need. Discover how to design a taxonomy tailored to your business goals and map it directly to metadata, ensuring your content is organized, discoverable, and ready for reuse.

Register

🗓️ [May 28] Setting Up a Localization Strategy For Technical Documentation

Join Louise Stengard Kristiansen, Globalization Strategist at ProStrategy | House of Localization, as she reveals why so many localization efforts fail before they even begin and how you can avoid common pitfalls. You’ll learn how to assess your current localization maturity, design effective workflows, select the right translation management system (TMS), and implement governance frameworks that support quality and consistency.

Register

In his paper, “Programming a Computer for Playing Chess,” Shannon wasn’t trying to build a novelty act for brainy cocktail parties. He chose chess because it forced a machine to face the sort of problem machines are facing now: too many possible moves, not enough time to calculate everything, and no choice but to make a judgment anyway.

That should sound familiar to anyone watching generative AI answer questions about our products, policies, processes, or software configuration with the calm confidence of a man giving directions while standing in the wrong city.

“Tolerably Good” Was the Goal

One of the most useful things Shannon did was lower the temperature. He didn’t say machines had to play perfect chess. He said they had to play “tolerably good” chess.

He understood that perfect performance wasn’t realistic. The problem space was too large. The machines of the day couldn’t analyze every possible continuation. So the real challenge wasn’t perfection. It was usefulness.

Could the machine make choices that were good enough to hold up under normal conditions?

That’s still the question with AI now, even though people keep dressing it up in more expensive language. We don’t actually need AI to be magical. We need it to be useful without wandering off into fiction. We need it to stop sounding certain when it should be saying, “I’m not entirely sure, and frankly neither should you be.”

The trouble is that “good enough” means very different things to different people depending on the task. If AI drafts a mediocre summary of a meeting, nobody faints. If it gives our prospects or customers the wrong setup instruction, skips a prerequisite, or blends two different product versions into one smooth paragraph of nonsense, suddenly “tolerably good” starts looking like a phrase that should come with a lawyer.

Related: Generative AI Lawsuits Timeline (updated weekly)

The Machine Doesn’t Know — It Guesses, Confidently

Shannon understood something that people still resist because it ruins the fantasy. A machine doesn’t always arrive at the answer by knowing the answer. Often, it arrives there by evaluating possibilities and choosing what seems best according to the signals it has.

Modern AI works pretty much the same way. It doesn’t know your product the way an experienced support agent knows it. It doesn’t understand your docs the way a careful reader does. It doesn’t stop, scratch its chin, and ask whether two similar procedures might apply to different user roles. It predicts. It estimates. It assembles a response that looks like the kind of thing a good answer would look like.

When the signals are strong, this can feel impressive. When the signals are weak, missing, or inconsistent, it still produces something. That’s where the trouble starts. The output may sound measured and complete, which is often the first sign you should worry.

Coherence Isn’t the Same Thing as Accuracy

People often treat fluent, easy-to-process language as a cue that something is true. Psychologists call this processing fluency, and a large body of research ties it to truth judgments. In a classic study, statements that were simply easier to read were more likely to be judged true. The authors’ conclusion was blunt: “perceptual fluency affects judgments of truth.”

If the answer flows nicely, uses the correct nouns, and doesn’t visibly burst into flames, many assume the machine must have understood what it was talking about.

But Shannon pushes against that kind of wishful thinking. He knew the system would often rely on approximation. In chess, that means the machine makes a reasonable move without proving it’s the best move. In genAI, the machine doesn’t arrive at an answer by checking whether it’s true in the way a human expert might. It produces a response by predicting what a good answer is likely to sound like, one LLM token at a time. That’s why AI-generated output can read as polished, measured, and entirely sensible while still being wrong in ways that matter.

That distinction matters a lot for tech writers. A response can be coherent and still be useless. It can be elegant and still omit the thing that mattered most. It can sound like it belongs in the product manual while quietly steering the reader into a ditch.

That’s why the current conversation about AI so often feels silly. People keep asking whether the prose sounds natural. That’s the least interesting part. The dangerous part is that the prose sounds natural even when the reasoning underneath it is shaky enough to qualify as decorative.

The Real Issue Isn’t Intelligence — It’s Signal Quality

Shannon’s chess-playing computer needed a way to judge positions — basically, how the board was set up at that moment — when it couldn’t calculate everything. In other words, it needed signals that helped it decide what choices looked stronger, weaker, safer, riskier, more promising.

That should sound very familiar to tech writers working with structured content, metadata, taxonomy, ontology, versioning, or workflow status. Because in modern AI systems, those are the signals.

They tell the model, or the retrieval layer feeding the model, what content applies to which audience, which version is current, which procedure belongs to which product version, which warnings matter, and which info has been reviewed and approved by someone who’d prefer not to be sued.

Without those signals, the machine doesn’t throw up its hands and refuse to answer. That would be far too responsible. It keeps going. It infers. It blends. It smooths over cumbersome gaps. It performs the digital equivalent of a person nodding along in a conversation they stopped understanding eight minutes ago.

That’s why weak content governance keeps showing up as an AI problem. It isn’t always an AI problem. Quite often it’s a problem with our content that AI exposes.

Why Tech Writers Are Suddenly More Important

This is where the tech writer’s job gets more interesting, and perhaps a bit more annoying. 🤬 It used to be enough for us to write clearly for humans. Homo sapiens are patient in ways machines aren’t. We notice contradictions, sense when context is missing, and when it is, we infer from surrounding material. We pause when something feels off.

AI doesn’t do that. Nope. It doesn’t slow down because a sentence feels off. It doesn’t ask whether the warning in one document conflicts with caution advice in another. It doesn’t notice that the troubleshooting article applies only to Version 11 while the setup instructions were written for Version 9 and last updated when everyone still thought QR codes were futuristic.

So now our job is larger. We have to make context more explicit, surface conditions, boundaries, prerequisites, exceptions, and applicability in our content. And, we have to help the system distinguish between general guidance and situation-specific instruction.

It’s not glamorous, but it is important. The machine can only work with what the content provides.

We’re Not Dealing With A New Problem

The reason Shannon’s work still matters some 75+ years later is that he described the shape of the problem long before anyone had a chatbot to blame. A machine facing a large decision space can’t calculate everything. It has to use approximations (see video below to learn more). The quality of its behavior depends on the quality of the signals guiding those approximations. That was true in 1950. It’s true now.

What changed is that the machine no longer sits quietly in the corner playing chess. Now it drafts documents, answers support questions, summarizes policy, and speaks to customers in complete sentences (increasingly through human-like interfaces called digital avatars or virtual humans). That makes the underlying problem more visible, but it doesn’t make it new.

We keep pretending we’ve stumbled into some unprecedented crisis of machine unreliability. In truth, we’ve mostly put a friendly conversational interface on top of an old computational reality and then acted stunned when it behaved like a machine making approximations under constraint.

In fact, it may be useful for us to stop saying that AI systems hallucinate when they actually approximate.

Claude Shannon would not be surprised. He might be amused, though. 😆

We Should Stop Pretending We Don’t Know

If there’s a lesson here for us, it’s not that AI is broken or that machines are foolish or that prompts are the secret to salvation. It’s that reliability has always depended on bounded problems, explicit signals, and sensible expectations.

AI doesn’t need to be brilliant. It needs to be trustworthy within clear limits. That means the content behind it — our content — has to do more than read well. It has to signal what applies, what doesn’t, what changed, what matters, and what should never be blended into a paragraph just because the model found it statistically convenient.

Shannon knew that a machine making decisions under uncertainty would only ever be as good as the method guiding its choices. We’re still learning that lesson now, only with better branding and much more overconfidence. 🤠

Once you’re ready to learn more about putting Claude to work for you, consider taking this free online course, Claude 101.

Their online courses walk through the fundamentals with clarity. They also include advice on working with large language models (LLMs). If you follow their guidance, your writing will likely improve. Your docs should become easier to read; your intent harder to misinterpret.

It feels like progress. And it is. But only up to a point.

The Subtle Shift No One Can Ignore

Tech docs have a new reader. Not a person skimming for answers while jumping between online meetings (and while distracted by a steady stream of Slack notifications) but a system that retrieves, assembles, and delivers those answers on demand.

The system does not read the way humans do. Instead, it predicts, reconstructs, and responds. It takes what you wrote and turns it into something else.

Google’s guidance helps us with that process. Clear sentences and logical and consistent content organization give the model something to work with. But clarity alone does not determine what the model produces.

That is where the gap begins.

When The Model Fills In The Blanks

Large language models are good at producing language that sounds correct. They’re less reliable when the source material is incomplete or inconsistent.

Unlike humans, when context is missing, the model does not pause and ask us for clarification. Instead, it proceeds full steam ahead.

Researchers at Stanford University have shown that models can generate citations that look real but do not exist. The titles and authors seem credible at first glance. The problem is the sources are fabricated, and far too often, completely detached from reality.

Other research shows that LLMs can explain what code does while missing why it was designed that way, because the reasons why weren’t captured in the docs to begin with.

Reporting from The New York Times has identified cases where AI assistants combine outdated and current info into a single answer without signaling the conflict.

These aren’t edge cases. They’re predictable outcomes. The model isn’t inventing problems. It’s exposing the gaps.

What Clear Writing Can And Cannot Do

I think Google’s guidance on clear sentences and organizing content is fairly solid.

• Clarity reduces ambiguity ✅

• Structure improves comprehension ✅

We know these things are required to produce usable docs. But, they’re not enough if we’re hoping they’ll help us obtain reliable AI output.

A polished sentence may still lack context. A neatly structured page may still leave out key constraints. And a clear explanation may apply only to one version, audience, or configuration without ever saying so.

LLMs do not know what we meant to include, but didn’t. It only works with what we provide it.

The Context That Never Made It Into The Content

This is where Google’s guidance starts to show its limits. The courses offered focus on how to write. They do not address how to encode meaning in a way machines can reliably interpret.

Consider metadata

Google tells us to define our audience, but not to encode that audience in a way that our systems can recognize and act upon.

Without metadata, important differences between user roles, product versions, and situations stay hidden. The model may blend them together into one answer that sounds correct but doesn’t really fit any of them.

Consider taxonomy

Google encourages clear headings (a solid suggestion) but does not address controlled vocabulary or semantic consistency.

People usually know when different words are just different outfits on the same idea. Dog, pooch, hound, pup, mutt — no one needs a crisis counselor to sort that out. Context does the work.

LLMs do not always manage that trick gracefully. Sometimes they treat minor wording changes as if the universe has shifted on its axis. Other times they blur important differences and act as though related terms all belong in one big semantic junk drawer.

Consider provenance

Google says to review AI output, but it doesn’t explain how to check where the source content came from, whether it is still valid, or whether anyone approved it. Without that information, old or unverified content can show up next to current guidance with no warning that it may be risky.

Consider content models

Google discusses organization at the document level, but not structure at the semantic level. A content model defines what types of content exist, what components they contain, and how those components relate. Without it, content remains a collection of pages. With it, content becomes a system that supports consistent interpretation.

A Familiar Scenario To Illustrate This Challenge

Imagine a doc set that includes a setup guide that someone wrote two years ago, a troubleshooting article you updated yesterday, and a release note explaining that the old instructions no longer work after a recent update.

Individually, each doc is clear and well written. None of them share consistent metadata, terminology, or version context.

Your user asks an AI assistant how to set up a feature. The assistant pulls info from all three documents and combines it into an answer that sounds clear and complete. But the answer is wrong for that user’s version, setup, or situation.

The problem isn’t that one document was badly written. The problem is that the content didn’t include the structure, labels, and context the AI needed to tell what applied and what didn’t.

Real-world example: [It] kept telling me that that I had to use this one envar to put the app in debug mode. But it wasn't working at all. So eventually I get around to looking deeper into it and it turns out that this method was used 2 versions prior to the current version. — GITHub post Very outdated answers and wrong suggestions everywhere

What Google Teaches Us — And What It Leaves for Us To Learn On Our Own

Google’s courses establish a baseline. They teach writers to produce content that is clear, structured, and easier to process. That baseline matters. Without it, nothing else works. Period.

But it fails to address the factors that determine whether AI-generated answers are accurate, consistent, and trustworthy. Those factors include structure beyond formatting, context beyond prose, and governance beyond editorial review.

They include decisions about how meaning is represented, how relationships are defined, and how trust is established. That work is not covered in the courses.

The Work That Now Defines Our Role

We tech writers have always been responsible for clarity. Now we’re also responsible for context. That includes making intent explicit, encoding meaning in ways machines can interpret, and ensuring that our content can be trusted when it’s retrieved, combined, and delivered outside its original form.

This isn’t a shift away from writing. It’s an expansion of what our writing must accomplish.

The sentence still matters. But the system that surrounds it matters more.

The Difference Between Readable Content And Trustworthy Content

Google will help you write docs that AI can read. It won’t help you create docs that AI can trust. And as AI takes on a larger role in delivering answers, that distinction moves from academic to operational. Those of us that recognize this distinction will design content accordingly. The rest of us will continue to wonder why their docs sound right but behave unpredictably. 🤠