The DITA completeness check is the quality gate that reads your whole repository at once — well-formedness, conformance to your DTD, broken links, unresolved conrefs and keyrefs, missing images, duplicate ids, tables whose grid does not add up, and circular maps — and hands back findings your team can act on line by line. Whether the DITA came from a conversion, a migration or a transformation, DITA validation at repository scale is what turns "probably fine" into proven-complete before anything ships.
A conversion is only as trustworthy as your ability to prove it is complete. Convert ten thousand topics and the question your CCMS will ask is unforgiving: does every link resolve, every conref find its target, every keyref bind, every image exist, and does every map avoid a circular chain? Checking that by hand, or one file at a time in a desktop editor, does not scale to a real repository. That is the job of the DITA completeness check — full DITA validation across the entire repository at once, reported in a form your team and your release process can actually act on.
Validation failures are cheap to find and expensive to ignore. An unresolved conref that slips through does not announce itself — it surfaces as a blank space in a published PDF, a dead link in an online help portal, or a rejected import into a CCMS that refuses the whole batch because of a single duplicate id. By then the cost includes a failed publish, a support escalation and a customer who no longer trusts the deliverable. At migration scale, hope is not a strategy: you need certainty that the output is not merely well-formed but referentially complete against your own DTD before it ships, not after a reader finds the gap.
An unresolved reference never announces itself — it waits until it is a blank page in front of your customer.
This is not a format conversion; it is validation that reads an entire DITA repository and tells you exactly what is wrong and where. It performs the complete set of checks a documentation team relies on: XML well-formedness, DTD validation against the standard DITA grammar or your own, broken links and cross-references between the files of the publication, conref resolution — including whether the element a conref pulls in is of a type the referencing element can accept — keyref binding, image and resource references that must genuinely exist, duplicate ids and keys, and maps that reference one another in a circle. References marked external or peer are deliberately left alone, so the check stays anchored to what your own publication can break. And it does two things no grammar ever can. CALS tables are checked as arithmetic, not just markup: a cell that overflows the declared column count, two cells claiming the same grid position, a morerows span running off the end of its section, a namest or nameend naming a column no colspec declares — the classic conversion damage that validates perfectly and still renders as nonsense. Then, once the whole map has been walked, every file in the package the map never reaches is reported too, so orphans do not ride quietly into your CCMS.
The difference is scale, and what you get back. Your repository is checked in a single run rather than opened topic by topic, at a size that comfortably covers the largest documentation estates — and a full pass is fast enough to repeat after every round of fixes, so the second and third passes keep pace with the people doing the fixing. The findings are built to be acted on rather than admired: one report, one line per finding, each naming its severity, its file and line, its category and what is wrong, worded the way your editor would put it — a format a human reads top to bottom and a pipeline parses without ceremony. Duplicate keys are reported with the definition that wins under DITA precedence, so the fix is informed rather than guessed. And the run's exit status is the gate itself: errors fail it, warnings never do, so validation becomes a straight pass or fail on the way to release rather than a suggestion.
| Your concern | How the completeness check answers it |
|---|---|
| Our writers already validate as they author. | The same checks, re-engineered for the whole repository and an unattended pipeline — every file in one run, a pass fast enough to repeat after every fix, and results as data rather than an on-screen list one person reads. |
| We have thousands of topics. | The corpus is validated in a single run, at a scale that comfortably covers the largest documentation estates. |
| Generic DITA is not enough — we have a specialization. | Point it at your own DTD — specializations included — and it enforces your constrained model and required elements instead of only the standard one. |
| How do we act on the results? | Every finding is one line — severity, file and line, category, message — so it routes straight to the author who owns it and drops straight into a tracker. |
| Can it block a bad build? | Errors fail the run — the exit status is the gate — so a real problem stops the release instead of shipping quietly. |
A generic run validates against the standard DITA model and confirms your output is well-formed, internally consistent and referentially complete — a strong baseline. A customer-specific run validates against your DTD instead — specializations included — so the check enforces your constrained content model and your required elements: the rules your CCMS will enforce on import anyway.
The distinction is the difference between "this is valid DITA" and "this will load into our CCMS without rejection." Suppose your house specialization forbids a plain topic and requires every file to be a concept, task or reference, each with a populated short description in the prolog. A generic check passes all of it. A customer-specific check flags every topic missing its required elements and every construct your constrained model forbids — precisely the set of issues that would otherwise bounce your batch import and turn into reactive cleanup after go-live. Validating against your own DTD before delivery turns all of that into a single report you clear before you ship.
Most DITA teams already trust a completeness check of some kind — inside an editor, on the project a writer happens to have open. That is precisely its limit: it is interactive, desktop-sized and human-in-the-loop, never meant to gate a DITA conversion of ten thousand topics running unattended. DocentraX takes that same trusted set of checks and re-engineers it for the repository and the pipeline: the whole corpus in one run, fast enough to re-run in full after every fix, and — the real difference — findings that arrive as located, actionable data instead of a list on a screen that somebody has to transcribe. It also checks what the desktop pass never does: CALS table grids validated as arithmetic, and a sweep for the files your maps never reference at all. That is what lets it sit at the end of every conversion, and after every Content Convergence reuse pass, as an automatic release gate rather than a manual afterthought.
With the DITA completeness check as your gate, "done" stops being a judgment call. Every conversion output — whether it came from Flare, Word, FrameMaker or a Content Convergence reuse pass — is proven complete against your own DTD before it reaches your platform. Broken references are caught at the source, located to the line, and routed to the author who owns them. Builds fail loudly on real problems instead of shipping quiet gaps. And because the whole thing runs unattended at repository scale, quality assurance keeps pace with migration volume instead of becoming the bottleneck that stalls it.
It is a validation pass that confirms a DITA repository is well-formed and referentially complete — checking conformance to your DTD, broken links, conref and keyref resolution, image references, duplicate ids and keys, table structure, and circular map chains. Every finding names its file and line, so the problem is fixed at the source instead of hunted for.
It runs the same checks, re-engineered for the whole repository and an unattended pipeline. Your entire corpus is validated in one run instead of file by file, a full pass is fast enough to repeat after every round of fixes, and the findings come back as located, actionable data your team and your build can use — not an on-screen list one writer reads.
Yes. Point the check at your own DTD — specializations included — and it enforces your constrained content model and required elements, the same grammar your CCMS enforces on import, instead of only the standard DITA model.
Yes. Errors fail the run and warnings never do, so the result is a clean pass or fail your build acts on directly — and a full pass is fast enough to repeat after every round of fixes, so DITA validation keeps pace with an automated conversion pipeline instead of becoming its bottleneck.
A single findings report: a header with per-run totals, a per-category tally, then one line per finding — severity, file and line, category, and a message worded the way your editor would put it. That line-per-finding format reads top to bottom for a human and parses trivially for a pipeline, and the run's exit status says pass or fail.
We'll convert them to DITA free of charge — through the real pipeline, not a demo — and review the output with you. Then we'll discuss pricing one-to-one.
Request your free sample conversion