AI kills the CCMS interface, not the contracts

Not long ago I rebuilt a documentation table in about thirty seconds, and it changed how I think about fifteen years of my working life.

I took a sample DITA topic: a reference topic with a three-column table, in the structured XML format I have worked in since 2011, that needed a fourth column populated from information elsewhere in the topic. The official way to do this runs through a component content management system:

1. open the topic in the editor,
2. place the cursor,
3. pick the right elements from the right menus,
4. fill the right attributes,
5. repeat for every row,
6. and hope you never mis-nest a tag.

I have done it that way more times than I can count. It is exact, and it is slow, and every step of it happens through an interface that was designed before the iPhone existed.

Instead, I pasted the XML into an AI coding assistant and prompted it to replace this three-column table with a four-column table containing these values, and respect the template and its attributes. Thirty seconds. The tags were right. The attributes were right. The structure was right.

That moment gets misread in two opposite ways, and both misreadings are currently shaping how companies spend money on documentation. The first misreading: "AI just replaced the CCMS." It did not. The second: "AI is a toy; real structured authoring still needs the big system." Also wrong. What actually happened is more specific, and more interesting:

The edit took thirty seconds because a template existed for the AI to respect. An enforceable definition of what a valid table in a valid topic looks like. Strip away the template and the same request produces plausible, drifting, unvalidatable markup. Keep the template, put it in front of the model, and remove the fifteen windows between the writer and the source, and you get the future of this field.

I want to unpack that claim properly, because I have spent fifteen years as a technical writer, first in-house and now freelance, and a good part of that time inside one of the big DITA component content management systems, IXIASOFT (now MadCap IXIA CCMS). Its customer list includes multinationals like SAP. I know what the machine does well, I know where it bleeds, and most of what is written about AI and documentation is written from outside the machine.

The machine, honestly

Start with what the critics get right. The classic IXIASOFT client is an Eclipse workbench: the Java IDE platform, carrying a DITA CMS inside it. By my count the toolbar sprawls past sixty icons. The look and feel is 1990s, the text is small, and accessibility was never part of my working reality in it. In my daily use it never felt fast. Working in it means keeping a half-dozen small windows open at once and knowing, from years of practice, which of the sixty icons hides the operation you need. It is a lot to learn, and it rewards the years you put in. The vendor's own documentation shows the Eclipse desktop client frozen while capability moves to a web client. That web client, as of the versions I used, still could not do parts of the metadata and validation work my releases depended on, so writers fell back to the desktop anyway. The vendor's own what's-new pages for the last two releases read as a campaign to move desktop operations to the web, one at a time, and the pull is constant: new writers now start in the web client and may never open Eclipse at all. I keep trying to make the move myself. I keep gravitating back. The muscle memory over those sixty icons turns out to be its own form of lock-in; the chrome does not merely resist replacement, it recruits its veterans to defend it. That is worth sitting with: the strongest argument for the old interface is not any capability, it is the years I spent learning it.

And the setup is not a download. Getting a deployment of this class running takes the vendor's own people plus internal specialists, and keeping it running is an ongoing institutional function. This is not a secret; reviewers describe initial setup as complex and vendor-assisted. Nobody adopts a system like this casually, and nobody leaves it casually either.

Now the part that rarely gets said, because it only shows from the inside.

The search is extraordinary. Full-text search across a gigantic corpus with layered operators: by date, by last modification, by taxonomy term, by dependency. And it comes back fast. Years into the docs-tools boom, I still cannot point to a lightweight documentation product whose search answers the question "which topics depend on this object, and which of them changed since March?" That question is daily bread in a real documentation operation.

The reuse machinery is deeper than anything the modern tools ship. Everyone imagines content reuse as "write a paragraph once, include it in five documents." The reality in a mature deployment is inverted: the standardized sentence is the asset, and the hand-typed word is the exception. In a mature deployment, a sentence like "You can use ⟨X⟩ to …" exists as a template in which only X is ever written by hand. A regulatory sentence ("In ⟨country⟩, the filing is submitted using ⟨report⟩") is templated in everything except the variables. Product names, UI strings, version numbers: hand-inserted variables in an ocean of governed boilerplate. That is phrase-level reuse, enforced by the system, at a scale where consistency is not a style preference but a legal and translation-cost necessity. Procedures forked mid-stream: steps one and two shared, then 3A, 3B, 3C diverging by audience or configuration, each fork tracked as structure rather than as copy-paste.

