MX for PDFs.

An MX Compatible PDF is an ordinary PDF that also carries three things most PDFs do not: a tagged structure tree, an AI-governance provenance record, and the metadata that ties both to a published canon. The badge on the cover is the visible index entry for that evidence chain. You can verify every part of it from the file alone.

This page tells you what is in the file you have, why any regulator, AI agent, or screen reader can walk it the same way wherever it lands, and how to verify any of the claims yourself. The structure travels with the file: ship it from London, Frankfurt, New York, Sydney, São Paulo, or Bangalore and it carries the same evidence on arrival.

Which laws bite depends on where the file is read, not where it was written. The sharpest enforcement risk today is European, because the European Accessibility Act and the EU AI Act both carry fines large enough to fund the lawyers who chase them; treat those as the floor any publisher serving European readers has to clear. The same evidence answers the United States NIST AI Risk Management Framework, the UK ICO AI guidance, the Colorado AI Act, and the analogous instruments now appearing in other jurisdictions, so a publisher who builds for the European floor inherits the rest for free.

Note: This page describes regulatory frameworks in general terms only. Nothing here is legal advice. Requirements vary by jurisdiction, organisation type, and use case. Consult qualified legal specialists for guidance specific to your situation.

The QR code you scanned ends with a fragment of the form #mx:<hash>. That hash is the first eight characters of the source-content SHA recorded inside the document. It identifies which version of the source the PDF was rendered from. Anyone can match it back to the canonical source on disk or in the repository.

What this PDF carries

Three things, all machine-readable, all open by design.

A tagged structure tree

Inside the PDF, every heading, paragraph, list item, table cell, figure, and caption is recorded as a node in a logical tree. The tree follows ISO 14289-1, the international standard for accessible tagged PDF (PDF/UA-1), declared in the document's XMP packet under pdfuaid:part=1. A screen reader can walk that tree the same way a sighted reader walks the visible page: heading by heading, paragraph by paragraph, alt text on every figure. An AI agent reads exactly the same tree. The structure is the file; it is not reconstructed from pixels.

For comparison, an ordinary PDF carries only the visual rendering. The order of text in the file is the order the typesetter wrote it, not the order a reader would follow. A screen reader has to guess. An AI agent has to do vision-based reconstruction. Both are slower, less accurate, and more expensive than reading a tree that is already there.

AI-governance provenance

Adjacent to the PDF on disk, and embedded as a single XMP payload inside the PDF itself, is a pair of provenance records. The AI sidecar (file extension .provenance.ai.json) records every non-deterministic step that touched the document: large-language-model calls, multi-agent collectors, human-committed actions. It serves the AI-governance regimes that ask "what model produced this, on what input, under what prompt, with what audit trail": the EU AI Act, the UK ICO AI guidance, the United States NIST AI Risk Management Framework, the Colorado AI Act, and the analogous instruments now appearing in other jurisdictions.

The deterministic sidecar (.provenance.deterministic.json) lives next to it and records the rule-driven steps: gate verdicts, CSV checks, render steps, probe results. It serves the European Accessibility Act, Directive 2019/882, which entered into force on 28 June 2025 and asks "is this document conformant to the relevant accessibility standard, and what evidence supports that conformance".

Both sidecars cross-reference each other through a companion field. Together they form an evidence vehicle, not a compliance grant. Compliance with any law stays a legal duty of the organisation that publishes the file. What the records do is make the evidence the organisation must produce structured, machine-readable, tamper-evident, and verifiable on request.

Responsible Person Identifier

At the top of every sidecar (both the AI stream and the deterministic stream) sits a structured responsiblePerson block. It carries the name, email, identifier URL, role, organisation, and country of the human accountable for the audit chain. Any reader walking from a finding to the person responsible finds the full identifier in one step, without having to cross-reference an external directory or guess from a commit author. The block is the structured identity regulators look for under EU AI Act Article 4 (AI literacy obligations for providers and deployers), the UK ICO AI guidance accountability principle, the United States NIST AI Risk Management Framework GOVERN function (roles, responsibilities, and lines of communication), and EAA Directive 2019/882's responsible economic operator requirement.

The shape:

{
  "name": "Tom Cranstoun",
  "email": "tom.cranstoun@gmail.com",
  "identifier": "https://allabout.network",
  "role": "Audit operator and accountable individual",
  "organisation": "Digital Domain Technologies Ltd (trading as CogNovaMX)",
  "country": "GB"
}

