AI-enabled information systems for technical writers

Bounding means that the limits of the system’s knowledge are decided before the system answers — not discovered when it answers wrongly.

Technical writers must ask:

• Which products, versions and variants does the system cover?
• Which questions may it answer, and which must it hand over to a person?
• Which knowledge is safety-critical and may only be passed on unchanged?
• What must the system never derive, estimate or combine on its own?
• How does the system say that it does not know?
• Who validates answers in the areas where the boundary is narrow?

A machine that has no boundary fills every gap. It answers questions for products it does not cover, combines values from different variants and turns uncertainty into confident sentences.

A boundary is a documentation decision. It names the scope, the content that may only be reproduced as it stands — warnings, limits, safety-related values — and the points where the system must stop and refer to a person or to the instructions for use.

For documentation this means: the scope and the limits of the knowledge are written down as carefully as the knowledge itself.

• Not knowing is a valid answer.
• A boundary is not a restriction of quality. It is part of it.
• Safety information is reproduced, not paraphrased.

A system that does not know where its knowledge ends will not stop there.

Anchoring means that every answer, every page and every derived output can be traced to one governed source that remains the authority.

Technical writers must ask:

• Where does the authoritative version of this knowledge live?
• Who owns it, and who may change it?
• Which outputs are derived from it: pages, PDFs, answers, product texts?
• What happens to the derived outputs when the source changes?
• Is a generated text a source, or only a proposal for one?
• Which content may the machine use: released only, or also drafts?

In many organisations the same knowledge exists in several places: the manual, the training slides, the website, the service portal and now the answers of an AI assistant. Each copy drifts away from the others.

Anchoring turns the relationship around. The governed source is the authority, and everything else is derived from it and reconciled with it when the source changes. Spec-driven software development describes the same idea for code: the code serves the specification. In documentation, the answer serves the source.

For documentation this means: the source stays the source for the whole life of the product. AI output is derived from it — it never quietly replaces it.

• A generated text is not a source.
• A copy is not a version.
• Released is not the same as available.

The answer serves the source.

Modelling meaning means that what a term stands for, how it relates to other terms and which constraints apply are written down — not left to the reader’s or the machine’s guess.

Technical writers must ask:

• Does every important concept have one preferred term and a definition?
• Which synonyms, abbreviations and outdated names point to the same concept?
• Which concept is broader, narrower or only related?
• Which constraints apply: valid only in this mode, only with this component, never together?
• Which questions must the model be able to answer?
• Is the meaning stored where the machine can read it, or only in a style guide?

People resolve ambiguity with context and experience. A machine resolves it statistically. If one thing has three names, the system may treat it as three things. If two things share a name, it may merge them.

Semantic structure gives the system something to hold on to: controlled terminology, explicit relations, taxonomies, ontologies. The more explicit the meaning, the less the system has to guess. I call this semantic gravity — the stronger the structure, the closer the answers stay to what is meant.

For documentation this means: terminology work, relations and constraints are not an extra for the localisation department. They are the meaning architecture the machine answers from.

• A term is not a word. It is a concept with a name.
• A synonym list is not a model.
• What is implicit for people is invisible for a machine.

The stronger the meaning structure, the less the machine has to guess.

Building units means that knowledge is divided into units that each serve one purpose and can be understood, retrieved and reused on their own.

Technical writers must ask:

• What is the one purpose of this unit?
• Can it be understood without the page before it?
• Does it state its own context: product, task, audience?
• Is the warning part of the unit it belongs to, or somewhere else on the page?
• Would the unit still make sense if a machine cut it out and showed it alone?
• Is the unit too large to be retrieved precisely, or too small to be understood?

Readers who arrive from search land in the middle of the documentation. Mark Baker described this in Every Page is Page One: every page must work as the first page. The machine, when it retrieves a passage, is the most extreme of these readers. It sees only the unit, nothing around it.

A unit that relies on the previous chapter, a warning placed two pages earlier or a table without its heading becomes a wrong answer once it is retrieved alone. Topic-based structures such as DITA and the information units of iiRDS were built for reuse; the same discipline makes units usable for retrieval.

For documentation this means: the unit that a person reads alone and the unit that a machine retrieves alone are the same unit. It must carry its context and its safety information with it.

• A chunk is not a topic unless someone designed it as one.
• A unit without context is a fragment.
• A warning outside its unit protects no one who sees only the unit.

Every unit is page one — for people and for machines.

Describing context means that every unit carries the metadata a system needs to select it for the right product, variant, role and situation.

Technical writers must ask:

• For which product, variant and version does this unit apply?
• For which role: operator, service technician, installer, developer?
• For which lifecycle phase and operating mode?
• What kind of information is it: concept, task, reference, warning, troubleshooting?
• Which metadata are mandatory, and who checks them?
• Do the metadata use the same vocabulary as the product data?

A human reader can often see from the cover, the layout or the product photo whether a page applies. The machine cannot. It selects by what is written down — and where nothing is written down, it selects by similarity.

Metadata turn validity into something a machine can check. Standards such as iiRDS describe product, functional and administrative metadata for exactly this purpose: to deliver the right information for the right product and situation.

For documentation this means: metadata are not filing information for the writer. They are the context the system uses to choose — and to leave out.

• Similar is not applicable.
• Missing metadata is a decision, too — made by the machine.
• Validity is content, not administration.

What the metadata do not say, the machine will guess.

Connecting to the product means that documentation units are tied to the real elements of the product — its states, fault codes, components, interfaces and configurations — by stable identifiers.

