Worked example
From a filled-in form to a PDF you can check
Every step below produced a file that is on this page. The form is staged; the document at the end of it is the one the pipeline actually built.
Why this page has files on it
Software that generates documents is easy to demonstrate and hard to verify. A screenshot proves nothing about the file, and a live form you cannot inspect proves only that something came back.
So the evidence is here instead of the demonstration. Pick a document, read the input it was built from, and download two things: the PDF, and the validator's report on it. You can run your own validator against the same file and compare.
Pick a document
Three of the document types XDAP builds. The fields are the input contract; the file underneath is what came out of it.
A periodic electrical inspection under NEN 3140, written by the inspector on site and issued as a fixed record.
PDF/A-4f + PDF/UA-2
A written appointment under the Dutch VIAG rules, naming a person, a scope of work and the installations it covers.
PDF/A-4f + PDF/UA-2
The assignment that goes with the appointment: what the named person may be given to do, and under which appointment.
PDF/A-4f + PDF/UA-2
This form is an example. The fields are filled in and cannot be edited, and nothing on this page sends anything anywhere. The PDFs and the validator reports are real files, built by the pipeline this page describes.
About these examples
The example documents are in Dutch because the rules they encode are: NEN 3140 for the inspection report, the VIAG rules for the appointment and the assignment that goes with it. The pipeline itself is not language-bound; these examples are.
They are templates, not copies of documents issued to anybody. Nothing on this page came out of a client engagement, and the parties in them are invented for that reason — which is also what the specimen marking on each file is there to say.
The conformance level stated with each file is the one that file delivers, and no more. PDF/A-4f covers archiving and embedded files. PDF/UA-2 asserts that the document has a structure a screen reader can navigate, and there is a separate validator report for each — a file claiming two standards and publishing one report is publishing the easier half.
These files carried a structure tree before they carried real headings, and the validator passed them anyway. It cannot require a heading a document never claims to have. So the tree was read rather than trusted, and three things were fixed before anything was declared: the document class was not tagging its sections, two of these templates set their title as large bold text rather than as a heading, and the findings table marked its header row as ordinary cells. Passing a validator and being navigable are not the same claim, and only the second is worth making.
Documents the platform itself issues carry a detached signature beside them, so a recipient can establish where a file came from and that it has not changed by a byte. The key that makes that checkable is published on this site rather than only on the platform, because a key served by the same machine that served the document proves nothing.
The example files above are not signed. They were built here, for this page, rather than issued by the platform, and saying otherwise would be the one dishonest sentence on a page about verifiability.
Want this for your own documents?
Tell us which document you issue most often and what has to be true of it. That is enough to say whether this fits.