"The future of enterprise technical documentation will not belong to organizations that merely generate more content with AI. It will belong to organizations that build semantically governed, operationally validated, and explainable knowledge ecosystems around AI generation.

Large language models are remarkable language-generation systems, but they remain fundamentally probabilistic, and no amount of vector-based probabilistic augmentation, recursive prompt gymnastics, or trillions of additional parameters magically transforms probabilistic token prediction into deterministic operational intelligence — regardless of what the AI snake-oil salesmen on LinkedIn insist between inspirational rocket-ship emojis. LLMs predict statistically likely outputs. They do not inherently understand operational correctness, governance policy, procedural safety, rollback integrity, regulatory compliance, or whether the “helpful” configuration change they just suggested is going to quietly detonate a production Kubernetes cluster at 2:13 a.m. while everyone is asleep and the on-call engineer is reconsidering their career choices.

That is not a moral failure of AI. It is simply the architectural reality of probabilistic systems pretending to perform deterministic operational reasoning often enough to make people dangerously optimistic.

This is precisely why deterministic models and governance matter.

Structured content, semantic markup, metadata governance, provenance tracking, DOM Graph RAG, iiRDS frameworks, knowledge graphs, RDF and OWL ontologies, context graphs, deterministic inference engines, orchestration platforms, Docs-as-Tests automation, and runtime observability together create something fundamentally different from prompt engineering. They create governed operational ecosystems capable of supporting trustworthy enterprise AI at scale."

https://medium.com/@nc_mike/deterministic-and-agentic-ai-architectures-for-technical-documentation-3fb2956a1334

#AI #GenerativeAI #DocsAsTests #LLMs #AgenticAI #DITAXML #AIAgents #TechnicalWriting #SoftwareDocumentation

"Technical writers have survived technological changes for decades. The advent of AI shouldn’t be different. If this reminds you of Realpolitik, you wouldn’t be wrong: LLM-generated contributions are already happening and there’s no going back. Writing an AI & Docs policy means taking full ownership of the process and reminding folks that documentation requires expertise and has high quality standards. That kind of strategic thinking is what will keep us afloat.

What I would find dangerous for technical writing right now is sitting on our hands, hoping that someone else sets the rules of the game. We can’t pretend that this will sort it out on its own, so start drafting your policy, your stance, and iterate as you learn more. Your policy will also act as a reminder of the value you bring to the organization. Worst case scenario, it’ll open useful internal debates that you might have missed otherwise. We need that depth."

https://passo.uno/ai-docs-policy-contributions/

#AI #GenerativeAI #AIPolicy #TechnicalWriting #SoftwareDocumentation #DocsAsTests #LLMs

#TechnicalWriting #SoftwareDocumentation #SoftwareTesting #DocsAsTests #APIDocumentation: "I wrote last month about how to test docs code examples. Now, let’s look at what to test in docs code examples.

- Test the claims you make in docs
- Use the APIs you document
- Demonstrate common usage patterns and best practices
- Figure out where you can safely omit boilerplate code

There are also a couple of “don’ts” when writing and testing docs code examples:

- Don’t show “wrong” code
- Don’t recreate comprehensive engineering tests for edge cases"

https://dacharycarey.com/2024/02/11/what-to-test-in-docs-code-examples/

#SoftwareDocumentation #DocsAsTests #DocsAsCode #APIDocumentation #TechnicalWriting #SoftwareTesting #SoftwareDevelopment: "I initially developed and implemented Docs as Tests at Skyflow, a startup that moves fast and releases features and updates even faster than I’d experienced before. I searched for tools to help me manage the pace of changes: there were style linters, API testers, and engineering-focused testing tools, but there wasn’t anything to easily help me validate the product descriptions or procedures in my docs. So I built my own, and Doc Detective was born. Doc Detective is a toolkit that parses docs and runs tests (like stepping through procedures) directly against UIs and APIs. It’s designed so non-engineers can use it individually, but teams can also collaborate. When I set it up to test my docs, it caught issues that I had no idea of. It was a game-changer.

But Doc Detective is just a tool (a good one, I like to think!), and no tool solves every problem. I wanted to find a way to apply my learnings to the broader docs community, and I came up with Docs as Tests—a strategy that can be implemented with whichever tools you choose to validate your docs. I’m excited to share my learnings with you and to learn from you as well."

https://www.docsastests.com/docs-as-tests/concept/2024/01/09/intro-docs-as-tests.html