Technical writers must ask:

• Which fault code, state or component does this unit belong to?
• Is that link stored as an identifier, or only mentioned in the text?
• Where does the product data come from: engineering, PLM, the control software?
• What happens to the documentation when the product changes?
• Can the system tell which configuration the reader actually has?
• Who is told when a product change affects a unit?

Documentation describes the product in communicable form. When it is connected to the product’s own data, the machine can answer from the state the product is in, the fault code it shows and the configuration it has — not from a general description.

A digital twin of the information environment, as Michael Iantosca and others describe it, connects documentation, terminology and product structure in one model. The connection works only as far as the identifiers are stable and shared.

For documentation this means: the link between a unit and the product is maintained like the content. A broken link produces an answer for a product that does not exist.

• A fault code in the text is not a link.
• Product reality changes before the documentation does.
• A shared identifier is worth more than a long description.

Documentation that is connected to the product can answer for the product in front of the reader.

Retrieving and adapting means that the system selects the right units for a question, answers only from them and adapts the answer to role, state, task and risk — without dropping what must stay.

Technical writers must ask:

• Which units must the system find for this question?
• Does the answer stay with what the units say, or does it add to them?
• What may change with the role: depth, order, terminology?
• What must never change: warnings, limits, prerequisites, stop criteria?
• How does the answer show its source and its validity?
• What happens when the risk level of the task rises?

Retrieval-augmented generation lets the machine answer from the documentation instead of from what its language model happens to contain. Grounding means that the answer stays with the retrieved sources. Both work only as well as the units, the meaning and the context behind them.

Adaptive output is where AI-enabled documentation becomes visible to the reader: the answer for the service technician differs from the answer for the operator. Adaptation is a documentation decision. It needs rules for what may be shortened, reordered or explained — and safety overrides that fail closed: when in doubt, the complete safety information is shown, never less.

For documentation this means: the writer decides in advance what an answer may adapt and what it must carry unchanged. Adaptation never leaves out safety-related or required information for use.

• Relevant is not complete.
• Adapted is not shortened.
• A safety override that fails open is not an override.

An adapted answer is only as safe as the rules for what it must not change.

Tracing means that the path from an answer back to the unit, the version, the review and the product requirement it rests on stays visible and verifiable.

Technical writers must ask:

• Which units and versions did this answer use?
• Who reviewed this unit, and when?
• Which product requirement, change or test does it belong to?
• Which parts of the product have no documentation yet?
• Which units are documented but no longer match the product?
• Can an auditor reconstruct what the system answered at a given time?

Traceability is familiar from requirements engineering: from requirement to design to test. In spec-driven software development it is extended to the code — each use case shows whether implementing code and tests exist. Documentation needs the same line from product change to unit to answer.

Tracing makes two kinds of gaps visible: knowledge the product has but the documentation does not, and documentation the product no longer matches. Both are invisible in a single answer.

For documentation this means: references, versions and review records are part of the information system, not an archive beside it. An answer that cannot be traced cannot be corrected.

• Plausible is not verified.
• A source list is not traceability.
• Coverage is a question, not an assumption.

What can be traced can be checked. What can be checked can be trusted.

Governing means that rules, roles and approvals decide what the machine may propose, what people must review and what reaches the reader.

Technical writers must ask:

• Which outputs may the system produce on its own, and which only as a proposal?
• What is never allowed: changing warnings, inventing values, answering beyond the scope?
• Who reviews a proposal, and by which criteria?
• Who may release it, and how is the release recorded?
• How are errors reported, corrected and fed back?
• Which decisions remain with people whatever the system can do?

AI makes it easy to produce text. It does not make it easy to take responsibility for it. Governance keeps the two together: AI output arrives as a proposal, a person reviews it against the source and the rules, and only an approved change becomes part of the source.

The same principle appears in spec-driven software development, where generated code arrives as a pull request that someone reviews and merges. In documentation, the review covers content, terminology, metadata and safety information.

For documentation this means: the writer defines the rules the system follows and remains the one who approves. Governance supports human oversight; it never replaces the manufacturer’s risk assessment or the responsibility for the information for use.

• A proposal is not a decision.
• Fast output is not fast approval.
• Responsibility does not move to the model.

AI may propose. People decide.

Evolving means that the knowledge model is improved from evidence of how it is used — in a governed loop, never by silent self-modification.

Technical writers must ask:

• Which questions does the system receive that the model cannot express?
• Which concepts or relations are missing, and how do we notice?
• Who proposes a change to the model, and in which form?
• How do we show that the change makes answers better, not only different?
• Who promotes a validated change into the governed model?
• How do we keep the governed core stable while the model grows?

In my article “EvoOntology vs. iiRDS” I described the tension between carefully governed ontologies and models that evolve from experience. Michael Iantosca took this further in the white paper “From knowledge graphs to adaptive semantics”: inference extends what the knowledge graph knows; ontology evolution extends what it can represent.

The paper presents an adaptive semantic feedback loop around the governed core: learn how AI agents use the model, detect gaps it cannot express, propose a new concept, relation or rule, evaluate whether answers improve, and govern by promoting validated changes into the enterprise model. The AI agent becomes a source of evidence, not an editor of the model.

For documentation this means: the model is never finished, and it never changes itself. Gaps become proposals, proposals become decisions, and only decisions change the governed core.

• Evolution is not drift.
• A gap is evidence, not a failure.
• The governed core grows by decision, not by accident.

A knowledge model that learns under governance gets better without losing trust.