If you search for “document management” you’ll find hundreds of products. SharePoint, Google Drive, Dropbox, Box, M-Files, DocuWare. They all do roughly the same thing: store files, control access, and track versions. For most office documents, this is fine.

But there’s a category of document that these systems weren’t designed for: documents that are assembled from reusable parts, where the same content appears across multiple files, and where a change to one section might need to propagate to dozens of others. Specifications, compliance documents, contracts with standardised clauses, technical manuals.

For these, you need something different. The software industry has a name for it: a component content management system, or CCMS. We call what SpecTacular does “document composition,” which is a specific application of the same principle.

What document management actually does

A document management system (DMS) operates at the file level. It stores a Word document or PDF as a single object. It can tell you when the file was last modified, who modified it, and which version you’re looking at. It handles check-in/check-out so two people don’t edit the same file simultaneously. It manages permissions so the right people can access the right files.

Before DMS platforms existed, teams were emailing files back and forth, saving copies on local drives, and losing track of which version was current. A shared, managed repository solved a real problem.

What a DMS cannot do is look inside the file. It doesn’t know that section 4.2 of your specification contains a safety clause that also appears in twelve other specifications. It can’t tell you which projects reference a particular standard. And when that standard changes, it can’t help you find every document that needs updating.

As TransPerfect’s analysis of DMS vs CCMS puts it: a DMS “focuses on content at the file level rather than the essence of the content itself.”

What document composition does differently

A document composition system manages content at a level below the document. Instead of storing whole files, it stores components: individual sections, clauses, requirements, procedures. These components are versioned independently and can be assembled into documents without being copied.

This is a well-established approach in technical publishing. Wikipedia’s entry on component content management systems describes it as managing content “at a granular level rather than at the document level, where each component represents a single topic, concept or asset.”

The difference shows up when content is reused. In a DMS, reuse means copy-paste. You take a section from one document, paste it into another, and from that point on the two copies are independent. They’ll drift apart over time, and there’s no systematic way to keep them in sync.

In a composition system, reuse means referencing. Multiple documents point to the same component. Update the component, and you can see which documents use it and decide which ones should receive the change. The connection between the source and its uses is maintained.

Where the line gets blurry

Some DMS platforms have added features that move in this direction. SharePoint has content types and metadata. Some enterprise CMS platforms support content fragments or reusable blocks. The line between categories isn’t always sharp.

The practical test is: can the system answer these questions?

Which documents contain this specific clause?
If I update this section, which projects are affected?
Which version of this requirement is each project currently using?
Can I update a section in some projects but not others?

If the answer to most of these is no, you’re working with a document management system, regardless of what features have been added on top. If the system can answer them natively, it’s operating at the component level.

Why the distinction matters

For teams that produce standalone documents (reports, memos, proposals that don’t share content), a DMS is the right tool. The file is the natural unit of work, and file-level version control is sufficient.

For teams that produce families of related documents, where standardised content is reused across projects and needs to stay consistent, file-level management creates problems that get worse over time. Every new project adds more copies of the same content, each independently maintained, each potentially drifting from the others.

This isn’t a theoretical concern. The construction industry has well-documented problems with specifications assembled from copy-pasted fragments of previous projects. The pharmaceutical industry recognised the same pattern and adopted CCMS platforms to manage regulatory content at the component level.

Choosing based on how your documents actually work

The question isn’t which type of system is “better.” It’s which one matches the structure of your documents.

If your documents are mostly independent of each other, a DMS handles them well. If your documents share content and regulatory changes need to cascade through multiple projects, then you need a system that manages content below the file level.

Most teams don’t frame the choice this way. They search for “document management,” find a DMS, and adopt it because it’s the category they know. The shared content problem persists because the tool they chose doesn’t address it, and they assume the manual workarounds (copy-paste, naming conventions, tracking spreadsheets) are just how it’s done.

They’re not. There are systems built for this. They just live in a different category.