The Inspector You Can Audit Yourself

The free version

The PDF inspector at mx.allabout.network/tools/pdf-inspector.html takes one file at a time. Drop a PDF on the page and a browser-side parser reads its tagged structure tree, its XMP metadata packet, and its embedded AI-governance provenance record if one is present. It then classifies the file into one of three tiers: MX Compatible, EAA Tagged Only, or Plain. The PDF never leaves your machine; the parser ships from the same site that hosts the page; the inspection is a conversation between the file and your browser.

That covers the single-file case. The operator case is different.

What an operator actually needs

An accredited operator producing PDFs for clients does not want a one-at-a-time browser tool. They want the same check running inside their own pipeline, against every artefact, on every build, with a non-zero exit code when something falls below the bar. They want it integrated into their existing CI surface so a misconfigured render breaks the build, not a meeting two weeks later when a client notices the badge claim does not match the file.

The MX PDF Inspector CLI is that. The same detection core the public inspector uses, packaged as a command-line tool for accredited operators and their pipelines.

# Single file
npx mx-pdf-inspect report.pdf

# Directory tree, recursive
npx mx-pdf-inspect ./deliverables/ --recursive

# CI mode: JSON output to a pipeline log
npx mx-pdf-inspect ./build/*.pdf --json > inspection.json

# Looser bar (accept EAA-tagged files, not just full MX Compatible)
npx mx-pdf-inspect report.pdf --min-tier eaa-tagged

Exit codes are CI-clean. Zero when every fixture meets the configured minimum tier, one when at least one fixture is below the bar, two on a fatal error. Drop it into a build step and the build does the work the operator would otherwise be doing by hand on a sample.

Four surfaces, one detection core

The inspector lives in four places, and they all read from one file.

The public page at mx.allabout.network/tools/pdf-inspector.html is the surface most visitors meet first. Browser-side parse, no upload, no third-party CDN call at inspection time. The same detection logic runs in this browser as in every other surface.

The production gate at scripts/bin/mx.pdf.sh calls the harness as a hard step after every canonical render in our own pipeline. If the inspector would not certify the freshly-rendered PDF as MX Compatible, the build fails non-zero and nothing ships. Our outbound work is gated by the same check we tell operators to run.

The test harness at tests/test-pdf-inspector.js runs the harness against a gold-standard fixture on every npm test. A regression in the detection core fails the test, fails the production gate, and fails the public inspector for every visitor, in the same way and on the same line.

The operator CLI at scripts/bin/mx-pdf-inspect.js is the same code with a command-line UI, available to accredited operators for their own pipelines.

All four import the detection core at mx-outputs/mx-site/js/pdf-inspector-core.js. One file. Browser and Node both load it the same way. A change to the core fails every surface in lockstep; a fix to the core repairs every surface in lockstep. No drift between the rule we publish and the rule we enforce.

Why a CLI and not a hosted service

Two reasons, both deliberate.

The PDFs an operator wants to verify are usually confidential. Draft contracts. Unpublished audit reports. Regulatory submissions. Board papers. A hosted service requires uploading the file to a third party; a CLI runs locally, sees no network, and leaves no trace outside the operator's own environment. That matches the property the public inspector advertises ("the file never leaves your machine") and extends it to the CLI surface.

The verification step also belongs in the operator's pipeline, not in ours. A CI-grade check that runs every time a PDF is built is worth more than a manual check that runs occasionally. Accredited operators integrate the CLI as a hard gate in their build. The operator's own infrastructure carries the rule. We did not write a service that gives operators an answer; we wrote a tool that lets them produce the answer themselves.

Why accreditation is the qualifier

The CLI is gated to accredited operators because the value it produces is contextual.

Anyone can run a verifier. What they cannot do is sign and stand behind the resulting claim in a way that holds up under inspection. The CLI does not issue claims; it inspects. But the phrase "every PDF we ship was certified by this tool" carries weight in proportion to whether the operator running it is someone whose other certifications mean something. The same way an ISO 17025 lab's instruments are coupled to the lab's accreditation, the inspector's findings carry the weight of the operator standing behind them.

For accredited operators, the CLI is one of the working tools the accreditation buys. For everyone else, the public inspector covers the single-file case for free. The pricing structure for the seed phase bundles CLI access with active accreditation in every tier; renewal of the accreditation renews access. Details on the Certified Operator page.

Three audiences

Three groups have asked for this, in declining order of immediate demand.

Tier 2 and Tier 3 accredited operators. Consultancies, agencies, and audit firms issuing third-party MX Compliance Claims on behalf of clients. The CLI runs in their CI on every PDF they produce, so the claim text and the published artefact agree by construction. The client can re-verify the same artefact in the public inspector and reach the same conclusion, because the same detection core runs both surfaces.

Tier 1 in-house compliance teams. Publishers, regulated-sector communications teams, government departments running their own publication pipeline. The CLI gates internal releases. The public inspector is the external proof.

Procurement and oversight reviewers. Buyers checking that supplier deliverables meet contracted accessibility and AI-governance standards. The CLI gives them a CI-integrable way to verify supplier claims at intake, before payment, without depending on the supplier's own infrastructure or a hosted third-party service. Same rule, same code, executed on the buyer's side of the boundary.

Credibility by mechanism, not by claim

Three things have to line up before a PDF is what its producer says it is. The page must say so. The pipeline must enforce it. The check must be runnable by anyone with the file. All three exist in the open here.

The inspector page makes the claim. The production gate enforces it. The test harness proves it. The CLI lets operators do the same in their own pipelines, against their own files, on their own infrastructure. For the AI-governance regimes increasingly requiring evidence-chain documentation (the EU AI Act, the European Accessibility Act, the AI risk-management instruments emerging in adjacent jurisdictions), this is what "evidence-vehicle" looks like in working form. Not "trust us, we did this carefully" but "here is the file, here is the rule, here is the check, run any of them yourself, decide for yourself."

The mechanism is the credibility. That is why we run every PDF through this tool, why the tool runs in your browser when you ask it to, and why the same tool is now available to operators whose work depends on the answer being checkable by anyone holding the file.

Get the CLI

The CLI is bundled with active accreditation in every tier of the Certified Operator programme. Join the waitlist for the next admission cohort, or get in touch if you are running a procurement review and want a non-accredited evaluation copy. The pricing schedule on the Certified Operator page is indicative for the seed phase; the published commercial terms apply at admission time.

For the conceptual background on what the inspector actually checks, the explainer at MX for PDFs is the walk-through. For the single-file case, the public inspector needs no further setup.