Um PDF está conforme PDF/A-3 ou não está. Então por que alguém rodaria dois validadores no mesmo arquivo?

Resposta curta: porque a especificação é grande o bastante para duas implementações corretas discordarem nas bordas, e um fluxo com nível de auditoria trata um “Pass” de motor único como sinal amarelo, não verde. Aqui está a versão longa.

PDF/A é uma pilha de regras negociadas, não um único algoritmo

PDF/A é definido em várias partes da ISO 19005 (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4), cada uma com níveis de subconformidade (b, a, u, e, f), e cada uma delas construída sobre a especificação PDF subjacente (ISO 32000). A superfície combinada tem vários milhares de páginas de texto normativo.

Alguns exemplos de onde implementações conformes historicamente divergiram:

Transparência em PDF/A-2/3: permitida sob condições específicas; as condições são escritas de forma procedural, e validadores diferentes implementam a checagem de formas diferentes.
Perfis de cor embutidos: quando um perfil ICC é “obrigatório” versus “recomendado”? Validadores diferentes já chamaram o mesmo arquivo de “Pass” e “Fail” nesse eixo.
Metadados de arquivo embutido em PDF/A-3: AFRelationship, referências /AF, o XMP embutido — as regras são bem especificadas, mas a rigidez de enforcement varia.
Subsetting de fontes: PDF/A exige que todas as fontes sejam embutidas com sua codificação real. Casos de borda em fontes CID-keyed com subsets parciais já causaram divergências entre validadores.

Isso não são bugs. É a consequência natural de uma especificação complexa implementada por equipes independentes a partir de texto normativo. A posição conservadora — e a posição adotada pela maioria dos setores regulados — é exigir múltiplas confirmações independentes.

O motor de referência + a segunda opinião

veraPDF é a implementação de referência mantida pela PDF Association — o órgão de padrões que publica PDF/A. É open-source, auditado por grupos de trabalho da indústria, e seu conjunto de regras é a interpretação canônica do texto ISO 19005. Se o veraPDF diz “Pass”, esse é o sinal mais forte que você consegue de um único motor.

Mas “sinal mais forte de um único motor” não é o mesmo que “evidência que passa em auditoria”. Auditores em instituições reguladas — bancos, arquivos de prontuários de saúde, órgãos públicos de registros — frequentemente exigem uma segunda confirmação independente porque:

A interpretação do veraPDF sobre uma regra pode diferir de outro validador usado internamente pelo auditado, levando a uma rejeição downstream.
Um bug em qualquer motor único (mesmo o de referência) não pode ser detectado rodando esse mesmo motor duas vezes.
O princípio de procurement “duas confirmações independentes” é amplamente aplicado em domínios de conformidade; PDF/A herda essa expectativa de seus casos de uso de arquivamento.

A escolha do segundo motor depende do que está disponível:

Adobe Acrobat Preflight é pago e closed-source — funciona como motor de confirmação, mas limita quem pode reverificar.
callas pdfaPilot é pago e a escolha enterprise de fato, mas também limita reverificação independente.
Um segundo motor open-source — existem alguns, em geral menos completos que o veraPDF.

O que fizemos no gPdf foi construir nosso próprio motor em Rust + WebAssembly como uma “reimplementação independente” deliberada — mesma especificação, mesmas regras, escrito do zero por outra equipe. Quando os dois motores aprovam o mesmo arquivo, a conclusão é muito mais forte do que qualquer um deles sozinho poderia oferecer. Quando discordam, você tem um bug claro para investigar (em um deles, ou no arquivo).

O validador que coloca ambos em uma URL

Hospedamos os dois em gpdf.com/validator/ — grátis, sem login, roda o arquivo pelo veraPDF E pelo nosso motor edge em paralelo, e retorna os dois relatórios lado a lado. Casos de uso:

Você gerou um PDF/A e quer enviá-lo: solte no validador, ambos passam, anexe os relatórios JSON como evidência de QA. Pronto.
Um motor falha e o outro passa: você tem um bug preciso — compare os relatórios e encontre o campo ofensivo. Muitas vezes é algo sutil, como timestamp XMP desalinhado ou referência /AF ausente em PDF/A-3.
Ambos falham: o arquivo está realmente quebrado; corrija na origem.
Auditoria de um lote de arquivo recebido: solte PDFs amostrados aleatoriamente, registre as URLs dos relatórios e anexe ao papel de trabalho da auditoria. “Verificamos com veraPDF e com um motor independente” é uma afirmação mais forte que “rodamos o checker do nosso fornecedor.”

O arquivo que você envia nunca sai da requisição — os motores rodam em memória no Cloudflare Workers e o arquivo é descartado depois que o relatório é renderizado. Sem login, sem persistência, sem quota.

O mesmo padrão, generalizado

Isso não vale só para PDF/A. O padrão de “duas confirmações independentes” se estende a:

E-invoices Factur-X / ZUGFeRD: gpdf.com/validator/ roda Mustang (mustangproject.org) para o XML CII EN 16931 embutido, junto com a checagem PDF/A acima. (Validando ZUGFeRD com Mustang — o que passa, o que falha cobre esse fluxo.)
Certificados TLS: todo log moderno de CA é verificado por múltiplos monitores.
Reprodutibilidade de build: duas reconstruções independentes a partir da mesma origem devem produzir saídas byte a byte idênticas.

O mundo de conformidade faz isso há décadas. PDF/A está apenas alcançando esse padrão.

TL;DR

“Pass” de motor único é sinal amarelo. “Pass” em dois motores é verde. Os dois motores estão gratuitos no validator — solte seu arquivo, receba dois relatórios e anexe à sua evidência de QA. Se o gPdf gerou o arquivo, o validador é o recibo público de que a API cumpriu a promessa de conformidade.

Se você está construindo sobre a API do gPdf, a referência da E-invoice API (§5) mostra como emitir Factur-X / ZUGFeRD PDF/A-3 diretamente. O validador confirma externamente depois. Dois motores, um upload — esse é o padrão com nível de auditoria.