Consolidation as an assembly step
Consolidated texts are built from approved components at the moment they are requested, so the version a citizen reads and the version an inspector cites are the same one.
Government & regulators
A regulator publishes content for a living. Treat it as the product
Rules, guidance and consolidated texts are the output of a rule-maker, not a by-product of it, whether the rule-maker is a public agency, an exchange or a standards body. They are amended continuously, cited by everyone downstream, and expected to be authoritative on the day they change. The question is whether the publishing chain can keep pace without a manual consolidation exercise every cycle.
ApprovedComponent v3
68% Reuse rate
The structural problem
Amendment is continuous, publication is not
A regulator's corpus is never finished. Rules are amended, guidance is reissued, and consolidated versions have to exist for every point in time somebody might need to cite. Handled as documents, each amendment triggers a manual consolidation pass: find every place the changed text appears, edit it, re-check the cross-references, republish the portal, and hope nothing was missed.
The cost is not the drafting. It is the sweep afterwards, repeated every cycle, and the exposure that comes with it. A rule published in two versions with two different wordings is a regulatory problem, not a formatting one.
Where it hurts
Long rules, many reviewers, and readers who want data
The same pattern holds for rule-makers outside government: exchanges writing market rules, standards and certification bodies, and primes issuing requirements their suppliers must follow. A small drafting team writes for a large review population and a larger downstream audience.
| Where it hurts today | What changes |
|---|---|
| A rulebook of 700 to 1,000 pages where fixing one place leaves 500 others uncertain | Each rule is written once and reused by reference, so a change is made in one place and every edition that uses it follows. |
| Drafts of 200 to 300 pages sent to 50 or more reviewers who comment everywhere | Reviewers comment in Word on the components they own, and each comment stays attached to the rule it concerns. |
| Stakeholders asking for rules as data rather than PDF | Every rule carries a unique ID, so it can be extracted, tracked and compared between editions, and published to PDF, Word, HTML and XML from one source. |
| Rule writers who will not learn an XML editor | They keep writing in Microsoft Word. EASA's rule officers declined XML editor training and asked for the same capability in Word, which is the request DitaExchange was built to answer. |
What changes
One approved statement, every downstream surface
When the unit of management is the rule statement rather than the document, an amendment is approved once and every consolidated version, portal page and downstream feed draws from it. The publishing step becomes assembly instead of reconciliation.
Provenance on every statement
Who approved this wording, under which amendment, on what date. Component-level version history answers it without reconstructing the trail from email and rendered PDFs.
Drafting stays in Word
Rulemaking officers and policy staff are subject matter experts, not XML authors. They keep working in Microsoft Word while the structure is applied underneath.
Portals fed from the source
Public access formats are outputs of the same component library, so a portal refresh is a publication event rather than a separate content project. EASA's Easy Access Rules is one example.
The consolidated text is the hard part
An amendment is easy to draft and expensive to publish: every consolidated version, portal and citation has to reflect it the same day. When the rule is a component, consolidation becomes an assembly step.
See the regulatory-affairs view
In production with
EASA
European Union Aviation Safety Agency. Publishing European aviation regulations on DitaExchange since 2018, the platform behind the eRules program and the Easy Access Rules format.
European Defence Agency
EU agency coordinating defense capability development across member states.
Canadian Nuclear Safety Commission
Canadian Nuclear Safety Commission
Federal regulator for Canadian nuclear energy and materials. Publishes Canadian nuclear safety regulations on DitaExchange, one of the most documentation-intensive regulatory environments in any sector.
LSEG
London Stock Exchange Group. A rule-maker outside government: its rules and regulatory documentation run on DitaExchange.
Frequently asked questions
A 300-page draft goes to fifty reviewers and comes back with comments everywhere. Does this help?
It changes where the comments land. Reviewers comment in Word on the components they are responsible for, so each comment stays attached to the rule it concerns and to the version it was made against. The drafting team works through comments rule by rule instead of reconciling fifty marked-up copies of the whole document. The number of reviewers does not go down. The reconciliation work does.
A tribunal asks for a rule as it stood on a particular date. Can that be produced?
It can, where the amendment history sits on the rule statement rather than on the file that carried it. Snapshot capability fixes an approved state as a version, so the text for a given date is produced rather than rebuilt from what looks plausible. A public body cannot argue about what it published. It can only show it.
Rules cite other rules. What happens to the cross-references when a provision is renumbered?
References are held as content keys that resolve at publishing time, so a pointer follows its target instead of naming a paragraph number that has since moved. Broken-link and orphan detection run as configurable rule-based checks across the corpus, which turns cross-reference decay from something a reader finds after publication into something the system reports before it.
Downstream systems want the rules as data rather than as PDF. Is that a separate project?
It is a publishing target. Components are DITA XML, and the same library that produces a consolidated text and a portal page can be read over REST endpoints by the systems that need it. The consumer reads the approved component instead of scraping a rendered page, so what it shows changes when the rule changes rather than when somebody remembers to scrape again.
We have twenty years of rules and guidance in Word files. Where does a program like this start?
With two human decisions: which document set goes first, and what the topic model looks like. DxMigrationTool then applies that model to the files, reading Word, HTML, Markdown and text, capturing metadata, aligning styling and repairing links. It is not a bulk conversion that runs unattended. Existing documents still have to become components, and the shaping is editorial work with tool support.
We need a public website platform as well. Does this replace the web CMS?
No. Dx5 manages the regulated content and publishes to the channels that consume it. It is not a web content management system. Where the requirement is one engine running the public site and the structured content together, and the site is Adobe Experience Manager, AEM Guides publishes directly into AEM Sites and is the honest choice for that. Otherwise keep the two roles apart.
Start with the corpus that is amended most often
Public-sector implementations start where the consolidation pain is worst: one rule set, one guidance series, one access portal. Then build outwards, once the amendment cycle has been through it.