And the structure can reach outside the docs. In the most advanced setups, product feature flags are imported into the CCMS and attached to content: to topics, to maps, to the release notes describing the feature. When a customer switches a feature on, the documentation for it appears with it. Documentation as configuration. It is not elegant, and the flag assignment is tedious hand-work, but it is a first-class capability I still do not see in the lightweight structured-authoring generation.

Release notes can run on contracts too. A release note is not prose in a wiki; it is a typed topic with strict metadata (what changed, whether it is new or changed, which deployment models it applies to), validated by scripts before it ships, because downstream systems consume that metadata mechanically. When the metadata is wrong, the validator catches it before a human does. That is what a working contract system sounds like.

So the honest summary of the machine: a monstrous interface wrapped around genuinely irreplaceable contracts. Hold that thought, because every current market narrative gets it half-wrong. The "DITA is dead" crowd throws out the contracts with the interface. The enterprise vendors defend the interface as if it were the contracts.

Two failures no redesign will fix

If the interface were the only problem, a skin would fix it. It is not, and I want to name the two failures that taught me the difference. Both are structural, neither is fixable by a prettier client, and neither, as far as I can tell, has ever been named in public by someone who lived with them.

Every map becomes its own parent. In IXIASOFT's release-management model, topics can be shared across release branches, but maps, the structures that define what a deliverable contains and in what order, work differently. The documentation states it plainly: "A map is never in more than one branch. Each branch always has its own instance of a map." Maps are branched automatically, and in the versions I worked in, a diverged map never re-attached to its parent. Here is what that means at scale. When a product is documented across parallel release branches, every feature that crosses them means the same structural edit (insert this topic, remove that sequence), performed by hand, in every release's copy of every affected map. Over time the maps drift apart, one by one, until every one of them is detached. The system that made phrase-level reuse effortless left the shape of deliverables without contracts. Content was governed; structure drifted.

The closed-release trap. Enterprise release trains have cars you cannot enter: when a release is being finalized for delivery, it is closed to changes. So you make your fix, you port it to the ten open releases, and the eleventh, closed today, gets nothing. When it reopens next cycle, there is no ledger anywhere that says a port is owed. You remember, or the change silently never arrives in that release. I forgot. Everyone forgets. The failure looks like human error, but it is designed-in: the system tracked every dependency between topics and none of the debts between branches. The git world proves this debt is trackable: backport labels and cherry-pick bots run it in public every day. To my knowledge, no structured-content system treats "downports owed to a closed branch" as a first-class object.

Notice what kind of failures these are. They are not usability failures; they are contract-management gaps: places where the system's own philosophy (structure everything, track everything) stopped short. That distinction is the whole argument of this essay, so let me now make it explicit.

Chrome and contracts

Everything a CCMS gives you divides into two piles.

The first pile is chrome: the windows, the toolbars, the tag pickers, the attribute forms, the wizards, the sixty icons, the click-paths you memorize. Chrome is how a human negotiates with structure through a screen. It is expensive to learn, slow to operate, and the reason a powerful system needs training courses and a support department.

The second pile is contracts: the topic templates that define validity, the metadata schemas that downstream systems consume, the dependency graph, the conditional structure, the phrase-level reuse library, the validators that reject a malformed release note before it ships. Contracts are why an enormous corpus stays coherent across a decade of releases, teams, and translation.

For thirty years these two piles have been sold as one product, and the industry's pricing, training economy, and consulting ecosystem all rest on the bundle. What my thirty-second table edit demonstrated, and what every technical writer quietly experimenting with an LLM is discovering, is that the bundle has come apart. A language model is a better interface to structured content than any window the industry ever built. It speaks intention ("make this a four-column table; respect the template") instead of mechanics (forty clicks). The chrome pile is dying.

The contracts pile is a different story, and my own workflow proves it from both directions. The edit worked because the template constrained the model. But my workflow was a hack: I carried fragments of source out of the system, edited them outside it, pasted them back in. The system's validation never saw the AI's work until afterward; I verified by hand, and re-finding the right place to paste an edited fragment into a large file was exactly where mistakes crept in. Every writer quietly running this loop is working the same way: the model and the contracts in separate rooms, with a person carrying paper between them. Fast, and unsafe, in precisely the way the old way was safe, and slow.

