Your file says it’s PDF/A. That was three tools ago.

We treat conformance as something a file has. It is closer to something a file was given by the last piece of software that wrote it, and it can be taken back just as quietly.

A certificate, not a state

Somewhere in most document workflows there is a validation step. A file is checked against ISO 19005 or ISO 14289, a validator returns a pass, and the result is recorded. From that moment the document is treated as conforming, and the record is treated as durable.

The mental model underneath is a certificate. The file was inspected, it complied, and compliance now travels with it the way a serial number does.

That model contains one specific error. It assumes the file that was validated is the file that will eventually be read. Between those two events, most documents are opened, compressed, merged, split, rotated, converted to an editable format, converted back, and saved again, by a sequence of programs nobody recorded, none of which was asked whether it understood what it was carrying.

Every save is a rewrite

It helps to be precise about what happens when software writes a PDF.

Most tools do not modify a PDF in place. They parse the document into an internal representation, apply whatever change was requested, and serialize a new file from that representation. The output is not the input plus an edit. It is a new document, assembled from whatever the tool's internal model was able to hold.

Anything that model has no representation for does not survive. It is not removed by a decision anyone made. It is simply never written back. The structure tree, the XMP packet, embedded files, output intents, optional content configurations, the attributes that make a table a table rather than a grid of positioned text: each of these survives only if the writing implementation was built to carry it.

The failure is silent by construction. A tagged document that passes through a tool with no concept of logical structure comes out looking identical. Same pages, same fonts, same layout, smaller file. Nothing in its appearance records what left.

There is one exception, and it is instructive. A digital signature breaks loudly: change the bytes and the viewer says so, in red, to the next person who opens the document. The signature is not better protected than the structure tree. It is simply the only conformance property that ships with an alarm attached. Everything else fails the same way, without one.

The claim outlives the property

Here the problem becomes something worse than loss.

A PDF/A file announces itself through XMP metadata, a small packet at document level stating the part and the conformance level. A PDF/UA file does the same. That packet is document metadata, and document metadata is exactly the kind of thing implementers are careful to preserve, precisely because it looks like the part you are not supposed to lose.

So the common outcome is the inverse of the one you would want. The operation strips the structure and keeps the declaration. What comes out is a file that states it is PDF/A-2u and is not.

Downstream, nothing objects. An archive ingests the document, reads the identification, files it as conforming, and moves on. No error is raised, because nothing looked. The claim has quietly become the evidence for itself.

This is not a hypothetical failure mode. veraPDF, the industry-supported PDF/A and PDF/UA validator, ships a metadata fixer whose documented behaviour includes removing PDF/A or PDF/UA identification from the XMP of documents that carry it but do not conform to the flavour they declare. A tool exists to strip false conformance claims because false conformance claims are common enough to justify building one.

The dangerous operations are the ordinary ones

There is a temptation to file this under advanced processing, something that happens deep inside pipelines, run by people who should know better.

It is the opposite. The operations that break conformance are the most common operations performed on PDFs anywhere: compress, merge, split, rotate, convert, export. They run constantly, on ordinary machines, outside any document management system, performed by people who have no reason to know that a structure tree exists and no way to see one if they did.

Merging two tagged documents requires reconciling two structure trees into a single coherent hierarchy. An implementation that concatenates page content without reconciling structure produces a file whose tags no longer describe one document’s reading order. Splitting can extract pages whose structure elements have parents left behind in the source. A round trip through an editable format is a reconstruction rather than a recovery: the returning file contains what the converter inferred, not what the original held.

Each of these operations has a correct implementation, and good ones exist. That is not the point. The point is that correctness here is invisible at the moment of use. The person compressing a report sees a progress bar and a smaller file. Nothing tells them which kind of tool they just used, and the file will not tell the next reader either.

Conformance is a chain property

If conformance is something tools produce rather than something files hold, three things follow.

Validate at the point of use, not the point of creation. Whether a document conformed when it was made is a historical question. Whether it conforms now is the operational one, and only one of the two can be answered by looking at the file in front of you.

Treat identification metadata as a claim rather than a finding. The XMP packet states what some earlier tool believed. Any workflow that reads it and proceeds is trusting the last program in a chain it cannot see.

Ask what a tool preserves, not what it supports. “Supports PDF/A” describes an export mode: what the software can produce when asked directly. The more useful question is what happens to a conforming file that goes in and comes out for some entirely different reason.

Two decades of standards work have gone into describing the artifact with increasing precision. ISO 19005 specifies what a file must contain to be preservable. ISO 14289 specifies what it must contain to be accessible, a layer whose readership has since grown well beyond the one it was written for. ISO 32000-2 specifies the format itself across hundreds of pages.

None of them describes the handoff. A standard can say what a conforming file looks like. It cannot say what the next program will do with it. That gap is not a small residue at the edge of the ecosystem. It is where almost every document actually spends its life.