Validation

At a glance

NextPDF Enterprise runs in-process, read-only structural checks for named policies: PDF/A-4, PAdES baseline, Long-Term Validation (LTV) health, ZUGFeRD, U.S. Food and Drug Administration (FDA) 21 CFR Part 11, and U.S. Securities and Exchange Commission (SEC) 17a-4. It returns a structured technical report.

Availability & licensing

This capability ships in NextPDF Enterprise (nextpdf/enterprise) and activates with an Enterprise-tier license envelope. A deployment without that entitlement does not load the capability’s classes. Compare editions and get a license.

Install

composer require nextpdf/enterprise:^3

Conceptual overview

Compliance is the entry point. Call Compliance::assess($pdfBytes, $policy) (or inject an instance and call run()) to apply one CompliancePolicy to the PDF bytes and receive a ComplianceReport. The policy defines the work; the report gives the structured result.

Policies provides pre-built policy factories: pdfA4(), pdfA4e(), pdfA4f(), padesBaseline(), eidasQualified(), ltvHealth(), zugferd($profile), fdaPart11(), and the SEC 17a-4 family (sec17a4(), sec17a4Compatible(), sec17a4Structural(), sec17a4PreSign()). Each factory returns a CompliancePolicy whose validate() method is pure: PDF bytes in, findings out. The architecture enforces a strict read-only boundary: a policy never mutates PDF bytes, so validation stays separate from any auto-fix behavior.

ComplianceReport groups findings by Severity (Error, Warning, Info). passes() returns true when there are no errors; warnings do not fail a report. The report includes a built-in legal disclaimer (getDisclaimer()) that states the result is a technical structure check for reference only and that qualified legal or compliance professionals make the final determination. You must surface that disclaimer in user-facing output.

A second boundary matters for signatures. LtvHealthCheck checks the structural presence of the Document Security Store (DSS) under ISO 32000-2:2020 §12.8.4.3; it does not cryptographically verify embedded Online Certificate Status Protocol (OCSP) or certificate revocation list (CRL) data. eidasQualified() validates PAdES structure at the PDF level only; actual eIDAS qualification depends on the trust service provider (TSP) and qualified certificate, which are outside this module.

What “validation” means here

This module checks structural attributes and reports findings.

• Conformance is a property of the final file plus a validator, not of this library. ISO 19005-4:2020 §5.2 determines conformance against the standard’s normative requirements through a checking tool, not through the producing software.
• A passing report is a checked result against the rules that each policy implements.
• FDA 21 CFR Part 11 and SEC 17a-4 policies check structural attributes implied by the regulations (signature presence, signing intent, audit-trail markers, write once, read many (WORM) constraints).

Tier boundary

• NextPDF Core Compliance ships byte-stream validators and a grammar cross-check; a zero-finding result is a checked result, not a certificate.
• NextPDF Pro Compliance (EInvoiceValidator) validates EN 16931 / Factur-X / ZUGFeRD in process at the e-invoice layer.
• NextPDF Enterprise Validation (this page) adds pre-built policies for archival, signature, LTV, and regulated-industry structural checks (FDA Part 11, SEC 17a-4) with one report format. The Enterprise Compliance module is a separate surface that delegates to external sidecars; this module runs in process.

Why it works this way

Validation is built as a set of pure, read-only policies, not a fix-and-report pipeline. Each policy’s CompliancePolicy::validate() takes PDF bytes and returns findings; it never edits the document. So a passing report is never an artifact of the tool quietly “helping” the input pass. It means only that the file was checked against the rules each policy implements. That same boundary is why every report carries a built-in disclaimer, and why conformance stays a property of the final file plus an external validator. The module reports structure and stops there.

Design background: Compliance you can hand to an auditor.

API surface

Class	Responsibility
Compliance	Entry point: applies one policy and returns a report.
Policies	Factory for pre-built CompliancePolicy instances.
CompliancePolicy	Contract: pure validate() returning findings.
ComplianceReport	Findings grouped by severity; carries the legal disclaimer.
ComplianceFinding	One finding: rule id, message, standard reference, remediation.
Severity	Error / Warning / Info.
PdfAPolicy	PDF/A-4 family structural policy.
PadesValidator	PAdES baseline / eIDAS structural policy.
LtvHealthCheck	DSS structural-presence check (ISO 32000-2 §12.8.4.3).
ZugferdValidator	ZUGFeRD / Factur-X PDF-level policy.
FdaPart11Policy	FDA 21 CFR Part 11 structural-attribute policy.
Sec17a4WormPolicy	SEC 17a-4 WORM structural policy (selectable strictness).

Code sample — Quick start

use NextPDF\Enterprise\Validation\Compliance;
use NextPDF\Enterprise\Validation\Policies;

$report = Compliance::assess($pdfBytes, Policies::pdfA4());
$ok = $report->passes(); // no errors

Code sample — Production

$report = (new Compliance($clock))->run($pdfBytes, Policies::fdaPart11());