The vendors can see the same future at a distance. MadCap now markets IXIA CCMS as an AI-readiness platform. "Well-managed proprietary content is rocket fuel for AI" is their line, and it is correct. But look at where their AI sits. The AI Positron add-on puts assistant actions into the Oxygen editor: grammar checking, style suggestions, short-description generation, plus custom prompts a team can define. Useful, and telling: it is a writing aid living in the chrome. It helps the writer form better sentences; it does not yet edit structure under the template's constraints, assign metadata, or operate on maps. Their AI is aimed at the prose. The contracts are where it would count.

What the next generation of tools has to be is now easy to state: contracts and AI in the same loop. The model edits inside the system, with the whole document and its dependency graph as context, and validation runs on every AI edit before it lands, not after a human pastes it back and hopes. Templates stop being training material for writers and become guardrails for models. Metadata stops being a form to fill and becomes something proposed by the model and confirmed by the human, because assigning "changed / cloud-only / applies to feature X" is precisely the kind of bounded judgment models are good at and humans resent. The department that existed to operate chrome shrinks; the contracts that department enforced matter more than ever, because now two kinds of authors, human and machine, have to obey them.

The migration corollary

There is a second lesson from my years in this field, and it is about how organizations get from one system to another, because the AI wave is about to trigger a lot of migrations.

Any large content migration follows a pattern the DITA world knows well, and I have been on the writing side of one. The automated transfer is announced as the project, and then the real work begins. Content has to be verified, because conversion is never total: parts of the structure do not survive the move cleanly, and what does come across can carry small artifacts a human has to notice and resolve. The people who run these projects know this and plan for it. Even so, verification is the phase that tends to be underestimated, because it is diffuse work spread across a whole team while the transfer itself already looks finished.

The DITA ecosystem knows this pattern so well that it standardized it: the specification includes a <required-cleanup> element, formally defined as a placeholder for migrated elements "that cannot be appropriately tagged without manual intervention". An XML element whose meaning is "the migration gave up here." One migration consultancy puts it plainly: post-conversion cleanup is one of the most overlooked tasks in a DITA migration, and one of the most important.

So here is the principle I would carve over the door of every migration project, in either direction (into structure or out of it): the transfer is the easy part; the verification report is the product. A migration tool that moves 40,000 topics and prints "done" has done the easy half. The tool worth paying for produces the inventory: what moved, what did not, what changed shape, where every reuse link and conditional landed, and what a human still owes the corpus. I am building an open-source DITA-to-Markdown/MDX migration tool on exactly this principle (more on my stake in this below) because the coming wave of teams leaving heavyweight systems for AI-era stacks are about to re-run my migration story in reverse, and most of their tooling will print "done."

What survives

Let me say plainly what I believe follows, because most coverage of this space is written by people selling one of the two piles.

The heavyweight CCMS, as a product category, is in real trouble, not because its ideas failed but because its economics depended on the chrome. Training courses, certification, implementation consulting, the department that runs the system: all of it priced the interface, and the interface is the part AI deletes. What survives is the part that was always the point: enforceable templates, typed metadata, dependency tracking, conditional structure, governed reuse. Those are not enterprise luxuries. They are what made my thirty-second edit correct, and they are about to be what separates documentation that AI systems can reliably consume from documentation that merely looks clean.

The teams best positioned for the next decade are not the ones with the biggest system, and not the ones who fled structure entirely. The docs-as-code world is instructive here: the engineering-led corpora that make it work at scale do it by rebuilding contracts piecemeal: Vale rules, frontmatter schemas, CI link checkers, style linters. A CCMS reassembled one commit at a time, without the reuse machinery. That is not an argument against contracts; it is the strongest evidence that nobody escapes them. The winners will be the small, unglamorous teams that keep the contracts and let the machines work the interface.

I have skin in this game twice over: I still earn my living inside the old machine as a freelance technical writer, and I am building Topicary, a small structured-authoring tool that is my attempt at the contracts-with-AI-in-the-loop architecture: reuse, conditions, and validation without the Eclipse workbench, priced for teams that will never buy the big system. If you need full DITA specialization or a thousand-writer deployment, the enterprise tools remain the serious answer, and Heretto, Tridion Docs, and IXIA itself will serve you better. But if the last few thousand words described your daily life, or the future you suspect is coming for it, the thing to protect, whatever tool you choose, is the pile that survives.

Keep the contracts. Let the chrome die.