Bir PDF ya PDF/A-3’e uygundur ya da değildir. O zaman aynı dosyayı neden iki validator ile çalıştırsın ki insan?

Kısa cevap: spec yeterince büyüktür; iki doğru implementasyon edge’lerde farklı karar verebilir. Audit-grade workflow, tek motorlu “Pass” sonucunu yeşil ışık değil sarı ışık olarak görür. Uzun versiyon şöyle.

PDF/A tek bir algoritma değil, müzakere edilmiş kurallar stack’idir

PDF/A, birden çok ISO 19005 part’ı boyunca tanımlanır (PDF/A-1, PDF/A-2, PDF/A-3, PDF/A-4). Her birinde sub-conformance level’ları vardır (b, a, u, e, f) ve bunların tamamı underlying PDF specification (ISO 32000) üzerine inşa edilir. Birleşik yüzey alanı binlerce sayfalık normative text demektir.

Conforming implementation’ların tarihsel olarak ayrıştığı birkaç örnek:

PDF/A-2/3 içinde transparency: belirli koşullar altında allowed’dır; koşullar prosedürel yazıldığı için validator’lar check’i farklı implement eder.
Embedded color profiles: ICC profile ne zaman “required”, ne zaman “recommended”? Farklı validator’lar aynı dosyaya bu eksende “Pass” ve “Fail” diyebilmiştir.
PDF/A-3 içinde embedded file metadata: AFRelationship, /AF reference’ları ve embedded XMP; kurallar iyi specified olsa da enforcement strictness değişir.
Font subsetting: PDF/A tüm fontların gerçek encoding ile embedded olmasını ister. Partial subset içeren CID-keyed font edge case’leri validator disagreement üretmiştir.

Bunlar bug değildir. Complex specification’ın normative text’ten bağımsız ekiplerce implement edilmesinin doğal sonucudur. Conservative position, yani regulated industries’in çoğunun aldığı pozisyon, birden fazla bağımsız confirmation istemektir.

Reference engine + second opinion

veraPDF PDF/A’yı yayınlayan standards body olan PDF Association tarafından sürdürülen reference implementation’dır. Open-source’tur, industry working group’ları tarafından audited’dir ve rule set’i ISO 19005 metninin canonical interpretation’ıdır. veraPDF “Pass” diyorsa tek engine’den alabileceğiniz en güçlü sinyal budur.

Ama “strongest single-engine signal”, “audit-passing evidence” ile aynı şey değildir. Regulated institution’lardaki auditor’lar, yani bankalar, healthcare records archive’ları ve government records office’leri, sık sık ikinci bağımsız confirmation ister; çünkü:

veraPDF’in bir rule yorumu, auditee’nin içeride kullandığı başka validator’dan farklı olabilir ve downstream rejection’a yol açabilir.
Herhangi bir single engine’deki bug, reference engine bile olsa, aynı engine’i iki kez çalıştırarak tespit edilemez.
“İki bağımsız confirmation” procurement principle’ı compliance domain’lerinde yaygın uygulanır; PDF/A bu beklentiyi archival use case’lerinden miras alır.

Second-engine seçimi elde ne olduğuna bağlıdır:

Adobe Acrobat Preflight paid ve closed-source’tur; confirmation engine olarak iyi olabilir ama yeniden doğrulamayı kimin yapabileceğini sınırlar.
callas pdfaPilot paid ve de-facto enterprise choice’tur; yine independent re-verification’ı sınırlar.
İkinci bir open-source engine; birkaç tane vardır, çoğu veraPDF’ten daha az complete’tir.

gPdf’te yaptığımız şey, Rust + WebAssembly ile kendi engine’imizi bilinçli bir “independent re-implementation” olarak inşa etmekti: aynı spec, aynı kurallar, farklı ekip tarafından sıfırdan yazılmış. İki engine aynı dosyayı pass ettiğinde sonuç, tek başına herhangi birinden çok daha güçlüdür. Ayrıştıklarında ise investigation için net bir bug vardır: dosyada, engine’lerden birinde veya yorumda.

İki raporu tek URL’ye koyan validator

İkisini de gpdf.com/validator/ üzerinde host ediyoruz: ücretsiz, login yok, dosyayı veraPDF VE edge engine’imizden paralel geçirir, iki raporu yan yana döndürür. Use case’ler:

PDF/A üretip ship etmek istiyorsunuz: validator’a bırakın, ikisi de pass etsin, JSON report’ları QA evidence olarak attach edin. Bitti.
Bir engine fail eder, diğeri pass eder: elinizde precise bug vardır; report’ları diff edin, offending field’ı bulun. Çoğu zaman misaligned XMP timestamp veya PDF/A-3 içinde missing /AF reference gibi subtle bir şeydir.
İkisi de fail eder: dosya gerçekten broken’dır; source’ta düzeltin.
Incoming archive batch audit ediyorsunuz: randomly sampled PDF’leri bırakın, report URL’lerini loglayın, audit work paper’a attach edin. “veraPDF ve independent engine ile verified” claim’i, “vendor checker’ı çalıştırdık“tan daha güçlüdür.

Yüklediğiniz dosya request’ten ayrılmaz: engine’ler Cloudflare Workers üzerinde in-memory çalışır ve report render edildikten sonra dosya discarded olur. Login yok, persistence yok, quota yok.

Aynı pattern, genelleştirilmiş hali

Bu yalnızca PDF/A meselesi değildir. “İki bağımsız confirmation” pattern’i şunlara da uzanır:

Factur-X / ZUGFeRD e-invoices: gpdf.com/validator/, yukarıdaki PDF/A check’in yanında embedded EN 16931 CII XML için Mustang (mustangproject.org) çalıştırır. (Mustang ile ZUGFeRD doğrulama: ne pass eder, ne fail eder bu workflow’u anlatır.)
TLS certificates: her modern CA log’u birden çok monitor tarafından cross-check edilir.
Build reproducibility: aynı source’tan yapılan iki bağımsız rebuild byte-identical output üretmelidir.

Compliance dünyası bunu onlarca yıldır yapıyor. PDF/A sadece yetişiyor.

TL;DR

Single-engine “Pass” sarı ışıktır. Dual-engine “Pass” yeşildir. İki engine de validator üzerinde ücretsiz: dosyanızı bırakın, iki report alın, QA evidence’ınıza attach edin. Dosyayı gPdf ürettiyse validator, API’nin compliance claim’ini yerine getirdiğine dair public receipt’tir.

gPdf API üzerine build ediyorsanız, E-invoice API reference (§5) Factur-X / ZUGFeRD PDF/A-3’ün doğrudan nasıl emit edileceğini gösterir. Validator sonra bunu externally confirm eder. İki engine, tek upload; audit-grade pattern budur.