Any vendor can run a backlog through a converter and hand back a folder of files. The question that survives a complaint is narrower: for this document, what proves it conforms?
Every document we remediate is validated against PDF/UA-1 by veraPDF — independently, on the output file, after the repair. It passes, or it goes back to the department that owns it with the reason named. There is no third answer.
2024-BOARD-AGENDA-PACKET.pdf
VERDICT RECORDED AGAINST THE OUTPUT FILE
This is the artifact attached to every document we return — not a summary we wrote, but the validator's own report on the file you receive.
// the actual risk
Bulk remediation goes wrong in a specific way, and it is almost never the volume.
A pipeline runs. Nothing throws an error. Ten thousand files land in the output folder and the job is reported as complete. Months later a complaint arrives about one of them, and nobody can answer the only question being asked — what was actually checked on this file, and by what?
The failure mode is subtle because it looks like success. A tagging engine that marks real text as decorative satisfies a naive checker while hiding that content from every screen reader. A remediation step that "completed" tells you the code ran, not that the document conforms. Those are different claims, and only one of them is worth anything in a records request.
So we built the pipeline the other way around. The remediation step is not permitted to declare its own success. An independent validator decides, reading the file that was actually produced.
“A repair is not finished because the pipeline ran without throwing. It is finished because an independent validator says the output conforms.” — DepartmentPipelineWorker, our own source comments
// the gate
veraPDF is the open-source reference validator for PDF/UA (ISO 14289-1), built by the veraPDF Consortium under the EU's PREFORMA programme. It is the same tool an auditor, a plaintiff's expert, or a state accessibility office would reach for. We run it as the gate rather than as a marketing claim.
The verdict is read back from the produced file. Never inferred from what the remediation step reported, never carried forward from the baseline scan. The file you receive is the file that was validated.
Every failing clause is named by number. Not "accessibility issues remain" but 7.21.4.1, font program not embedded — a specific sentence in a published ISO standard that a person can look up and check our work against.
We read the warnings, not just the verdict. A validator's pass/fail is a filter, and anything it does not rule on is invisible to anyone who only reads the headline. Our verification captures the validator's parser output alongside its verdict, because a file can be formally compliant and still be telling you something is wrong with it.
A conformance failure is not permitted to become a silent pass. If a document does not validate after remediation, it does not quietly ship. It moves to a named outcome — our queue, the department's queue, or blocked at source — and stays visible until somebody resolves it.
Re-running what cannot change is not a strategy. Certain failures are produced by deterministic steps: given the same input they produce the same output, so a second attempt is arithmetic guaranteed to reach the same answer. We identify those and escalate them instead of billing you to fail twice.
The standard is the product. Everything else is how we get there.
// the pipeline
The same five steps run on every file in the inventory, whether that is forty documents or forty thousand. Each step records what it did, so the history survives the job.
STEP 01
Each document is retrieved from its published location — the live URL on the department's site, so what we assess is what the public actually receives.
STEP 02
veraPDF runs on the file as received, before anything is changed. This is the before-picture, and it is what tells you how much of your inventory was already fine.
STEP 03
The repair path is chosen per document, not per batch. A well-authored file gets targeted deterministic fixes; a file with no usable structure gets a full rebuild of its tag tree.
STEP 04
veraPDF runs again, independently, on the output. This is the gate. Nothing is recorded as remediated without a verdict from this step.
PASS OR ESCALATESTEP 05
The conformant file is stored and handed back with its validation report, its repair path, and its full run history attached.
// five outcomes, no others
This is deliberate. "How much of our backlog was already fine, how much was cheap to fix, how much was expensive, and how much was never ours to fix" is the report a department actually needs — and it cannot be reconstructed after the fact.
Outcome 01
The document validated clean on arrival. We do not touch it, and we do not bill it as remediation work. Knowing this number is often the single most useful output of a baseline scan — it is usually larger than departments expect.
YOU GET → Baseline report, file untouched
Outcome 02
The document has real structure, with specific defects — ragged table rows, untagged vector graphics, header cells missing scope, fonts referenced but not embedded. Each repair is conditional on finding something wrong, so it is a no-op on the parts that were already correct.
YOU GET → Conformant file + report
Outcome 03
The document has no usable structure, or carries tagging so wrong it has to be replaced. Reading order, headings, tables, lists, and figures are derived from the page itself and a new tag tree is built — then held to the same validator as everything else.
YOU GET → Conformant file + report
Outcome 04
Some things cannot be fixed downstream without inventing content — a form field with no label anywhere on the page, a decision only the author can make. We refuse to guess. It goes to the department that owns the content with the specific question attached, and it is tracked as theirs, not as work we are sitting on.
YOU GET → Named action for the owner
Outcome 05
The file is damaged in a way no amount of retrying resolves: corrupt glyph mappings that carry no recoverable text, encryption, a damaged source, or a page count past the tagging budget. This is a different answer from "we tried and it did not work," and we report it as one.
YOU GET → Diagnosis + what it needs
The point
The outcome that does the damage is the one that reads as success without being one. Every document here carries a disposition someone can defend in a meeting, and the ones we could not fix are labelled as such rather than folded into a completion percentage.
RESULT → A defensible record
// the honest limit
We lead with veraPDF because it is the strongest evidence available. It is not evidence of everything, and a vendor who implies otherwise is selling you a number rather than an outcome.
Alt text is the clearest example. PDF/UA clause 7.3 requires only that alternative text be present and non-empty. A photograph of a council meeting described as "Image" passes. It is formally conformant and useless to the person it exists for.
Form field labels have the same shape. A field needs an accessible name; the standard cannot tell whether the name matches the box it is attached to. A confidently wrong label sends a screen-reader user to the wrong field, which is worse than no label at all.
So these do not get counted as verified. Image descriptions and generated field labels are written to a review queue with the image crop beside them, for a person who knows the content to confirm, correct, or reject. Rejections are deliberately not written into the file — leaving a description a reviewer called wrong would announce it to every screen reader, and blanking it would mark real content decorative. A rejection stays outstanding work for a human.
Where machines generate, we require agreement. Field labels are derived twice, by two independent strategies with different blind spots — one reads the caption nearest a single field, the other reads the whole page for section context. Where the two agree, the label is written. Where they disagree, the field is queued with both candidates stored, so a reviewer clicks rather than retypes.
That costs volume on purpose. Fewer labels are written automatically than a looser rule would produce. It is the correct trade when the failure mode is a confident, wrong answer.
Conformance and accessibility are not the same claim. We report them separately because they fail separately.
// what you can hand to counsel
Remediation you cannot evidence is remediation you will have to argue about. Each document carries its own history, per attempt, permanently.
The validator's verdict on the file as received, and on the file as delivered. The delta is the work, stated in the standard's own terms.
Every rule that failed, with its ISO clause and test number and the count of failed checks — not a severity score we invented.
Already conformant, targeted repair, full rebuild, sent to the owner, or blocked — recorded at the time, because it cannot be reconstructed later.
An attempt that crashed still happened. Runs are closed out honestly rather than left open, so the history reflects what occurred.
Who accepted, corrected, or rejected each generated description or label, and when. The review trail is part of the record, not separate from it.
The same record aggregated by department, so remediation debt sits with the office that owns the content and can prevent the next batch.
// how to compare vendors
Including us. These are the dimensions where bulk remediation quietly differs, and none of them show up in a per-document count.
| The question | Common answer | SentraCheck |
|---|---|---|
| Is the validator's verdict kept per document? | Automated PDF/UA validation is widely advertised — but the per-file report is often not retained, so "validated" is a property of the process rather than of the document in your hand. | The veraPDF report is produced against the output file, stored with that document, and handed over with it. You can re-run the same open-source tool and get the same answer. |
| What happens to files that can't conform? | Folded into a completion percentage, or returned with a generic failure note. | A distinct outcome with the blocking cause named, routed either to us or to the department that owns it. |
| Is alt text counted as verified? | Yes — non-empty alt text passes the validator, so it counts. | No. Descriptions and field labels go to human review with the image beside them. Conformance and usefulness are reported separately. |
| Can you show the before state? | Often not retained once the batch is processed. | Baseline validation is run and stored before anything is modified. |
| What does a failed attempt look like? | Retried silently, or absent from the report. | Recorded as an attempt with its outcome. Failures that a retry cannot change are escalated rather than repeated. |
| Who owns the remaining work? | Unassigned — it returns to the agency as an undifferentiated list. | Tracked per department, so the office that produced the document is the office that sees the gap. |
// questions
veraPDF — the reference validator for PDF/UA (ISO 14289-1) — runs on the output file after remediation, and its verdict is read back from that file. Not from what our remediation step reported, and not from the baseline. The validator's own report travels with the document.
It is recorded as blocked, with the cause named: corrupt glyph mapping, an encrypted file, a damaged source, or a page count past the tagging budget. Some of these are only fixable at the source — re-exporting from the original application, or adding a text layer. You get that diagnosis rather than a failure notice, because it tells the department what to do next.
Because some gaps can only be closed by whoever owns the content. A form field with no caption anywhere on the page has no correct label to derive — inventing one would produce a file that validates and misleads. Routing it back is the honest answer, and it puts the fix where it also prevents the next batch.
It means it is conformant, which is the strongest objective evidence available and the thing regulators and courts reference. It does not mean every image is well described or every label is right — no validator can assess that. That is exactly why those items go to human review instead of being counted as verified.
It starts with a baseline scan of your published inventory, which costs you nothing and produces the split you need before scoping anything: how many documents are already conformant, how many need targeted repair, how many need a full rebuild, and how many are blocked at source. Scope and pricing follow from that mix, and we quote on it directly — not per page.
Documents are assessed at their published URLs, so the inventory is whatever the public can actually reach — no export step, and no dependence on a particular CMS. Remediated files come back for you to publish through your normal process.
Structure recognition on the full-rebuild path uses a vision model; targeted repairs are deterministic code with no model involved. Either way the output is held to the same independent validator, and generated descriptions and labels are queued for human confirmation. See our security and bring-your-own-key pages for how data is handled.
Point us at your published documents and we will tell you what you are actually holding: how much is already conformant, how much needs repair, and how much was never fixable downstream. That split is worth having whether or not you hire anyone to act on it.