PDF либо соответствует PDF/A-3, либо нет. Тогда зачем кому-то запускать два validators на одном и том же файле?

Короткий ответ: потому что спецификация достаточно велика, чтобы две корректные реализации расходились на пограничных случаях, а audit-grade workflow относится к single-engine “Pass” как к желтому свету, не зеленому. Ниже — подробная версия.

PDF/A is a stack of negotiated rules, not a single algorithm

PDF/A определен через несколько частей ISO 19005 (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4), каждая с sub-conformance levels (b, a, u, e, f), и все они строятся поверх базовой PDF specification (ISO 32000). Combined surface area — несколько тысяч страниц normative text.

Примеры мест, где conforming implementations исторически расходились:

Transparency in PDF/A-2/3: разрешена при конкретных условиях; условия описаны процедурно, и разные validators реализуют check по-разному.
Embedded color profiles: когда ICC profile “required”, а когда “recommended”? Разные validators называли один и тот же file “Pass” и “Fail” по этой оси.
Embedded file metadata in PDF/A-3: AFRelationship, /AF references, embedded XMP — rules хорошо определены, но enforcement strictness varies.
Font subsetting: PDF/A требует, чтобы все fonts были embedded с actual encoding. Edge cases вокруг CID-keyed fonts с partial subsets вызывали validator disagreements.

Это не обязательно bugs. Это естественное следствие complex specification, которую independent teams реализуют по normative text. Conservative position — и позиция большинства regulated industries — требовать multiple independent confirmations.

The reference engine + the second opinion

veraPDF — reference implementation, поддерживаемая PDF Association, standards body, который публикует PDF/A. Это open-source engine, audited by industry working groups, и его rule set — canonical interpretation of the ISO 19005 text. Если veraPDF говорит “Pass”, это самый сильный signal, который можно получить от одного engine.

Но “strongest single-engine signal” не равен “audit-passing evidence”. Auditors в regulated institutions — banks, healthcare records archives, government records offices — часто требуют second independent confirmation, потому что:

Interpretation rule в veraPDF может отличаться от другого validator, который auditee использует internally, и это приведет к downstream rejection.
Bug в любом single engine, даже reference, невозможно найти, запустив тот же engine twice.
Procurement principle “two independent confirmations” широко применяется в compliance domains; PDF/A наследует это expectation из archival use cases.

Выбор second engine зависит от доступности:

Adobe Acrobat Preflight paid и closed-source — нормальный confirmation engine, но ограничивает independent re-verification.
callas pdfaPilot paid и de-facto enterprise choice, но также ограничивает independent re-verification.
A second open-source engine — есть несколько, обычно менее complete, чем veraPDF.

В gPdf мы построили собственный engine на Rust + WebAssembly как deliberate “independent re-implementation”: та же spec, те же rules, написано from scratch другой team. Когда оба engines pass один file, conclusion гораздо сильнее, чем любой engine отдельно. Когда они disagree, у вас есть clear bug to investigate (в одном из них или в file).

The validator that puts both on one URL

Мы размещаем оба engine на gpdf.com/validator/ — бесплатно, без login. File проходит veraPDF AND наш edge engine параллельно, а result возвращает оба reports side-by-side. Use cases:

You generate a PDF/A and want to ship it: drop into the validator, both pass, attach the JSON reports as QA evidence. Done.
One engine fails, the other passes: у вас precise bug — diff the reports, find the offending field. Часто это subtle mismatch вроде XMP timestamp или missing /AF reference в PDF/A-3.
Both fail: file genuinely broken; fix at the source.
Auditing an incoming archive batch: drop randomly-sampled PDFs in, log the report URLs, attach to the audit work paper. “We verified with veraPDF and an independent engine” — stronger claim, чем “we ran our vendor’s checker.”

Uploaded file never leaves the request — engines run in-memory on Cloudflare Workers, and the file is discarded after the report is rendered. No login, no persistence, no quota.

The same pattern, generalized

Это не только про PDF/A. Pattern “two independent confirmations” extends to:

Factur-X / ZUGFeRD e-invoices: gpdf.com/validator/ runs Mustang (mustangproject.org) для embedded EN 16931 CII XML, alongside PDF/A check above. (Validating ZUGFeRD with Mustang — what passes, what fails covers that workflow.)
TLS certificates: every modern CA log gets cross-checked by multiple monitors.
Build reproducibility: two independent rebuilds from the same source should produce byte-identical outputs.

Compliance world делает это десятилетиями. PDF/A просто догоняет.

TL;DR

Single-engine “Pass” — yellow light. Dual-engine “Pass” — green. Оба engines бесплатны на validator — drop your file, get two reports, attach to your QA evidence. Если file generated by gPdf, validator становится public receipt, что API delivered on its compliance claim.

Если вы строите на gPdf API, E-invoice API reference (§5) показывает, как emit Factur-X / ZUGFeRD PDF/A-3 directly. Validator затем подтверждает это externally. Two engines, one upload — audit-grade pattern.