Content engineering is the discipline that, in technical communication, turns a stack of Word files into a controllable system. Anyone working without content engineering in 2026 can still write manuals, but can no longer integrate them into their customers’ digital delivery processes — nor into the regulatory requirements of the Machinery Regulation 2027.
In practice I run into two gaps in understanding the term. One group takes content engineering to mean „introducing a CCMS“. The other takes it to mean „professionalising content marketing“. Both are wrong. Content engineering is the engineering-grade treatment of information: information is modelled, modularised, tagged with metadata, versioned, and delivered through defined interfaces. The CCMS is only one of the tools for it. Content marketing is an entirely different world.
What content engineering actually delivers
Modelling. Information is given a structure that does not depend on the output. A topic „open the maintenance flap“ exists exactly once — as a structured module with defined components (precondition, tool, step-by-step, safety instruction, follow-up action). From this single module come the manual, the training-video script, the service-portal article, and the AI training dataset.
Modularisation. Content is broken down into small, reusable units — topics, concepts, tasks, references (DITA logic). Anyone who takes this seriously ends up with 30 to 50 % less volume for the same amount of content, because the same information is no longer typed out five times in five manuals.
Metadata. Every module gets a classified stack of metadata: product, version, language, target audience, safety relevance, lifecycle status. This metadata is the basis for intelligent filtering, automated delivery, and compliance analysis.
Versioning. Every change to a module is traceable, every state restorable. Under the Machinery Regulation 2027 this becomes mandatory: you must be able to prove at any time which version of a piece of safety information was delivered with which machine at which point in time.
Delivery via interfaces. iiRDS (intelligent information Request and Delivery Standard) is the industry standard that gives modules a machine-readable address space. Service portals, apps, and AI assistants access the right information at the right time via iiRDS.
Where content engineering is worth the investment
The discipline does not pay off in every organisation. Three indicators that, in practice, make for a sustainable business case:
1. More than three languages, more than 100,000 words per year. At this volume, modularisation amortises through translation savings within two to three years. At smaller volumes, the effort rarely pays for itself.
2. More than two output channels. Anyone who only produces PDF manuals anyway has little leverage. Anyone who serves PDF, web help, service portal, app, and training video from the same source saves the multiple maintenance.
3. Regulatory pressure. The Machinery Regulation 2023/1230 (binding from 14 January 2027) requires audit-proof provision of the instructions in the official language of the market. Anyone who wants to ensure conformity with Word files very quickly loses the overview.
The five maturity levels
Content engineering is not introduced in a single step. From recent consulting engagements, the five levels I see consistently:
- Level 0 — the Word/FrameMaker world. Content as files. Reuse manually by copy-paste. Versioning by file name. Translation sentence by sentence.
- Level 1 — structured templates. Word- or XML-based templates with defined sections. Reuse via copy-paste, but with discipline. TM pre-population takes hold in part.
- Level 2 — CCMS with topic logic. Modular topics in a CCMS, reuse 30 to 60 %. Metadata partially maintained. Output PDF and web help. Translation workflow integrated.
- Level 3 — content model with metadata discipline. A clear data model, metadata binding, reuse 60 to 85 %. Output across several channels including the service portal. First API integrations.
- Level 4 — iiRDS-based intelligent delivery. Content retrievable via iiRDS endpoints, context-based filtering at the end device. Connection to AI assistance and AR instructions. Compliance trail automated.
In practice, among German Mittelstand companies I currently see a concentration at levels 1 to 2, with clear movement towards level 3. Level 4 is still rare in mechanical engineering and further along in the medical-technology environment.
The tool landscape
The most important tool classes used to implement content engineering in practice:
CCMS (Component Content Management System). SCHEMA ST4, Acolada cosima, RWS Tridion Docs, Bluestream XDocs. Effort to introduce in the Mittelstand: 9 to 18 months, six-figure investment range.
DITA editors. Oxygen XML, Adobe FrameMaker (Structured), Heretto. For creating modular XML-based content.
Headless CMS for web delivery. Strapi, Contentful, Storyblok. When content is also used in marketing channels, a headless CMS can make sense as a delivery layer behind the CCMS.
Translation-memory systems. SDL Trados, MemoQ, Phrase. Direct connection to the CCMS via XLIFF and iiRDS.
iiRDS tooling. Quanos iiRDS Suite, parson iiRDS Workbench. For converting and validating iiRDS packages.
Common mistakes in practice
Four patterns I have repeatedly seen in recent consulting engagements:
Tool selection before the data model. A CCMS is bought, and then the discussion about the data model begins. That is the most expensive order: the data model has to come before the tool selection, otherwise the tool is chosen against the wrong criteria.
Migration without cleanup. 20 years of Word documents are mirrored into the CCMS. Out comes structured rubbish: module boundaries along Word page breaks, duplicate content across product lines, inconsistencies that are now even harder to maintain in modular form. Solution: clean up the content before migration.
Metadata without mandatory character. Metadata are „optional fields“ and are therefore left empty. After 12 months the metadata basis is unusable and intelligent filtering does not work. Solution: metadata as mandatory fields in the CCMS, an owner per metadata class.
No interface strategy. The CCMS stands as an island. Service portal, app, and PIM pull their content via manually maintained exports. With every change, someone runs across three systems. Solution: an API-first architecture, iiRDS as the standard for delivery.
The connection to AI
AI tools in technical writing only work with content-engineering groundwork. A language model that works on an unstructured content base produces consistently inconsistent results. A language model that works on modularly structured, metadata-tagged content can offer concrete support — with translation, consistency checking, structure suggestions, terminology maintenance.
Anyone who introduces AI into the writing department without first laying the content-engineering foundation is building on sand. That also applies to AI-supported service assistants and knowledge bots: they are only as good as the content base they operate on.
What a typical introduction project looks like
From consulting practice, the order that has held in German Mittelstand companies:
- Data-model workshop (4 to 6 weeks): which content types exist, what module granularity makes sense, which metadata are binding?
- Tool selection on the basis of the data model (4 to 8 weeks): CCMS vendors are assessed against your own requirements, not against the vendor demo.
- Pilot with one product line (3 to 6 months): one document type, one language direction, clear metrics.
- Migration with cleanup (6 to 12 months, in parallel with ongoing operations): existing content is taken over according to a clear logic or rewritten.
- Delivery via multi-channel (in parallel from month 9): PDF, web help, service portal, and where applicable iiRDS endpoints.
- Handover into regular operation (after month 18 to 24): maintenance owners, documented processes, a governance model.
An inventory as a starting point
Before the CCMS selection, before the iiRDS strategy, before the AI discussion, a systematic inventory pays off: which content types, what reuse today, which data model makes sense. Schübeler Consulting carries out this inventory with you and delivers a concrete data model plus roadmap.
Initial consultation: info@schuebeler-consulting.de or via the website.
Johann Jörgen Schübeler, Schübeler Consulting