foreach ($report->errors as $finding) {
    $logger->warning('validation.error', [
        'rule'     => $finding->ruleId,
        'standard' => $finding->standardReference,
    ]);
}
$auditLine = $report->getDisclaimer(); // surface this in user-facing output

Edge cases & gotchas

• Warnings never fail a report; only errors set passes() to false. A clean report still means “checked against implemented rules”, not “compliant”.
• LtvHealthCheck confirms DSS structure, not cryptographic revocation validity.
• eidasQualified() checks PDF-level structure only; qualification depends on the TSP and certificate.
• The SEC 17a-4 family provides selectable strictness (Full / Compatible / Structural / PreSign); choose the one that matches your workflow stage.

Performance

Each policy runs in process over the supplied PDF bytes; cost scales with document size and rule count. Compliance records the run duration in the report.

Security notes

Policies parse PDF bytes in process and never call out. Treat PDF bytes from untrusted sources as hostile; the pure read-only architecture prevents a policy from altering the input.

Data residency & PII mitigations

Validation is in-process and local, with no network I/O. Signed documents and audit-trail metadata may carry personal data; apply your own retention and minimization controls to reports and findings.

Safe telemetry & log scrubbing

Findings include rule ids, standard references, and messages; some messages echo signer names or reason strings extracted from the PDF. Scrub or redact those fields before forwarding logs to shared sinks.

Conformance

Behavior	Reference	Status
Conformance determined against the standard, not the producer	ISO 19005-4:2020 §5.2	Reflected in design (read-only policies)
DSS structural presence for LTV	ISO 32000-2:2020 §12.8.4.3	Checked (structure only)
PAdES baseline structure	ETSI EN 319 142-1 §5.4.3	Checked (PDF-level)
EN 16931 profile semantic model	Factur-X 1.08 (EN 16931)	Supporting reference (issuer remains responsible)
FDA 21 CFR Part 11 / SEC 17a-4	21 CFR Part 11 / 17 CFR 240.17a-4	Structural attributes checked; not legally verified

This table records what each policy checks and the specifications behind that policy. The FDA and SEC rows are structural-attribute checks only.

FIPS-mode behavior

These policies do not verify PDF digital signatures, certificate chains, OCSP/CRL responses, or legal qualification; any SHA-256 audit-trail digests they compute are tamper-evidence checks, not signature verification. The Signature and Security modules handle cryptographic signature validity, key custody, and Federal Information Processing Standards (FIPS)-mode behavior.

Threat model

The primary input is untrusted PDF bytes. Mitigations include pure read-only policies (no mutation, no auto-fix), no network I/O, and an explicit legal disclaimer on every report.

Behavior contract

• Each policy’s validate() is a pure function: PDF bytes in, findings out. It never mutates the input; the architecture keeps a strict read-only boundary separate from any auto-fix behavior.
• The report groups findings by severity; passes() returns true when there are no errors, and warnings never fail a report.
• Every report carries a built-in legal disclaimer stating that the result is a technical structure check for reference only; you must surface that disclaimer in user-facing output.
• The LTV health check confirms DSS structural presence only; it does not cryptographically verify embedded OCSP/CRL data.
• The eIDAS-qualified policy validates PAdES structure at the PDF level only; actual qualification depends on the trust service provider and certificate, outside this module.

Publication boundary

This page documents externally observable behavior and the supported public API surface only. Internal namespace paths, helper classes, mechanism tables, runbook filenames, and ticket prefixes are out of scope.

Core fallback

NextPDF Core Compliance ships byte-stream validators and a grammar cross-check; a zero-finding result is a checked result, not a certificate. The pre-built archival, signature, LTV, and regulated-industry policies with one report format have no Core-tier equivalent.

Pro fallback

NextPDF Pro Compliance validates EN 16931 / Factur-X / ZUGFeRD in process at the e-invoice layer. It does not provide the pre-built PDF/A-4, PAdES, LTV, FDA Part 11, or SEC 17a-4 structural policies; those ship in the nextpdf/enterprise package only. The Enterprise Compliance external-sidecar surface is a separate module.

Enterprise boundary note

The entry point, policy factory, and report are described at the behavior level. The per-policy rule internals and any internal classification detail are out of scope for the public surface. Cryptographic signature validity is deliberately not in scope here; the Signature verification verify-side and the Security modules handle it.

Deployment boundary

Validation runs in process and locally, with no network I/O; a policy cannot alter the input. The operator treats PDF bytes from untrusted sources as hostile, surfaces the report disclaimer in user-facing output, and owns retention and minimization controls for reports and findings, which may carry personal data from signed documents and audit-trail metadata.

See also

• Compliance — external validator sidecars (distinct surface).
• Evidence — sealed, timestamped report packages.
• Core Compliance — in-process byte-stream validators.
• Signature verification — cryptographic CMS / timestamp / archival-chain verify-side (distinct from this structural surface).
• Specifications: PDF/A-4 — referenced standard.
• Validation — Deep Reference — per-policy rule internals and full class reference.