Nine CMS Platforms, One Structural Question: What Happens When You Change Your Taxonomy Later? Three Have a Real Answer — Six Don't.

We checked Kontent.ai, Sitecore, Adobe AEM (Sites + Assets), Storyblok, RWS Tridion, Contentful, Hygraph, Contentstack, and Optimizely against 19 structural capabilities — from taxonomy depth to component-level provenance to pattern versioning — using nothing but each vendor's own public documentation and a five-tier evidence scale. Five capabilities turned out to be true of every vendor, and one turned out to be true of none. The sharpest gap: what happens to already-classified content when you change your taxonomy. Three vendors have a documented answer — the other six's own docs admit they don't, or stay silent.

Where this fits in the whole system

The Content Value Chain is a dependency structure, not a menu of options — each layer is built on the one before it, from diagnosing what's broken (Diagnosis) through to sensing and reacting to the market (Market Environment). Seven layers, sixteen named components between them — each component is one specific, book-chapter-sized piece of a content operation, like "Brand LLM / AI Brand Governance" or "Universal Taxonomy."

Every report we publish picks one component and breaks it into a handful of specific, testable capabilities — concrete claims like "does this platform enforce brand rules while content is being generated, or only after" — then checks every vendor's own documentation against each one. A highlighted component below has at least one published report; the rest are components we haven't researched yet, not components that don't matter. Altogether, the framework breaks down into 103 specific, testable capabilities spread across 13 of its components — the ones where "does this product do X" is a fair, checkable question. Two more categories work differently: Failure Modes Map and Market Environment are diagnostic and market-context lenses rather than product capabilities, so they're part of the framework but never vendor-graded the same way. Any single report only ever covers one component's worth of that — a handful of capabilities, checked against a handful of vendors — which is what this map is actually tracking: how much of the 103 is covered so far, and how much is still ahead.

This report is entirely about the highlighted layer — whether a CMS makes content genuinely reusable is a Structural Infrastructure question, not a control or governance one. It assumes the System Model above it (why you'd want a value chain at all) is already understood, and it's a precondition for everything above it in the stack — Control Systems like Brand LLM can't enforce rules on content that was never structured to be governed in the first place.

How we chose these nineteen, and what they're not

These nineteen capabilities aren't a checklist assembled from vendor marketing pages or analyst reports. They come from the book itself: Chapter 5 gives Universal Taxonomy its structure, Chapter 9 gives Atomic Content three defining properties, and Chapter 10 gives Pattern Library its full card — intent, structure, variables, constraints, validation rules, version, and ownership. We restated all nineteen as something a product either verifiably does or doesn't do, then checked every vendor's documentation against them. A taxonomy built from what vendors already sell would just describe the market back to itself; this one comes from the framework's own architecture, and vendors either match it or don't.

That also means this isn't exhaustive. These nineteen are the specific claims the book makes about what structural content infrastructure actually requires — not a complete inventory of every CMS feature. A vendor can have real strengths (visual editing, personalization, commerce integrations) that don't appear here at all, because they're not what these three components are about. And a vendor with real gaps here can still be the right choice for a team whose priorities sit elsewhere.

That's the difference from a feature comparison. A feature comparison starts from a vendor's own list of what it sells and checks a box when the feature exists. This starts from what the book argues has to be true for content to actually be reusable, independent of how any vendor names or packages it — which is why every primitive is named by function, never by a vendor's product name for it. A box only gets checked here when a vendor's own documentation — not its marketing copy — actually backs that specific claim. In the full report, every grade links straight to that documentation.

The matrix

Key: V = Verified · C = Vendor-claimed · I = Inferred · U = Unknown. Grades as of the 2026-09-24 expanded research pass.

Licensed, Enabled, Practised

Explore the full research library →