--- title: 'Glossary' date: 2026-07-01 lastmod: 2026-07-01 last_updated: 2026-07-01 doc_version: '2026-07-01' description: 'Definitions for the technical writing and AI jargon used across this blog, including terms coined on this blog.' canonical: https://passo.uno/glossary/ --- # 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](https://passo.uno/tech-writer-learn-to-code/). ### 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](https://passo.uno/circles-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](https://passo.uno/documentation-theater-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](https://passo.uno/how-write-tech-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](https://passo.uno/how-write-tech-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](https://passo.uno/docs-observability-do11y/). ### 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](https://passo.uno/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](https://passo.uno/seven-action-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](https://passo.uno/docs-hierarchy-of-needs/). ### 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](https://passo.uno/from-tech-writers-to-ai-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](https://passo.uno/tech-writing-predictions-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](https://passo.uno/tools-slop-is-a-problem/). ### 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](https://passo.uno/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](https://passo.uno/docs-team-of-the-future/). ### 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](https://passo.uno/four-modes-ai-augmented-tech-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](https://passo.uno/docs-bestiary-taxonomy/). --- Canonical HTML version: https://passo.uno/glossary/ ## Sitemap - [Full post index](https://passo.uno/sitemap.md) - [llms.txt](https://passo.uno/llms.txt)