Content standards, enforced
Your content standards expressed as machine-checkable rules, applied to a single Word document or an entire SharePoint repository, wherever content is written.
Spelling and grammar are not the problem
Factual correctness and the obvious surface-level errors are caught by reviewers and standard tooling. The defects that quietly accumulate underneath (and that catch you in an audit, a re-publication, or an AI pipeline) are structural. DxChecker enforces the rules a reviewer cannot keep in their head.
Terminology & vocabulary
Approved terms used consistently. Banned phrases caught at authoring time, not in legal review.
Structural consistency
Correct outlining, valid heading hierarchies, required sections present where they have to be.
Styling consistency
Style rules enforced, indent with the right style, not with spaces or tabs. Tables that meet the spec. No silent drift.
Formatting consistency
ISO date formats. Precise reference syntax for external sources. Citation patterns that survive a re-publication.
Links & cross-references
Internal and external links validated. Non-allowed targets blocked. Broken references caught before publication.
Metadata consistency
Required metadata applied uniformly across documents. The foundation for reuse, classification, and downstream AI.
Rules, rulesets and checks
Content quality rules are human-readable XML files, created and maintained by your content specialists or with help from external consultants. Each rule has an assert statement, optional auto-fix instructions, and a paper trail of creation and approval. Rules are assembled into rulesets, anywhere from one to several hundred rules per ruleset. When DxChecker runs, you choose which ruleset applies.
String
Literal-text rules. Example: not "e.g.,", but "e.g.".
RegEx
Pattern rules. Example: dates must be ISO. Not "10/11/23" but "2023-10-11".
XPath
Structural rules. Example: test for the actual Word styles used in the document, not just the visible formatting.
Links
Reference rules. Internal and external link validation. Block non-allowed targets. Catch dead URLs.
Validation
XML schema validation against an XML node in a Word .docx file or any XML file.
The same engine, three places it runs
DxChecker fits where the content lives: at the author's desk, across the repository, or inside the workflow.
DxChecker for Word
A modern Word add-in. The author drops a ruleset onto the document, hits Check, and sees rule violations grouped by category: string, regex, XPath, links. One-click fix where the rule supports it.
- Word 365 desktop
- Word 365 online
DxChecker Server
Scheduled or on-demand checking of a folder, a SharePoint library, or an entire repository against a ruleset. Reports surfaced where compliance and quality teams already work.
- SharePoint 365 online
- SharePoint 2019 on-prem
DxChecker API
Server-side checking inside any workflow that moves content: submission gates, publication pipelines, third-party integrations. Pass or fail a document against a ruleset before it is allowed downstream.
- REST API surface
- Pass/fail + diagnostics
Most content quality problems are also AI quality problems
The terminology drift, missing metadata and broken cross-references an auditor finds in review are the same defects that destabilize an LLM answer: retrieval picks up the inconsistent chunk, the model speaks from the wrong terminology, the agent follows the broken link.
DxChecker fixes the defects before they propagate. Content that has passed a ruleset check is content an LLM can quote without quietly going wrong.
Content with consequences
Rules and regulations
Where the published wording is the law.
Compliance documentation
Where an inconsistent label is a regulatory event.
Safety and security content
Where the wrong threshold causes harm.
Guides, specs & technical docs
Where a publishing portfolio reuses the same components across hundreds of variants.
Contracts and agreements
Where a clause changed in one document and forgotten in another creates legal exposure.
Legal content generally
Where consistency is structural, not stylistic.
Content comes in, lives in SharePoint, is written in Word, and is checked against your rules.
One place to look for each of the four jobs: bringing existing content in, managing and publishing it, writing it, and checking it against your rules.
DxMigrationTool
The content you already have, brought in as components.
- Imports Word, HTML, Markdown and text files
- Metadata captured, styling aligned
- Links and cross-references fixed
- Documents componentized into topics
Dx5
Content management and publishing inside Microsoft SharePoint.
- Browser-based topic-tree authoring
- Built-in approval workflows and snapshot capability
- One-click publishing: Word, HTML, XML
- Translation packages per language
DxAuthor+
Structured DITA authoring inside Microsoft Word.
- Word add-in, authors stay in the tool they know
- Topic tagging from SharePoint Term Store
- Cross-topic linking with SharePoint search and preview
- Single sign-on through Entra ID
DxChecker
Rule-based content quality across the SharePoint repository.
- Configurable rule sets: your standards as machine-checkable rules
- Runs at authoring time, on schedule, or via workflow
- Controlled-language enforcement (ASD-STE100 and equivalents)
- Roadmap: deeper DxAuthor+ integration; AI-supported content rules
Frequently asked questions
Does DxChecker flag problems while the author is typing?
No. Today it is a check that gets run. An author applies a ruleset in Word and gets the violations back, or the server runs a ruleset across a library on a schedule, or a workflow calls the API before content is allowed downstream. Rules running continuously inside the DxAuthor+ writing experience, and rules written in natural language rather than in XML, are roadmap items and not shipping capabilities.
We have a style guide, not a rule set. How does one become the other?
By starting with the deterministic part of it. Date formats, approved and prohibited terms, reference syntax, required metadata and heading structure can all be tested. Anything that reads as a matter of judgment stays with the reviewer, where it belongs. In practice the first ruleset is built from the style guide you already have, run against a real document, and grown from there, rather than specified in full before anything is checked.
Does DxChecker replace review?
No. A rule can test a string, a pattern, a structure, a link or a schema. It cannot judge whether the threshold in a safety warning is the right threshold, and nothing in the product pretends otherwise. What it removes is the mechanical class of defect, the drifted term and the dead cross-reference, so that review time is spent on meaning instead of on formatting a human should never have been asked to police.
Can DxChecker fix what it finds?
Some of it. A rule can carry auto-fix instructions, and where it does, the violation arrives with a correction the author can apply in one click. Where it does not, the finding is reported and a person decides. Rules also carry their own record of creation and approval, which matters when a check is what stands between a document and publication. There is no unattended sweep that rewrites a repository by itself.
Does DxChecker only work on Word documents, or across the whole repository?
Both, with one engine. It checks a Word file, an XML node inside a Word file, or any XML file, and it runs across a folder or a SharePoint library, on SharePoint Online or SharePoint Server 2019, on a schedule or on demand. Controlled-language specifications such as ASD-STE100 run this way, alongside your own terminology rules.
See DxChecker run a ruleset against your own document
The fastest way to evaluate DxChecker is to point it at a real document and a draft ruleset. We will help you build the ruleset from your existing style guide and run the first check together.