Each field serves a regulator-facing question. name is the legal individual answerable for the audit; email is the direct contact channel. identifier is a stable URL that an auditor can resolve to verify the identity claim against an independent record (in this case the operator's own public-facing biography). role says in plain language what this person did in the audit chain. organisation names the legal entity behind the work, distinguishing the public brand from the registered company where the two differ. country is the two-letter ISO 3166-1 alpha-2 code that determines which jurisdiction's accountability rules apply.

The identifier travels with the file. A regulator who downloads the PDF, extracts the AI sidecar from the XMP payload, and reads the first six fields knows immediately who is accountable, where to reach them, and which jurisdiction governs the chain. There is no separate identity directory to consult and no email-address-from-commit-history reconstruction to attempt. The audit identifies its own author and stands behind the chain by name.

One single identifier is enough for the simplest audits. Real-world audits routinely involve more than one accountable party: a provider distinct from a deployer, an authorised representative for non-EU placements, a bias auditor for an employment system. The provenance JSON's v2 shape (from 2026-05-28 onwards) carries these as a parties[] array with a controlled role enum drawn from what regimes actually ask for: auditOperator, provider (EU AI Act Art. 16; Colorado developer), deployer (EU AI Act Art. 26; Colorado deployer), authorisedRepresentative (EU AI Act Art. 22 / Art. 54 for non-EU providers), importer, distributor, auditor (NYC Local Law 144 bias auditor; ISO 42001 internal audit), dataController, dataProcessor, dpo, modelDeveloper, modelEvaluator. The full canonical position on regime compatibility, what compatibility means, what it does not mean, which 30 regulatory regimes the chain currently serves as evidence for, and how an operator extends it for a new regime, is documented at provenance-regime-compatibility.md.

The MX metadata packet

The document's XMP metadata carries an MX namespace with twenty-plus fields that record what the file is, who wrote it, when, against what canonical source, with what intended audience, under what status. The fields draw from MX, an open, community-governed standard administered by The Gathering. The wire schema travels with the file: a tool that opens the PDF without ever visiting a network can still read provenance, intent, audience, and canonical pointers directly from the metadata. The structure survives mirroring, archiving, and re-distribution.

Why it matters

Two halves do the work. MX makes the content machine-readable: any system reading the file gets a complete, structured account of what it contains and how to use it. REGINALD, the registry for which CogNovaMX is the reference operator, makes the content machine-trustworthy: a signed attestation binds the file to a known publisher and a specific source hash, so a verifier can check that the document has not been altered since it was published.

The combined effect is that AI agents working from MX Compatible content cite attested facts rather than inferences. Hallucination rates drop. Inference cost drops by orders of magnitude, because the agent walks a tree it does not have to reconstruct. The documentation regulators require (under the EAA for accessibility, under the EU AI Act for high-risk AI systems, under the NIST AI RMF for risk management) becomes a structured by-product of how the file was built rather than a separate compliance artefact that has to be assembled by hand.

For a publisher, the upside is that the same metadata serves three audiences against the same fabric. Auditors walk from a regulatory clause to every decision that cited it via the policy-reference fields. Operational teams get a tamper-evident log of every action the file went through, sequence-numbered and signature-bound. Regulators verify each link with their own standard libraries: DID resolution, JCS, Ed25519, RFC 6962.

How to verify the claims

Everything in the file is open to inspection. Three commands cover most of the verification surface. Or drop the PDF on the interactive inspector and read every claim without the commands.

Check the structure tree

Confirm the PDF carries ISO 14289-1 tags:

qpdf --json file.pdf | jq '.objects[] | select(.["/Type"] == "/StructTreeRoot")'

If the result is non-empty, the document has a structure tree. Walk further into the tree to confirm tags map to logical content. The structure-tree presence and the /MarkInfo /Marked true declaration are the Level 1 conformance signal under the MX Document Accessibility note.

Read the conformance claim

Confirm the document declares PDF/UA-1 (ISO 14289-1):

exiftool -XMP-pdfuaid:Part file.pdf

A value of 1 indicates ISO 14289-1 (PDF/UA-1) conformance is asserted. The declaration is open to verification by any tool that walks the XMP packet.

Read the provenance chain

The AI provenance payload is embedded in the XMP packet under xmp:ProvenanceAiPayload:

exiftool -b -XMP-mx:ProvenanceAiPayload file.pdf | jq .

The -b flag is mandatory; without it exiftool prepends a label that breaks JSON parsing. The output is the full AI provenance chain: every step the document went through, the agent that took it, the input hashes, the outcome. The deterministic chain lives in the adjacent .provenance.deterministic.json file on disk, pointed to from the XMP under xmp:ProvenanceCompanion.

If you publish PDFs

The standard the badge points to is open. ISO 14289-1 tagged structure, the MX metadata schema, and the provenance pair are all published by The Gathering at tg.community, community-governed, and free to implement. Any publisher can adopt the pattern; any tool can produce a file that meets the same technical bar; other tools and registries can exist on the same standard.

The badge itself is reserved. The right to award and display the MX Compatible badge on a deliverable belongs to accredited MX practitioners, formally Certified Operators of the CogNovaMX Accreditation Programme. The programme runs in three tiers. Approved Operators self-attest on their own published work. Certified Operators issue third-party claims after methodology review and a sample-claim audit. Audit-Grade Operators sign regulated-scope claims, backed by professional indemnity insurance, independent peer review, and named-individual signing authorities. Admission is by application and audit, not by course or exam.

Separating the open standard from the restricted badge keeps two things true at once. The conformance pattern stays free for anyone to implement. The visible mark on a file stays accountable to a named human, a working address, and a registry entry a regulator can resolve. A reader who scans the QR code and walks the evidence chain back to the responsible-person block does not need to trust the publisher's word about who signed for the artefact; the accreditation record says so.

CogNovaMX operates the accreditation programme, the reference tooling at cognovamx.com, and the registry at reginald.allabout.network. The Gathering governs the open standard the programme is built on.

The point of the badge is that the file declares its claim and lets you check it.

Get a free MX-readiness check on your own PDF

Paste a public PDF URL and we will run the MX audit pipeline against it. You will receive a written report covering ISO 14289-1 tagged structure, MX metadata presence, AI-governance provenance, and explicit eligibility for the MX Compatible badge. No payment, no obligation. Reports go out within two working days.