# AI TechDoc Knowledge > Reference content from knowledge.aitechdoc.world on AI regulation, technical documentation and semantic systems. The site holds 16 sourced glossaries with 2,444 terms — AI concepts and brands (the basis of an AI learning path), information architecture, ontology and iiRDS, DITA 1.3, the EU AI Act compared with AI rules in the USA, Canada and China, machine safety, functional safety and systems engineering, safety documentation and industrial cybersecurity, the EU Digital Product Passport and the omnibus packages, MedTech and pharma regulation (MDR, IVDR, ISO standards, GxP, FDA) and industrial automation (PLC programming, components, sensors and drives, robotics and manufacturing operations, industrial communication and OT security, automation software engineering), most automation terms with their German equivalent — and, in a separate glossary pool (The art of thinking), philosophy, reasoning and mental models. It adds 15 in-depth wiki guides to the iiRDS core concepts, an encyclopedia of formal reference articles (starting with the four types of software development kit and how they interoperate), knowledge vaults with linked notes and an AI learning path for technical writers, technical marketers, technical project managers and developers. The site is written in US English; the pages outside the glossaries, the wiki and the vaults are mirrored in British English (/uk) and German (/de). Glossary, encyclopedia, wiki and vault pages are US English only. Every glossary definition in one file: https://knowledge.aitechdoc.world/llms-full.txt ## Pages - [Glossaries](https://knowledge.aitechdoc.world/glossary): Sourced definitions with examples, comparisons and SKOS relations, grouped into 16 glossaries - [The art of thinking](https://knowledge.aitechdoc.world/art-of-thinking): A separate glossary pool for philosophy, reasoning, mental models and cognitive psychology — where thinking methods come from, how they were adapted and what research says about how people think with information; not norms or requirements - [Glossary Updates](https://knowledge.aitechdoc.world/glossary-updates): Numbered issues listing the terms added to each glossary, newest first - [Norms and regulations index](https://knowledge.aitechdoc.world/norms-and-regulations): Every standard and legal act the glossary entries cite, grouped by type, with the entries that cite it - [Wiki](https://knowledge.aitechdoc.world/wiki): In-depth evergreen guides with definitions, practice examples, RDF snippets and FAQs - [Context cards](https://knowledge.aitechdoc.world/context-cards): Self-contained explanations of the technical contexts behind AI and automation news (one question, a direct answer, key points, FAQ, linked glossary terms), in US English, British English (https://knowledge.aitechdoc.world/uk/context-cards) and German (https://knowledge.aitechdoc.world/de/context-cards) - [System Coordination Framework (SC1–SC8)](https://knowledge.aitechdoc.world/system-coordination-framework): Original system architecture model by Saina Veigel in eight elements (software, control, communication, motion, safety, diagnostics, human–machine interaction, digital twin), each with scope, layers and glossary references; copyrighted, published for reference and citation only - [Blueprints](https://knowledge.aitechdoc.world/blueprints): Original thinking models for technical documentation by Saina Veigel, each with its author, edition and origin; copyrighted, published for reference and citation; in US English, British English (https://knowledge.aitechdoc.world/uk/blueprints) and German (https://knowledge.aitechdoc.world/de/blueprints) - [Thinking models for technical writers](https://knowledge.aitechdoc.world/blueprints/thinking-models-for-technical-writers): Ten thinking models by Saina Veigel that help technical writers structure complexity before writing, with the mental model stack and an operating-mode grid. Thinking models: First principles thinking, Information Mapping, Component thinking, System thinking, Task thinking, Risk thinking, Variant thinking, Metadata thinking, Publication logic thinking, Clarity thinking. First published as LinkedIn newsletters (https://www.linkedin.com/pulse/thinking-models-technical-writers-saina-veigel-32myc, https://www.linkedin.com/pulse/mental-models-better-context-saina-veigel-wj7ne). German: https://knowledge.aitechdoc.world/de/blueprints/thinking-models-for-technical-writers - [Cognitive psychology for technical communication](https://knowledge.aitechdoc.world/blueprints/cognitive-psychology-for-technical-communication): The reader’s stack by Saina Veigel: ten layers of how documentation works in the reader’s mind, with a use-situation grid and a crosswalk. Thinking models: Noticing, Finding, Orienting, Understanding, Modeling, Holding, Remembering, Deciding, Acting, Recovering. First published as LinkedIn newsletters (https://knowledge.aitechdoc.world/blueprints/thinking-models-for-technical-writers). German: https://knowledge.aitechdoc.world/de/blueprints/cognitive-psychology-for-technical-communication - [Encyclopedia](https://knowledge.aitechdoc.world/encyclopedia): Reference articles on software, content and technical systems: formal definitions, history, components and comparisons, linked to the glossaries. - [Software development kits](https://knowledge.aitechdoc.world/encyclopedia/software-development-kits): Four types of SDK compared: developer, publishing, platform and hardware SDKs — their domains, components and how they interoperate. Includes a comparison and how the subject areas interoperate - [Developer SDKs](https://knowledge.aitechdoc.world/encyclopedia/software-development-kits/developer-sdks): Developer SDKs wrap a platform’s APIs in language libraries, authentication, serialization and error handling. Definition, history, components and uses. - [Publishing SDKs](https://knowledge.aitechdoc.world/encyclopedia/software-development-kits/publishing-sdks): Publishing SDKs parse, validate, transform and render structured content such as DITA or XML into many output formats. Definition, history and components. - [Platform SDKs](https://knowledge.aitechdoc.world/encyclopedia/software-development-kits/platform-sdks): Platform SDKs define how third-party apps, plug-ins and integrations extend a platform: extension points, manifests, sandboxes and permissions. - [Hardware SDKs](https://knowledge.aitechdoc.world/encyclopedia/software-development-kits/hardware-sdks): Hardware SDKs expose devices, sensors and processors to software through drivers, low-level libraries, toolchains and debug tools. Definition and uses. - [Technical documentation models](https://knowledge.aitechdoc.world/encyclopedia/technical-documentation-models): Six documentation models compared: topic-based, task-based, Every Page is Page One, semantic, minimalism and structured authoring — and how they combine. Includes a comparison and how the subject areas interoperate - [Topic-based documentation](https://knowledge.aitechdoc.world/encyclopedia/technical-documentation-models/topic-based-documentation): Topic-based documentation writes content as self-contained units on one subject and assembles them into deliverables. Definition, history, types and limits. - [Task-based documentation](https://knowledge.aitechdoc.world/encyclopedia/technical-documentation-models/task-based-documentation): Task-based documentation organizes content around what users do, derived from task analysis. Definition, history, components, uses and limits. - [Every Page is Page One](https://knowledge.aitechdoc.world/encyclopedia/technical-documentation-models/every-page-is-page-one): Every Page is Page One (EPPO), described by Mark Baker, treats each page as the reader’s entry point. Seven characteristics, origin, uses and limits. - [Semantic documentation](https://knowledge.aitechdoc.world/encyclopedia/technical-documentation-models/semantic-documentation): Semantic documentation represents the meaning of content in machine-readable markup and metadata. Definition, history, components, uses and limits. - [Minimalism](https://knowledge.aitechdoc.world/encyclopedia/technical-documentation-models/minimalism): Minimalism, described by John M. Carroll, designs documentation for action: real tasks, error recovery and little text. Principles, history and limits. - [Structured authoring](https://knowledge.aitechdoc.world/encyclopedia/technical-documentation-models/structured-authoring): Structured authoring writes content to a schema and separates it from formatting. Definition, history from SGML to DITA, components, uses and limits. - [Cognitive psychology in technical communication](https://knowledge.aitechdoc.world/encyclopedia/cognitive-psychology-in-technical-communication): Six articles on how readers notice, remember, understand, decide and search — what research shows and what documentation does because of it. Includes a comparison and how the subject areas interoperate - [Perception and attention](https://knowledge.aitechdoc.world/encyclopedia/cognitive-psychology-in-technical-communication/perception-and-attention): Perception and attention: selective attention, Gestalt grouping, inattentional blindness and signal detection, and what they mean for layout and warnings. - [Memory and instructions](https://knowledge.aitechdoc.world/encyclopedia/cognitive-psychology-in-technical-communication/memory-and-instructions): Memory and instructions: working memory, chunking, schemas and prospective memory, why "seven plus or minus two" is no rule for steps, and what follows. - [Reading comprehension](https://knowledge.aitechdoc.world/encyclopedia/cognitive-psychology-in-technical-communication/reading-comprehension): Reading comprehension: construction-integration, situation models, dual coding and mental models, and how they inform concept information and plain language. - [Cognitive load](https://knowledge.aitechdoc.world/encyclopedia/cognitive-psychology-in-technical-communication/cognitive-load): Cognitive load: Sweller’s theory, split attention, expertise reversal and Mayer’s multimedia principles, with their evidence and limits for documentation. - [Judgment and human error](https://knowledge.aitechdoc.world/encyclopedia/cognitive-psychology-in-technical-communication/judgment-and-human-error): Judgment and human error: heuristics, satisficing, situation awareness, SRK levels and error types, and how they shape troubleshooting and recovery. - [Information seeking](https://knowledge.aitechdoc.world/encyclopedia/cognitive-psychology-in-technical-communication/information-seeking): Information seeking: information foraging, scent, the paradox of the active user and scanning, and how they shape navigation, headings and entry points. - [AI learning path](https://knowledge.aitechdoc.world/ai-learning-path): Three levels (beginner, intermediate, expert) and twelve modules for learning AI, with tracks for technical writers, technical marketers, technical project managers and developers, linked to the AI glossary - [EPPO Projects](https://knowledge.aitechdoc.world/eppo-projects): Fictional documentation projects after Mark Baker's Every Page is Page One, showing what online technical documentation and conceptual landing pages can do - [Integrated machinery lines](https://knowledge.aitechdoc.world/eppo-projects/integrated-machinery-lines): Every Page is Page One documentation of integrated machinery lines, one reference plant per line - [Packaging machine: the reference line RL-1](https://knowledge.aitechdoc.world/eppo-projects/integrated-machinery-lines/packaging-machine): A fictional bottling and packaging line for 0.5-liter PET bottles, 12,000 bottles per hour. Six machines from four suppliers, conveyors and the line control from a system integrator, one safety controller for the whole line. Overview and topic pages (concept, reference, task, troubleshooting, lifecycle), each standing on its own - [When a packaging line becomes one machine](https://knowledge.aitechdoc.world/eppo-projects/integrated-machinery-lines/packaging-machine/when-a-line-becomes-one-machine) (concept): Why linked machines that work as an integral whole count as one machine under EU machinery law, and what that means for the integrator. - [Interfaces and signals between the stations](https://knowledge.aitechdoc.world/eppo-projects/integrated-machinery-lines/packaging-machine/line-interfaces-and-signals) (reference): Reference of the signals the machines of packaging line RL-1 exchange: PackML states, material-flow handshakes and the safety signals per zone. - [Restart the line after a zone stop in the labeling zone](https://knowledge.aitechdoc.world/eppo-projects/integrated-machinery-lines/packaging-machine/restart-after-a-zone-stop) (task): Step by step: restart packaging line RL-1 after an interlocked guard door in labeling zone Z2 was opened and the zone stopped. - [A station stands still without a fault: starved or blocked](https://knowledge.aitechdoc.world/eppo-projects/integrated-machinery-lines/packaging-machine/station-starved-or-blocked) (troubleshooting): Why a machine on packaging line RL-1 stops without a fault message, and how to find the station that really causes the standstill. - [Commissioning the line: from machine acceptance to handover](https://knowledge.aitechdoc.world/eppo-projects/integrated-machinery-lines/packaging-machine/commissioning-the-line) (lifecycle): The commissioning phase of packaging line RL-1: acceptance tests, integration, validation of the safety functions and the documents handed over. - [Knowledge vaults](https://knowledge.aitechdoc.world/vault): Linked notes with a knowledge graph, starting with information architecture - [Blog](https://knowledge.aitechdoc.world/blog): Posts on AI and technical documentation - [Downloads](https://knowledge.aitechdoc.world/downloads): White papers as PDF - [About](https://knowledge.aitechdoc.world/about): Vision, mission and topics, and how AI TechDoc Knowledge and the AI TechDoc Press newsletter complement each other - [User interviews](https://knowledge.aitechdoc.world/interviews): Interviews per target group on the glossaries and the AI learning path - [Contact](https://knowledge.aitechdoc.world/contact): Contact form and email address - [British English version](https://knowledge.aitechdoc.world/uk): Same pages in British spelling - [Deutsche Version](https://knowledge.aitechdoc.world/de): German translation of the pages outside the glossaries ## Glossaries Each glossary has its own llms.txt with every term and its full definition. - [AI glossary and learning path: from beginner to expert](https://knowledge.aitechdoc.world/glossary/ai-glossary-and-learning-path): AI terms and brands arranged as a learning path: levels from beginner to expert, with notes for technical writers, marketers, PMs and developers. 72 terms; definitions: https://knowledge.aitechdoc.world/glossary/ai-glossary-and-learning-path/llms.txt - [Information architecture and ontology glossary](https://knowledge.aitechdoc.world/glossary/information-architecture-and-ontology): iiRDS classes, metadata and packages, RDF, IRI and JSON-LD, and information modeling terms, defined with examples for technical documentation and AI. 37 terms; definitions: https://knowledge.aitechdoc.world/glossary/information-architecture-and-ontology/llms.txt - [DITA 1.3 glossary](https://knowledge.aitechdoc.world/glossary/dita-1-3): DITA 1.3 concepts defined with markup examples: topics, maps, keys, conref reuse, specialization, constraints and conditional processing. 25 terms; definitions: https://knowledge.aitechdoc.world/glossary/dita-1-3/llms.txt - [AI regulation glossary: EU AI Act vs. USA, Canada and China](https://knowledge.aitechdoc.world/glossary/ai-regulation-eu-us-canada-china): EU AI Act terms compared with the AI rules of the USA, Canada and China: risk categories, roles, high-risk obligations, oversight and transparency. 38 terms; definitions: https://knowledge.aitechdoc.world/glossary/ai-regulation-eu-us-canada-china/llms.txt - [Machine safety and safeguarding glossary](https://knowledge.aitechdoc.world/glossary/machine-safety-and-safeguarding): Machine safety terms defined: ISO 12100 risk assessment, hazards, guards, protective devices, emergency stop, stop categories, lockout/tagout and maintenance. 163 terms; definitions: https://knowledge.aitechdoc.world/glossary/machine-safety-and-safeguarding/llms.txt - [Functional safety and systems engineering glossary](https://knowledge.aitechdoc.world/glossary/functional-safety-and-systems-engineering): Functional safety and systems engineering terms: SIL and PL, verification and validation, evidence and traceability, MBSE, interfaces and fault behavior. 218 terms; definitions: https://knowledge.aitechdoc.world/glossary/functional-safety-and-systems-engineering/llms.txt - [Safety documentation, compliance and security glossary](https://knowledge.aitechdoc.world/glossary/safety-documentation-compliance-and-security): Safety documentation and compliance terms: Machinery Regulation, CE marking, safety standards, instructions, warnings, document control and OT security. 97 terms; definitions: https://knowledge.aitechdoc.world/glossary/safety-documentation-compliance-and-security/llms.txt - [Digital product passport and EU omnibus glossary: EU vs. USA, Canada and China](https://knowledge.aitechdoc.world/glossary/digital-product-passport-and-eu-omnibus): EU digital product passport and omnibus rules compared with the USA, Canada and China: ESPR, identifiers, data carriers, DPP standards and ownership. 25 terms; definitions: https://knowledge.aitechdoc.world/glossary/digital-product-passport-and-eu-omnibus/llms.txt - [MedTech and pharma regulation glossary: MDR, IVDR, ISO standards, GxP and ICH](https://knowledge.aitechdoc.world/glossary/medtech-and-pharma-regulation): MedTech and pharma rules defined: MDR vs. IVDR, ISO 13485, ISO 14971, IEC 62304, GMP, GEP and the other GxP, ALCOA+, ICH guidelines and FDA rules. 83 terms; definitions: https://knowledge.aitechdoc.world/glossary/medtech-and-pharma-regulation/llms.txt - [PLC programming, control engineering and SCADA glossary](https://knowledge.aitechdoc.world/glossary/plc-programming-and-control-engineering): PLC programming (IEC 61131-3), IEC 61499, control theory, HMI/SCADA and control panel terms, each with its German term and documentation notes. 263 terms; definitions: https://knowledge.aitechdoc.world/glossary/plc-programming-and-control-engineering/llms.txt - [Automation components, sensors and drives glossary](https://knowledge.aitechdoc.world/glossary/automation-components-sensors-and-drives): Automation components, sensors, process instrumentation, pneumatics, hydraulics, motion control and drives, each with its German term. 404 terms; definitions: https://knowledge.aitechdoc.world/glossary/automation-components-sensors-and-drives/llms.txt - [Robotics, machine vision and manufacturing operations glossary](https://knowledge.aitechdoc.world/glossary/robotics-vision-and-manufacturing-operations): Robotics, machine vision, CNC, intralogistics, ISA-88 batch, MES/ISA-95, energy and maintenance terms, each with its German term. 277 terms; definitions: https://knowledge.aitechdoc.world/glossary/robotics-vision-and-manufacturing-operations/llms.txt - [Industrial communication, IIoT, industrial AI and OT security glossary](https://knowledge.aitechdoc.world/glossary/industrial-communication-iiot-and-ot-security): Fieldbus, industrial Ethernet, OPC UA, IIoT, industrial AI and IEC 62443 OT security terms, each with its German term and documentation notes. 262 terms; definitions: https://knowledge.aitechdoc.world/glossary/industrial-communication-iiot-and-ot-security/llms.txt - [Automation software engineering and system integration glossary](https://knowledge.aitechdoc.world/glossary/automation-software-engineering-and-integration): Automation software engineering, system integration, orchestration and validation terms, each with its German term and documentation notes. 461 terms; definitions: https://knowledge.aitechdoc.world/glossary/automation-software-engineering-and-integration/llms.txt - [Technical documentation and information design glossary](https://knowledge.aitechdoc.world/glossary/technical-documentation-and-information-design): Technical documentation models and information design terms: topics, tasks, EPPO, semantic markup, minimalism, structured authoring and content models. 8 terms; definitions: https://knowledge.aitechdoc.world/glossary/technical-documentation-and-information-design/llms.txt - [Philosophy, reasoning and mental models glossary](https://knowledge.aitechdoc.world/glossary/philosophy-reasoning-and-mental-models): First principles, Socratic questioning, Descartes, analysis and synthesis, reasoning by analogy and mental models: thinking methods and their origins. 11 terms; definitions: https://knowledge.aitechdoc.world/glossary/philosophy-reasoning-and-mental-models/llms.txt ## [Wiki: iiRDS core concepts](https://knowledge.aitechdoc.world/wiki) In-depth guides to the fifteen concepts that carry the iiRDS standard — information units and their versions, renditions and selectors, the metadata that makes content findable, and the package format with the software that creates and reads it. Each guide gives the sourced definition, a practice example, how the concept applies in technical documentation, migration, MedTech and AI retrieval, an RDF snippet and a concept cluster of related guides. - [iiRDS InformationUnit: the abstract base class for metadata-bearing content](https://knowledge.aitechdoc.world/wiki/iirds-information-unit): An iiRDS information unit is the addressable piece of content, identified by an IRI, to which all descriptive metadata is attached, always typed as one of four concrete subclasses. - [iiRDS Topic: the self-contained unit of topic-based documentation](https://knowledge.aitechdoc.world/wiki/iirds-topic): An iiRDS Topic is a subclass of InformationUnit for one self-contained subject, typed as iirds:Topic and described by metadata so it can be delivered on its own. - [iiRDS Document: the information unit for complete deliverables](https://knowledge.aitechdoc.world/wiki/iirds-document): An iiRDS Document is the subclass of InformationUnit for an ordered set of information that the sender intends to be regarded as one entity, classified by at least one document type. - [iiRDS Package: the information unit that describes a complete delivery](https://knowledge.aitechdoc.world/wiki/iirds-package): The iirds:Package instance is the metadata record of the delivery as a whole, while the ZIP archive is the file that carries it. - [iiRDS InformationObject: one identity for every language and revision](https://knowledge.aitechdoc.world/wiki/iirds-information-object): An iiRDS InformationObject is the shared, file-less identity behind all translations and revisions of one piece of content. - [iiRDS Rendition: the file behind an information unit](https://knowledge.aitechdoc.world/wiki/iirds-rendition): An iiRDS Rendition names one file inside the package, by relative path and format, that delivers the content of an information unit. - [iiRDS Selector: FragmentSelector and RangeSelector for parts of files](https://knowledge.aitechdoc.world/wiki/iirds-selector): An iiRDS Selector is a pointer from a rendition into its file, expressed as a FragmentSelector for one identifier or a RangeSelector for a start and an end. - [iiRDS metadata: how documentation, administrative and information type metadata fit together](https://knowledge.aitechdoc.world/wiki/iirds-metadata): iiRDS metadata is the machine-readable description of a package's content, grouped by what content applies to, how it is managed and what kind of content it is, all written as RDF into one metadata file. - [iiRDS InformationType: classifying content by document type, topic type and subject](https://knowledge.aitechdoc.world/wiki/iirds-information-type): iiRDS InformationType is the classification branch of the vocabulary that tells a consumer whether content is, for example, operating instructions, a task, safety information or a table of contents. - [Audience in iiRDS: how Qualification, Role and SkillLevel model the target group](https://knowledge.aitechdoc.world/wiki/iirds-audience): iiRDS expresses who a piece of content is meant for by linking it to company-defined roles and skill levels, which are subclasses of iirds:Qualification. - [iiRDS ProductLifeCyclePhase: linking content to the phases of a product's life](https://knowledge.aitechdoc.world/wiki/iirds-lifecycle-phase): A product lifecycle phase in iiRDS says at which stage of the product's life, such as installation, operation or disposal, the content is needed. - [iiRDS ExternalClassification: mapping content to ECLASS, VDI 2770 and other systems](https://knowledge.aitechdoc.world/wiki/iirds-external-classification): An iiRDS ExternalClassification stores the code a product, component or piece of content has in someone else's classification system, together with the system it belongs to. - [iiRDS container and ZIP archive: how an iiRDS package is structured and exchanged](https://knowledge.aitechdoc.world/wiki/iirds-container-and-zip): The container fixes where metadata and content files sit in an iiRDS package, and the .iirds ZIP archive packs that layout into one exchangeable file. - [iiRDS Generator: the software role that creates iiRDS packages](https://knowledge.aitechdoc.world/wiki/iirds-generator): An iiRDS Generator is whatever software writes the package: it converts source content into renditions, describes them in metadata.rdf and delivers both as one .iirds file. - [iiRDS Consumer: the software role that reads and processes iiRDS packages](https://knowledge.aitechdoc.world/wiki/iirds-consumer): An iiRDS Consumer is whatever software receives a package, reads its metadata and uses it to find, filter, assemble or display the content. ## [Context cards](https://knowledge.aitechdoc.world/context-cards) Each card answers one question and names the glossary terms it builds on. Also in British English (/uk) and German (/de). - [Cognitive load and split attention: why figures, labels and text belong together](https://knowledge.aitechdoc.world/context-cards/cognitive-load-and-split-attention) (transitional topic: bridges The art of thinking and technical documentation) — What does cognitive load theory say about combining figures and text in instructions, and what follows for technical documentation? Cognitive load theory, developed by John Sweller from 1988, holds that working memory is limited and that instruction should not spend it on processing that does not serve understanding. Paul Chandler and John Sweller (1991) showed that when learners must mentally integrate a figure and a separate text that only make sense together, learning suffers (the split-attention effect), and that physically integrating them helps. In documentation this supports labels placed on the figure, text next to the part it explains and no redundant copies of the same information. Terms: Symbol, Safety information readability, Usability, DITA task, Instructions for use (IFU), Safety sign. German: https://knowledge.aitechdoc.world/de/context-cards/cognitive-load-and-split-attention - [Mental models and concept information: why readers need to know how it works before they act](https://knowledge.aitechdoc.world/context-cards/mental-models-and-concept-information) (transitional topic: bridges The art of thinking and technical documentation) — How does research on mental models support placing concept information before task information in technical documentation? Research on mental models, from Philip Johnson-Laird (1983) and Donald Norman (1983, 1988), describes how people build internal representations of a system and use them to predict its behavior and choose actions. Users form these models from the system image, which includes the documentation, so a short, accurate explanation of how the product works helps readers carry out tasks, infer what to do in unforeseen cases and interpret what they see. Concept information placed before or linked from the tasks is the documentation practice built on that finding. Terms: Mental model, DITA concept, DITA task, Human-machine interface (HMI), Instructions for use (IFU), Operating mode, Mental model (thinking tool). German: https://knowledge.aitechdoc.world/de/context-cards/mental-models-and-concept-information - [Human error types and troubleshooting: from slips, lapses and mistakes to recovery information](https://knowledge.aitechdoc.world/context-cards/human-error-types-and-troubleshooting) (transitional topic: bridges The art of thinking and technical documentation) — How do the error types of James Reason and Jens Rasmussen's skill-, rule- and knowledge-based behavior help design troubleshooting and recovery information? James Reason (1990) distinguished slips and lapses, where a correct plan is carried out wrongly or a step is forgotten, from mistakes, where the plan itself is wrong, and linked them to Jens Rasmussen's levels of skill-, rule- and knowledge-based behavior (1983). Each type calls for different help: slips are mostly prevented by design, lapses by checklists and visible progress, rule-based mistakes by clear symptom-cause-remedy information and knowledge-based mistakes by an accurate model of the system. Troubleshooting information that is organized around what the reader observes, and that says how to detect, stop and undo an error, follows from this distinction. Terms: Human error, Troubleshooting, DITA troubleshooting topic, Reasonably foreseeable misuse, Risk assessment, Alarm management, Mental model. German: https://knowledge.aitechdoc.world/de/context-cards/human-error-types-and-troubleshooting - [Cognitive psychology in technical communication: theory, application and the bridges between them](https://knowledge.aitechdoc.world/context-cards/cognitive-psychology-theory-and-application) (transitional topic: bridges The art of thinking and technical documentation) — What is the difference between cognitive psychology as theory and its application in documentation, and how do the two fit together? Cognitive psychology as theory describes how people perceive, attend, remember, understand, decide and err; it is descriptive and judged by evidence. Applied cognitive psychology for information use is prescriptive: it turns those findings into design principles, practices and evaluation methods for documentation. The bridges are the explicit arguments that lead from one finding to one practice, together with their limits. Terms: Mental model, Human error, Warning message, Safety information usability, Usability, Risk assessment, Instructions for use (IFU), DITA concept, DITA task. German: https://knowledge.aitechdoc.world/de/context-cards/cognitive-psychology-theory-and-application - [Attention and warning placement: from selective attention and habituation to where warnings go](https://knowledge.aitechdoc.world/context-cards/attention-and-warning-placement) (transitional topic: bridges The art of thinking and technical documentation) — What does research on attention and warnings say about where and how warnings should be placed in instructions? Attention is selective: people notice what is salient and relevant to their current goal and can miss even conspicuous things they are not looking for, as inattentional blindness studies show. Warnings research, summed up in Michael Wogalter's communication-human information processing model (C-HIP), shows that a warning works only if it is noticed, keeps attention, is understood, is believed and motivates the right behavior, and that repeated, irrelevant warnings lose attention through habituation. Warnings therefore go where the hazard meets the reader's action, immediately before the step, and only where the risk assessment calls for them. Terms: Warning message, Safety information usability, Safety information readability, Safety sign, Warning (HMI message), Alarm flooding, Risk assessment, Residual risk. German: https://knowledge.aitechdoc.world/de/context-cards/attention-and-warning-placement - [Working memory and procedure steps: why "seven plus or minus two" is the wrong rule](https://knowledge.aitechdoc.world/context-cards/working-memory-and-procedure-steps) (transitional topic: bridges The art of thinking and technical documentation) — Does working memory research justify a fixed maximum number of steps in a procedure, such as seven plus or minus two? No. George A. Miller's 1956 paper was about the limits of absolute judgment and immediate memory span and about recoding information into larger chunks; it set no rule for documents. Later work, notably Nelson Cowan's 2001 review, puts the capacity of working memory at about four chunks, but a reader of a procedure does not need to hold all steps in mind, because the steps stay on the page. Terms: DITA task, Instructions for use (IFU), Usability, Safety information usability, Mental model. German: https://knowledge.aitechdoc.world/de/context-cards/working-memory-and-procedure-steps - [How first principles thinking evolved: an adaptation of many adaptations](https://knowledge.aitechdoc.world/context-cards/first-principles-thinking-lineage) (transitional topic: bridges The art of thinking and technical documentation) — Where does first principles thinking come from, and how has it changed on its way to technical writing? First principles thinking is not a modern invention. Aristotle named first principles in the 4th century BCE, and since then Euclid, Descartes, the scientists of analysis and synthesis, physicists, the strategist John Boyd, Elon Musk and the mental-model literature have each adapted it for their own field. The first principles layer of the thinking models for technical writers is one more adaptation: it applies the method to information — what is true about the product, the user and the risk before structure or wording begins. Terms: First principles thinking, First principle (philosophy), Socratic questioning, Axiomatic method, Analysis and synthesis (method), Cartesian method, First-principles calculation, Destruction and creation (John Boyd), Reasoning by analogy, Mental model, Latticework of mental models, Five whys, Risk assessment, Assumption (systems engineering). German: https://knowledge.aitechdoc.world/de/context-cards/first-principles-thinking-lineage - [Documenting foreseeable misuse without making it an option](https://knowledge.aitechdoc.world/context-cards/documenting-foreseeable-misuse) — How do instructions describe reasonably foreseeable misuse without presenting it as a way to use the product? By stating it as a boundary, not as a variant of use. Reasonably foreseeable misuse is identified in the risk assessment; the instructions name what must not be done, say why, and keep it apart from the descriptions of intended use and from procedures. A prohibited action written like an operating step, or explained in so much detail that it reads like a workaround, normalizes the very behavior it is meant to prevent. Terms: Reasonably foreseeable misuse, Intended use, Residual risk, Risk assessment, Information for use, Machinery Regulation (EU) 2023/1230, ISO 12100, Warning message. German: https://knowledge.aitechdoc.world/de/context-cards/documenting-foreseeable-misuse - [Operating modes in technical documentation](https://knowledge.aitechdoc.world/context-cards/operating-modes-in-technical-documentation) — Why do operating modes change what the documentation of a machine has to say? Because a machine is not the same machine in every mode. In setup, cleaning, maintenance or fault recovery, safeguards may be open or reduced, other people work at other places, and other hazards and temptations arise. Documentation that only describes normal operation leaves the riskiest moments undocumented; asking the same questions in every mode — who, where, what activity, which residual risks, which misuse, what is prohibited, which site conditions — shows which information each mode needs. Terms: Operating mode, Operating-mode management, Residual risk, Reasonably foreseeable misuse, Safeguard, Enabling device, Lockout/tagout (LOTO), Personal protective equipment (PPE), Qualified person, Machinery Regulation (EU) 2023/1230, ISO 12100. German: https://knowledge.aitechdoc.world/de/context-cards/operating-modes-in-technical-documentation - [Where a warning belongs: safety chapter or before the task](https://knowledge.aitechdoc.world/context-cards/warning-placement-in-instructions) — Should a warning go into the safety chapter or directly before the step it concerns? Both places have a job, and they are not interchangeable. The safety chapter gives the general safety information a reader needs before using the product at all; a warning that concerns a specific hazard during a specific action belongs directly before that action, where the reader meets the hazard. A warning that only appears in the safety chapter is often not seen at the moment of action, and a warning repeated everywhere loses its meaning. Terms: Warning message, Safety chapter, Residual risk, Risk assessment, Information for use, DITA hazard statement, Three-step method, Safety information usability. German: https://knowledge.aitechdoc.world/de/context-cards/warning-placement-in-instructions - [Instructions for use: one manual or a set of information products?](https://knowledge.aitechdoc.world/context-cards/instructions-for-use-as-an-information-set) — Do "instructions for use" mean one user manual or a collection of documents? Either. IEC/IEEE 82079-1:2019 uses "information for use" as the generic term and allows it to consist of several information products, each selected and delivered for a target audience: an operating manual, a maintenance manual, quick guides, safety leaflets, online help. For a machine or an integrated line the set usually also contains supplier documentation. The set leaves the manufacturer, and a copy of it remains in the technical file. Terms: Instructions for use (IFU), Information for use, Operating manual, Maintenance manual, Technical file, Labeling and instructions for use (MDR and IVDR). German: https://knowledge.aitechdoc.world/de/context-cards/instructions-for-use-as-an-information-set - [Betriebsanweisung: one German word, many operator documents](https://knowledge.aitechdoc.world/context-cards/betriebsanweisung-and-operator-documentation) — What is a Betriebsanweisung, and how does it differ from the manufacturer’s operating manual? In German occupational safety law, a Betriebsanweisung is a written, binding instruction from the employer to its employees on how to work safely with work equipment, hazardous substances or biological agents, based on the employer’s own risk assessment (§ 12 BetrSichV, § 14 GefStoffV). The operating manual (Betriebsanleitung) comes from the manufacturer with the product. In company usage the word also covers operator SOPs, work instructions, shift instructions and other operator documents. Terms: Ordinance on Industrial Safety and Health (BetrSichV), Ordinance on Hazardous Substances (GefStoffV), Operating manual, Instructions for use (IFU), Personal protective equipment (PPE), Lockout/tagout (LOTO). German: https://knowledge.aitechdoc.world/de/context-cards/betriebsanweisung-and-operator-documentation - [Task analysis across the documentation disciplines](https://knowledge.aitechdoc.world/context-cards/task-analysis-across-documentation-disciplines) — Who uses task analysis, and which documents does it feed? Almost every documentation discipline, each for its own document: safety engineers for the risk assessment and the instruction handbook, regulatory teams for the usability file of medical devices, quality for SOPs and work instructions, R&D and PLM for requirements and the split between people and machines, technical writers for the instructions for use, roll-out teams for training, and operators for their own instructions. The analysis is similar; the purpose, audience and access of the result differ. Terms: Risk assessment, ISO 12100, IEC 62366-1, Training needs analysis, Quality documentation, Product lifecycle management (PLM). German: https://knowledge.aitechdoc.world/de/context-cards/task-analysis-across-documentation-disciplines - [Task analysis: one task, three lenses](https://knowledge.aitechdoc.world/context-cards/task-analysis-lenses) — Is task analysis one method, or are technical, collaborative and cognitive task analysis different things? They are three lenses on the same task. ISO 9241-11:2018 defines a task as a set of activities undertaken to achieve a specific goal and notes that these activities can be physical, perceptual and cognitive. Hierarchical task analysis asks what has to be done and in which order, team task analysis asks how the work passes between people, and cognitive task analysis asks what people have to know, notice and decide. Terms: Usability, DITA task, Task allocation, Human error, RACI matrix, Training needs analysis. German: https://knowledge.aitechdoc.world/de/context-cards/task-analysis-lenses - [Internal and external technical documentation: what "external" really means](https://knowledge.aitechdoc.world/context-cards/internal-and-external-technical-documentation) — Does "external documentation" mean documentation that is published? No. In German practice (VDI 4500) and in EU product law, "internal" and "external" say who keeps a document: internal documentation stays with the manufacturer as evidence, external documentation leaves the manufacturer and goes to operators and users. Whether a document is also public is a separate decision: most external documentation is handed over under contract or behind a login and is never on the open internet. Terms: Technical documentation, Technical file, Information for use, Instructions for use (IFU), Operating manual, Machinery Regulation (EU) 2023/1230. German: https://knowledge.aitechdoc.world/de/context-cards/internal-and-external-technical-documentation - [CRA product categories: default, important and critical](https://knowledge.aitechdoc.world/context-cards/cra-product-categories) — Which CRA products need a notified body, and how many products fall into the stricter categories? Only products whose core functionality matches a category listed in Annex III (important, classes I and II) or Annex IV (critical) face stricter conformity assessment; everything else in scope is in the default category and may use internal control (Module A). As the Open Regulatory Compliance Working Group puts it: "Most products in scope of the CRA are not classified as Important or Critical." The essential requirements, vulnerability handling and reporting obligations apply to every category. Terms: Cyber Resilience Act (CRA), Conformity assessment, Notified body (MDR and IVDR), Harmonized standard, Presumption of conformity, Declaration of Conformity, CE marking. German: https://knowledge.aitechdoc.world/de/context-cards/cra-product-categories - [The Radio Equipment Directive: when sector law absorbs aspect requirements](https://knowledge.aitechdoc.world/context-cards/radio-equipment-directive-sector-and-aspect-law) — Why does the cybersecurity part of the Radio Equipment Directive create parallel compliance paths? The Radio Equipment Directive (RED) is sector legislation: it covers one product group, radio equipment, but also carries aspect requirements that horizontal acts cover for all other products — safety, EMC and, since August 1, 2025, cybersecurity, privacy and fraud protection through Delegated Regulation (EU) 2022/30. When the horizontal Cyber Resilience Act covers the same aspect, the result is two routes for the same objective. The Commission resolved this overlap by repealing the RED cybersecurity delegated act with effect from December 11, 2027. Terms: Cyber Resilience Act (CRA), Low Voltage Directive, Electromagnetic compatibility (EMC), Harmonized standard, Presumption of conformity, CE marking. German: https://knowledge.aitechdoc.world/de/context-cards/radio-equipment-directive-sector-and-aspect-law - [Machinery Regulation and CRA: coupled through standards, not cross-references](https://knowledge.aitechdoc.world/context-cards/machinery-regulation-and-cra-coupled-through-standards) — Why can the Machinery Regulation and the Cyber Resilience Act not simply refer to each other? Because they overlap only on the surface. The Machinery Regulation sets safety objectives — a machine must not become dangerous, including through corruption of its control system — while the CRA sets cybersecurity objectives for products with digital elements. Their scopes and exemptions differ, so a legal cross-reference would leave gaps. The final CRA dropped the presumption its proposal had foreseen and asks for the coupling in harmonized standards instead, where safety and security are linked methodically. Terms: Machinery Regulation (EU) 2023/1230, Cyber Resilience Act (CRA), Harmonized standard, Safety-security convergence, Safety-security interface, IEC 62443, Presumption of conformity. German: https://knowledge.aitechdoc.world/de/context-cards/machinery-regulation-and-cra-coupled-through-standards - [EN 50742: safety-related security levels and IEC 62443 working together](https://knowledge.aitechdoc.world/context-cards/en-50742-safety-related-security-levels) — Is EN 50742 a sign that legislators misunderstand technicalities, and do its SRSLs contradict IEC 62443? Neither. EN 50742, "Safety of machinery – Protection against corruption", is not legislation: it is a European standard drafted by the CENELEC technical committee CLC/TC 44X to support the Machinery Regulation. Its safety-related security levels (SRSL 0–3) state how strongly a safety function must be protected against corruption; IEC 62443 provides the security control framework. EN 50742 combines the two, which is standard practice in coupling safety and security. Terms: Machinery Regulation (EU) 2023/1230, IEC 62443, Security level (SL), Safety-security convergence, Tamper resistance, Harmonized standard, Presumption of conformity, Risk assessment. German: https://knowledge.aitechdoc.world/de/context-cards/en-50742-safety-related-security-levels - [The SBOM under BSI TR-03183-2: an inventory, not a vulnerability report](https://knowledge.aitechdoc.world/context-cards/bsi-tr-03183-sbom) — What does BSI TR-03183-2 require of a software bill of materials, and how does it relate to the CRA? TR-03183-2 defines a machine-processable SBOM in CycloneDX 1.6 or SPDX 3.0.1 or higher, one per software version, with set data fields for every component and recursive dependency resolution down to the first component outside the scope of delivery. It deliberately excludes vulnerability information: the SBOM is static for a given version, while vulnerability status changes and belongs in security advisories or VEX. The CRA makes an SBOM mandatory; the guideline describes one detailed way to draw it up. Terms: Software bill of materials (SBOM), Cyber Resilience Act (CRA), Supply chain security, License management, Security advisory, Common Vulnerabilities and Exposures (CVE), Vulnerability management. German: https://knowledge.aitechdoc.world/de/context-cards/bsi-tr-03183-sbom - [Receiving vulnerability reports under BSI TR-03183-3: report, notification, advisory](https://knowledge.aitechdoc.world/context-cards/bsi-tr-03183-vulnerability-reports) — What does BSI TR-03183-3 expect a manufacturer to have in place before the first vulnerability report arrives? A public, findable way in and a process behind it: a signed security.txt under /.well-known/, a PSIRT and a CSIRT with functional mailboxes and OpenPGP keys, an anonymous web form, a central web page for vulnerability reports and a published CVD policy with response times. The guideline also separates three things that are often mixed up: the confidential vulnerability report a manufacturer receives, the non-public notification it sends to a CSIRT or ENISA, and the public security advisory for users. Terms: Coordinated vulnerability disclosure (CVD), Vulnerability disclosure, Security advisory, Common Vulnerability Scoring System (CVSS), Vulnerability management, Cyber Resilience Act (CRA). German: https://knowledge.aitechdoc.world/de/context-cards/bsi-tr-03183-vulnerability-reports - [Module H under the CRA: BSI TR-03183-H builds full quality assurance on ISO/IEC 27001](https://knowledge.aitechdoc.world/context-cards/bsi-tr-03183-module-h) — How can a manufacturer demonstrate CRA conformity through its processes rather than product by product, and what does BSI TR-03183-H add? Through Module H, full quality assurance under Annex VIII of the CRA: a notified body approves and periodically audits the manufacturer's quality system for design, development, production and vulnerability handling. TR-03183-H describes one way to build that quality system on an ISO/IEC 27001 information security management system, refined and extended for products with digital elements and complemented by ISO 9001 elements. It is not a new management system standard, and its approval still includes a product-type-specific review of technical documentation. Terms: Conformity assessment, Notified body (MDR and IVDR), Information security management system (ISMS), Quality management, Security development lifecycle (SDL), Harmonized standard, Presumption of conformity, Cyber Resilience Act (CRA). German: https://knowledge.aitechdoc.world/de/context-cards/bsi-tr-03183-module-h - [BSI guidance on the CRA: context-dependent, not contradictory](https://knowledge.aitechdoc.world/context-cards/bsi-cra-guidance-context-and-method) — When two pieces of BSI guidance on the Cyber Resilience Act seem irreconcilable, is the guidance contradictory? Usually not. BSI TR-03183-1 builds its controls on risk scenarios: a control applies only where the product's assets, access, interfaces and users match its scenario, and is otherwise marked not applicable. Two recommendations can therefore point in different directions for two parts of the same product without contradicting each other. The manufacturer's cybersecurity risk assessment under Article 13 CRA decides which one applies where. Terms: Cyber Resilience Act (CRA), Security risk assessment, Harmonized standard, Presumption of conformity, Software bill of materials (SBOM), State of the art. German: https://knowledge.aitechdoc.world/de/context-cards/bsi-cra-guidance-context-and-method - [The explosion protection document after a conversion](https://knowledge.aitechdoc.world/context-cards/explosion-protection-document-and-conversions) — When does the explosion protection document have to be updated? Whenever the plant changes significantly. § 6(9) of the German Ordinance on Hazardous Substances (GefStoffV) requires hazards from explosive mixtures to be shown separately in the documented risk assessment, and § 6(10) requires the assessment to be updated promptly when significant changes require it; Directive 1999/92/EC names changes, extensions and conversions. An extension or a moved spray booth is such a change. Terms: Explosion protection document, Hazardous area classification (Ex zones), Ordinance on Hazardous Substances (GefStoffV), Grandfathering (work equipment), Management of change (MOC), Explosion protection, Retrofit. German: https://knowledge.aitechdoc.world/de/context-cards/explosion-protection-document-and-conversions - [BetrSichV or GefStoffV: which ordinance carries the duty?](https://knowledge.aitechdoc.world/context-cards/betrsichv-or-gefstoffv) — Does the duty to keep the explosion protection document current come from the BetrSichV or the GefStoffV? From the GefStoffV. The explosion protection document is part of the risk assessment under § 6 of the Ordinance on Hazardous Substances, which also requires its prompt update after significant changes. The BetrSichV governs the use and inspection of work equipment, including Ex equipment, and has its own review duty in § 3(7). The result is often the same; the legal basis is different. Terms: Ordinance on Industrial Safety and Health (BetrSichV), Ordinance on Hazardous Substances (GefStoffV), Explosion protection document, Presumption effect (technical rules), Adaptation to the state of the art (work equipment), Grandfathering (work equipment). German: https://knowledge.aitechdoc.world/de/context-cards/betrsichv-or-gefstoffv - [Grandfathering covers the design, never the file](https://knowledge.aitechdoc.world/context-cards/grandfathering-and-plant-documentation) — Does grandfathering protect an existing plant and its documentation? German operational safety law grants no general grandfathering for work equipment: under § 3(7) BetrSichV the risk assessment must be reviewed regularly, taking the state of the art into account, and the measures adapted where needed. An older machine may keep its original design if it can still be used safely, but its documents enjoy no protection at all: a risk assessment or zone drawing that was never updated describes a plant that no longer exists. Terms: Grandfathering (work equipment), Ordinance on Industrial Safety and Health (BetrSichV), Adaptation to the state of the art (work equipment), Presumption effect (technical rules), As-built documentation, Explosion protection document, State of the art. German: https://knowledge.aitechdoc.world/de/context-cards/grandfathering-and-plant-documentation - [Retrofit and substantial modification under the Machinery Regulation](https://knowledge.aitechdoc.world/context-cards/retrofit-and-substantial-modification) — When does a retrofit make the operator the manufacturer of a machine? Only when the retrofit is a substantial modification: a change by physical or digital means that the original manufacturer did not foresee and that creates a new hazard or increases a risk so that new guards or protective devices changing the safety control system, or new measures for stability or strength, are needed. A new program on the safety controller can meet this test as much as a new guard. Then Article 18 of the Machinery Regulation treats whoever made it as the manufacturer. Most retrofits are not substantial, but each one needs the assessment that shows it. Terms: Retrofit, Retrofit under the Machinery Regulation, Substantial modification, Machinery Regulation (EU) 2023/1230, Machinery Directive 2006/42/EC, Assembly of machinery, Stop controls of an assembly of machinery (1.2.4.4), Ordinance on Industrial Safety and Health (BetrSichV), Technical file, Safety PLC, Remote software update, Configuration management. German: https://knowledge.aitechdoc.world/de/context-cards/retrofit-and-substantial-modification - [Topic-based vs. task-based documentation](https://knowledge.aitechdoc.world/context-cards/topic-based-vs-task-based-documentation) — Is topic-based documentation the same as task-based documentation? No. Topic-based documentation is about the unit: content is written in self-contained topics and assembled by maps. Task-based documentation is about selection: content is chosen and organized around the tasks users perform. A topic-based set can be feature-oriented, and task orientation also works in a book, but the two are most often combined. Terms: DITA topic, DITA task, DITA concept, DITA reference, DITA map, DITA information typing. German: https://knowledge.aitechdoc.world/de/context-cards/topic-based-vs-task-based-documentation - [Minimalism and structured authoring](https://knowledge.aitechdoc.world/context-cards/minimalism-and-structured-authoring) — How do minimalism and structured authoring work together? Minimalism, described by John M. Carroll, sets principles for content: support action on real tasks, anchor instruction in the user’s work, help users recognize and recover from errors, and keep text to what users need. Structured authoring sets the form: content follows a validated content model. A content model can make minimalist patterns mandatory, for example one action per step or a result after each step. Terms: Schema (data), Schema validation, DITA (Darwin Information Typing Architecture), DITA task, DITA specialization, Information for use. German: https://knowledge.aitechdoc.world/de/context-cards/minimalism-and-structured-authoring - [Every Page is Page One vs. semantic documentation](https://knowledge.aitechdoc.world/context-cards/eppo-vs-semantic-documentation) — Is Every Page is Page One a form of semantic documentation? No — they are separate models that complement each other. Every Page is Page One, described by Mark Baker, is a model of writing: each page must work as the reader’s first page, establish its context and link richly. Semantic documentation is a model of representation: markup and metadata state in machine-readable form what content is about. Semantic metadata can make an EPPO page’s context readable for systems. Terms: DITA topic, Metadata, Taxonomy, Ontology, Information model, iiRDS Topic, Knowledge graph. German: https://knowledge.aitechdoc.world/de/context-cards/eppo-vs-semantic-documentation - [Six technical documentation models compared](https://knowledge.aitechdoc.world/context-cards/documentation-models-compared) — How do topic-based, task-based, EPPO, semantic, minimalist and structured documentation differ? They answer different questions rather than competing. Topic-based documentation defines the unit of content, task-based documentation which content is needed, Every Page is Page One whether each page stands on its own, semantic documentation what content is about, minimalism how content supports action, and structured authoring the form in which content is written. Most documentation systems combine several of them. Terms: Technical documentation, DITA (Darwin Information Typing Architecture), DITA topic, DITA task, Metadata, Information model, Schema (data). German: https://knowledge.aitechdoc.world/de/context-cards/documentation-models-compared - [Four types of SDK compared](https://knowledge.aitechdoc.world/context-cards/sdk-types-compared) — What distinguishes developer, publishing, platform and hardware SDKs? All four are software development kits — bundles of libraries, tools, documentation and samples — but they target different things. A developer SDK wraps a remote service or API, a publishing SDK transforms structured content into output formats, a platform SDK extends a host application from the inside, and a hardware SDK exposes a device or processor to software. The target decides the artifacts, the users and who calls whom. Terms: Software development kit (SDK), Application programming interface (API), DITA (Darwin Information Typing Architecture), Device driver, Firmware, Software library, Compiler. German: https://knowledge.aitechdoc.world/de/context-cards/sdk-types-compared - [How the four SDK types interoperate](https://knowledge.aitechdoc.world/context-cards/sdk-interoperation) — Where do developer, publishing, platform and hardware SDKs meet in practice? The four SDK types serve different domains but meet at shared interfaces. A device built with a hardware SDK reports data to a cloud service used through a developer SDK; a platform extension presents that data inside a business application; a publishing pipeline pulls interface descriptions and product data into documentation. Interoperation works when each boundary has an explicit contract, a common data format, versioning and shared identifiers. Terms: Interoperability, Interface contract, Serialization format, JSON, Distributed tracing, Observability, IoT gateway, Digital twin, Software bill of materials (SBOM). German: https://knowledge.aitechdoc.world/de/context-cards/sdk-interoperation - [Extension points of a platform](https://knowledge.aitechdoc.world/context-cards/platform-extension-points) — How does a platform SDK let outside code extend a host application? A platform SDK defines where and how outside code may plug into a host application: named extension points, a manifest that declares what the extension contributes and which permissions it needs, APIs the extension may call and usually a sandbox that isolates it. The host loads the extension and calls it at the declared points — control stays with the host. Terms: Software framework, Application programming interface (API), Authorization, Interface contract, Backward compatibility, Deprecation path, Low-code/no-code platform. German: https://knowledge.aitechdoc.world/de/context-cards/platform-extension-points - [Stages of a publishing pipeline](https://knowledge.aitechdoc.world/context-cards/publishing-pipeline-stages) — What happens to structured content inside a publishing SDK? A publishing SDK runs structured source content through a fixed sequence of stages: it resolves the map and its references, validates the markup, applies filtering for the intended audience or product variant, transforms the result into an output format and packages it with its metadata. Each stage can be configured or extended, so one source yields many outputs. Terms: DITA (Darwin Information Typing Architecture), DITA map, DITA topic, DITA conditional processing, DITA content reference (conref), DITA key, Schema validation, Metadata. German: https://knowledge.aitechdoc.world/de/context-cards/publishing-pipeline-stages - [SDK vs. API](https://knowledge.aitechdoc.world/context-cards/sdk-vs-api) — What is the difference between an SDK and an API? An API is an interface: the contract of operations, data formats and rules through which one piece of software uses another. An SDK is a kit built around one or more APIs — libraries in a given programming language, authentication helpers, samples, tools and documentation — that makes the API easier and safer to use. An API can exist without an SDK; an SDK always rests on some interface. Terms: Software development kit (SDK), Application programming interface (API), REST API, Software library, Authentication, Interface contract, Semantic versioning. German: https://knowledge.aitechdoc.world/de/context-cards/sdk-vs-api - [Layers of a hardware SDK](https://knowledge.aitechdoc.world/context-cards/hardware-sdk-layers) — Which layers does a hardware SDK provide between application code and a device? A hardware SDK stacks several layers: a toolchain that compiles and links code for the target processor, low-level drivers and a board or device description, a hardware abstraction layer that hides register details, optional operating system or runtime support, and high-level libraries or standard APIs for applications. Debugging and flashing tools connect the developer's computer to the physical device. Terms: Device driver, Firmware, Microcontroller (MCU), Real-time operating system (RTOS), Compiler, Debugging, Abstraction, Application binary interface (ABI), Embedded software. German: https://knowledge.aitechdoc.world/de/context-cards/hardware-sdk-layers - [Control points for AI agents](https://knowledge.aitechdoc.world/context-cards/ai-agent-control-points) — Who controls what an AI agent is allowed to do? Not the model. What an AI agent may do is decided by the systems around it: its own identity, the permissions granted to that identity, a gateway that checks every tool call, logs that record each action and human approvals for consequential steps. Documentation has to describe these control points, not only the agent. Terms: AI agent, Model Context Protocol (MCP), Role-based access control (RBAC), Principle of least privilege, Audit trail, Human in the loop, Logging. German: https://knowledge.aitechdoc.world/de/context-cards/ai-agent-control-points - [AI vs. classical automation](https://knowledge.aitechdoc.world/context-cards/ai-vs-classical-automation) — How does AI differ from classical automation? Classical automation executes rules that people have defined in advance — a PLC program, a workflow, an RPA bot — and behaves the same way every time. AI systems derive their behavior from data or models and produce outputs that are probable rather than fixed. That is why AI output in operations is usually bounded by deterministic control, permissions and human approval. Terms: Artificial intelligence (AI), Automation, Machine learning (ML), Programmable logic controller (PLC), Robotic process automation (RPA), Human in the loop. German: https://knowledge.aitechdoc.world/de/context-cards/ai-vs-classical-automation - [MQTT vs. OPC UA: transport and meaning](https://knowledge.aitechdoc.world/context-cards/mqtt-vs-opc-ua) — What is the difference between MQTT and OPC UA? MQTT is a lightweight publish-subscribe protocol that moves messages through a broker; it says nothing about what the data means. OPC UA is an industrial interoperability framework with an information model, services, security and, with OPC UA PubSub, its own publish-subscribe mode. In practice they are often combined: OPC UA describes the data, MQTT carries it. Terms: MQTT, OPC Unified Architecture (OPC UA), Publish-subscribe pattern, Message broker, Information model, OPC UA PubSub. German: https://knowledge.aitechdoc.world/de/context-cards/mqtt-vs-opc-ua ## [Information architecture vault](https://knowledge.aitechdoc.world/vault/information-architecture) Linked notes on information architecture: taxonomies, metadata, ontologies, navigation, findability and content models, with a knowledge graph. - [Card sorting](https://knowledge.aitechdoc.world/vault/information-architecture/card-sorting): Card sorting is a research method in which participants sort cards — each naming a piece of content — into groups that make sense to them. It reveals users' Mental models and vocabulary before a structure is fixed. - [Content model](https://knowledge.aitechdoc.world/vault/information-architecture/content-model): A content model defines the types of content an organization produces, the parts (fields) each type consists of, and how types relate to each other. It is the blueprint that turns documents into structured content. - [Controlled vocabulary](https://knowledge.aitechdoc.world/vault/information-architecture/controlled-vocabulary): A controlled vocabulary is an agreed list of terms used to describe and retrieve content, where each concept has one preferred term and the variants are mapped to it. It keeps people and systems from describing the same thing in five… - [Faceted classification](https://knowledge.aitechdoc.world/vault/information-architecture/faceted-classification): Faceted classification describes each item along several independent dimensions — facets — instead of placing it in one position of a single hierarchy. The idea goes back to S. R. Ranganathan's Colon Classification in the 1930s; on the… - [Findability](https://knowledge.aitechdoc.world/vault/information-architecture/findability): Findability is the quality of being locatable: how easily people — and increasingly machines — can find a particular piece of information. Peter Morville, who popularized the term in Ambient Findability (2005), put the premise simply: you… - [Information architecture](https://knowledge.aitechdoc.world/vault/information-architecture/information-architecture): Information architecture is the structural design of shared information environments: how content is organized, labeled, navigated and searched so that people can find what they need and understand where they are. The classic definition… - [Knowledge graph](https://knowledge.aitechdoc.world/vault/information-architecture/knowledge-graph): A knowledge graph represents knowledge as a network of entities (nodes) and typed relations (edges), usually structured by an Ontology. The term became widely known when Google introduced its Knowledge Graph in 2012; today it describes… - [Labeling systems](https://knowledge.aitechdoc.world/vault/information-architecture/labeling-systems): Labeling systems are the words and icons that represent content and choices: menu items, headings, link texts, button captions, index terms. In information architecture, a label is a promise about what lies behind it. - [Mental models](https://knowledge.aitechdoc.world/vault/information-architecture/mental-models): A mental model is a person's internal picture of how something is organized and how it works. In information architecture, mental models decide whether people expect a piece of content under "Maintenance", "Service" or "Troubleshooting" —… - [Metadata](https://knowledge.aitechdoc.world/vault/information-architecture/metadata): Metadata is structured data about content: what it is, what it is about, who it is for and how it may be used. In information architecture, metadata is what connects content to Navigation systems, filters and search — the precondition for… - [Navigation systems](https://knowledge.aitechdoc.world/vault/information-architecture/navigation-systems): Navigation systems are the means by which people move through an information environment and understand where they are. Rosenfeld and Morville distinguish embedded navigation, built into the pages, from supplemental navigation such as… - [Ontology](https://knowledge.aitechdoc.world/vault/information-architecture/ontology): In information science, an ontology is a formal, explicit description of the concepts in a domain and the relations between them. Tom Gruber's often quoted definition calls it "an explicit specification of a conceptualization". Unlike a… - [Taxonomy](https://knowledge.aitechdoc.world/vault/information-architecture/taxonomy): A taxonomy is a controlled set of terms arranged in a hierarchy of broader and narrower categories. Each term has one preferred label, and every item is classified by one or more terms. Taxonomies are one kind of Controlled vocabulary. - [Topic-based authoring](https://knowledge.aitechdoc.world/vault/information-architecture/topic-based-authoring): Topic-based authoring is the practice of writing documentation as self-contained units — topics — that each answer one question or support one task, instead of long linear chapters. The topics are then assembled into manuals, help systems… - [Tree testing](https://knowledge.aitechdoc.world/vault/information-architecture/tree-testing): Tree testing evaluates a proposed hierarchy by asking participants to find items in a text-only version of it — no visual design, no search. It is sometimes called reverse Card sorting: card sorting generates a structure, tree testing… - [Users, content and context](https://knowledge.aitechdoc.world/vault/information-architecture/users-content-and-context): The three circles of information architecture — users, content and context — are the model Rosenfeld and Morville use to scope any IA project. A structure only works where the three overlap. ## Blog posts - [Better branding: our hexagon is in fact a cube](https://knowledge.aitechdoc.world/blog/our-hexagon-is-a-cube): Why the AI TechDoc hexagon is really a cube with three faces: Knowledge for lasting reference, Learning for courses and Press for timely analysis. - [Cybersecurity and resilience architecture for websites: treating the web as a technical system](https://knowledge.aitechdoc.world/blog/cybersecurity-and-resilience-architecture-for-websites): Why modern websites need security and resilience by design: trust boundaries, server-side authorization, edge protection, immutable deploys and recovery. - [Every page could have been page one a long time ago: are we ready now?](https://knowledge.aitechdoc.world/blog/every-page-could-have-been-page-one-a-long-time-ago-are-we-ready-now): What Mark Baker saw early – and what online documentation can do now. The idea did not become a working documentation system at the time because the production models were not ready for it. They should be ready for it now. - [Learning in public: why I build glossaries and an AI learning path](https://knowledge.aitechdoc.world/blog/making-knowledge-shine-glossaries-and-learning-path): Why a technical writer and communications specialist builds glossaries and an AI learning path in public: organizing knowledge, vibe coding, studying digital learning and asking for feedback. - [From an article to a white paper: my collaboration with Michael Iantosca](https://knowledge.aitechdoc.world/blog/adaptive-semantics-a-collaboration): How an article on EvoOntology and iiRDS sparked an idea for Michael Iantosca and became a white paper on adaptive semantics for DITA and iiRDS digital twins. ## White papers - [From knowledge graphs to adaptive semantics](https://knowledge.aitechdoc.world/downloads#from-knowledge-graphs-to-adaptive-semantics) (PDF, 25 pages: https://knowledge.aitechdoc.world/downloads/from-knowledge-graphs-to-adaptive-semantics-september-2026.pdf): A plain-language introduction to how ontology evolution can complement knowledge graphs, inference engines and AI agents without giving up semantic governance. ## [AI TechDoc Press](https://www.press.aitechdoc.world/) In-depth articles on the same topics, in the Substack newsletter AI TechDoc Press: - [Regulatory ambition of the EU AI Act](https://www.press.aitechdoc.world/p/regulatory-ambition-of-the-eu-ai): The EU AI Act as a systems law: risk classification, human oversight, monitoring and documentation as the evidence layer between law and practice. - [Machine AI regulation begins in 2027 — not 2028](https://www.press.aitechdoc.world/p/machine-ai-regulation-begins-in-2027): Why machinery-law assessment of AI functions begins on January 20, 2027, while the AI Act high-risk profile follows in 2028. - [Who owns the EU Digital Product Passport?](https://www.press.aitechdoc.world/p/who-owns-the-eu-digital-product-passport): Why the EU DPP touches almost every function in the company — and the seven checks to run now, from access rights to change control. - [Beyond PIM: building the product data bridge between MR and DPP](https://www.press.aitechdoc.world/p/beyond-pim-building-the-product-data): Why Machinery Regulation safety evidence and DPP product data must stay legally separate — and how PLM, PIM, QMS, MDM and supplier data can connect them.