Glossary
Short definitions for terms that come up often in these posts.
General terms
Agentic workflow
A sequence of tasks carried out by an AI agent that plans, calls tools, and checks its own output with limited human intervention, as opposed to a single prompt-response exchange.
Docs as code
The practice of treating documentation like source code: stored in version control, reviewed through pull requests, and built through the same pipelines as software.
LLM (large language model)
A machine learning model trained on large amounts of text that generates or transforms language, used here as shorthand for tools like Claude, GPT, or Gemini.
MCP (Model Context Protocol)
An open standard that lets LLMs call external tools and read external data sources through a common interface, rather than each integration being built from scratch.
RAG (retrieval-augmented generation)
A technique where an LLM’s answer is grounded by first retrieving relevant passages from a document store, then generating a response based on those passages instead of the model’s training data alone.
Tech writer
Shorthand for technical writer: someone who researches, structures, and writes documentation, often bridging engineering, product, and support teams.
Vibe coding
Writing software by iterating on prompts to an AI coding assistant rather than writing code by hand, often with limited review of the generated output.
Coined on this blog
Terms and frameworks introduced (or adapted and renamed) in these posts, defined the way they were defined there.
Devling
A technical writer who has grown proficient enough with code and developer tools to act as a trusted coding associate on an engineering team — not a developer, but no longer just a spectator either. Coined as “young developer, developer spawnling” in Coding as a tech writer.
Product truth
The tension and nuance behind a mature feature — the support tickets, customer feedback, and sense of unfinishedness that shape a product but rarely make it into a spec. Pictured as concentric circles, from the outermost (what exists and where) to the innermost (why), in Circles of Product Truth.
Documentation theater
The act of creating documentation for its own sake — so a box can be checked, an issue closed, or a project completed — rather than to address a real need. Named after developer Annie Mueller’s parody of tutorials in When docs become performance art, everybody loses, where it’s also noted the author once called the same idea cargo-cult documentation.
Ferri Paradox
“Any document describing a system is necessarily inaccurate.” Offered, tongue-in-cheek, as the reason to write docs quickly rather than chase an unreachable completeness, in How I write docs quickly.
Not-viable-enough docs (NVE docs)
Documentation that falls short of even “minimum viable” — usually a symptom of underlying product issues rather than a writing problem. Sometimes the only fix available is “palliative docs care”: content that helps users cope with a flawed reality rather than fixing it. Introduced in How I write docs quickly.
do11y (documentation observability)
Tracking how docs and product usage interact — for example, whether a user who hit an error, read the linked doc, and successfully retried their API call should count as a doc’s success. Modeled on software observability (o11y) and coined in a conversation with Bob Watson, in Docs observability, or measuring docs inside a product-docs system.
The Columbo Technique
An approach to extracting information from subject-matter experts modeled on Lieutenant Columbo: playing genially unassuming so SMEs correct, elaborate on, and ultimately confirm the details a document needs, rather than simply answering direct questions. See The Columbo Technique for Technical Writers.
The Seven-Action Documentation Model
A framework for structuring docs around what users are trying to accomplish rather than what content type to produce: Appraise (Discern), Understand (Learn), Explore (Discover), Practice (Train), Remember (Recall), Develop (Integrate), and Troubleshoot (Solve). See The Seven-Action Documentation model.
Docs Hierarchy of Priorities
A Maslow-style pyramid of what a documentation effort needs before the next level becomes possible, starting with an organization simply recognizing that docs — and someone accountable for them — are needed at all. See Docs Hierarchy of Priorities: A Proposal.
Context curator
A technical writer who orchestrates and executes a content strategy around both human and AI needs — or AI needs alone — treating context, not generic “content,” as the unit of value that AI systems actually draw on. From AI must RTFM: Why technical writers are becoming context curators.
Peripheral professionals
Humanists and artists — writers included — who bridge the gap between the technical core of software and the humans using it, and whose jobs are often first on the chopping block when AI reshapes what a company treats as essential. From Technical writing predictions for 2025.
Tools slop
The flood of narrow, disposable tools that AI coding assistants make trivial to spin up and tempting to over-promote, lacking the reach, sociality, and finish of a tool built to last beyond its own creator. See Most vibe-coded tools are not for you.
Impersonaid
A docs user simulator the author built: point it at a document, pick a persona, and hold a conversation about the content to see where a reader gets stuck — turning an argument about clarity into a reproducible transcript. From Conjuring digital companions: How I’m thinking better through AI.
Roles are verbs, not nouns
A model for structuring a documentation team around four poles — Product Vision, Knowledge Design, Engineering Depth, and Delivery Strategy — where people move fluidly between them instead of being locked into fixed job titles. From In the team of the future, roles are verbs, not nouns.
The four modes of AI-augmented writing
A framework for where AI fits into a technical writer’s workflow, from most to least hands-on: the watercooler conversation (chat-based Q&A), the whisperer (inline suggestions), the wordsmith (shaping drafts from context), and the assembly line (agentic checks, rewrites, and tests). See The four modes of AI-augmented technical writing.
Documentation bestiary
A satirical taxonomy of documentation content types cast as medieval beasts: the Releasaurius (release notes), Realisticasius (scenarios), Examplanatii (examples), Solutionarius (troubleshooting), Optimarius (best practices), and Interfacilus (UX writing). See Bestiary: On Doc Types and Other Animals.