Filum ships with an installation qualification protocol: thirteen steps the customer's IT team runs and signs. Most vendors write it. We executed it, on a real installation, from loading the image through restoring a backup. Here is what it found — and why that is good news.
Each line gives the step that surfaced the defect, what it would have cost the customer, and what was done. None would have been found without running the procedure: neither code checking, nor the application build, nor the qualification cases ran inside the delivered container at the time.
The installation stopped at the first technical step, in front of the customer's IT provider, on go-live day. No upstream check could have caught it: they all run outside the container.
Resolution — Dependencies completed, and a check that now fails the BUILD rather than the start-up: the error can no longer travel as far as the customer.
The start-up log — kept by the IT provider as installation evidence — said 1.0.0 while the screen displayed 1.2.0. Two numbers for one installation, in a file that must tie every record to the version that produced it.
Resolution — A single source, no fallback value left. And the protocol now makes it a check: record the version in the log, compare it with the screen.
The procedure checked that the archive of the volume holding approved documents was not empty. The test answered “verified” on an 86-byte archive that was entirely empty. A reassuring, hollow backup — the defect would only have surfaced at the first restore.
Resolution — Volume existence checked BEFORE the backup, then a count of archived records. The trap was reproduced deliberately to prove the new version catches it.
The backup stops the service, copies, restarts. The script died half-way: the application stayed unavailable for four minutes. On a task scheduled at two in the morning, it would have stayed down until daybreak.
Resolution — The restart is now guaranteed whatever happens, and the guide points out that a backup whose exit code nobody reads is not a backup.
The protocol asked to compare the digest of the archive received with the one communicated by the vendor. Neither the archive nor the digest existed, and the step skipped the only check that catches a delivery altered in transit.
Resolution — Delivery archive produced with two digests verifiable without Docker, and the step now requires both: the archive's before loading, the image's after.
The criterion announced a redirect; the software renders the sign-in screen instead of the content. The protection is there — nothing leaks — but an IT provider applying the text literally would have recorded a deviation on correct software.
Resolution — Criterion rewritten on the observed behaviour, in both languages of the protocol.
The guide had the reader load a file with an invented name and asked for no digest check before loading. The customer would have followed a procedure impossible from its very first line.
Resolution — Section rewritten on the real delivery, digest check included, with the warning never to rebuild the image in order to check it.
The seven above come from our protocol. The two that follow come from someone else — and that is precisely the point.
The archival copies of frozen records are produced in PDF/A, the format meant to guarantee a document still opens in ten years. We had written our own conformance check at the same time, and it had been declaring those files conformant.
On 9 August 2026 we ran veraPDF — the reference implementation, written by an outside consortium — over a complete archive. Four records out of fifteen were non-conformant.
The cause was a single character: the superscript plus of “Na⁺”, an entirely ordinary chemistry notation in a diagnostics file. The embedded font did not draw it, and the file fell back on a glyph the format forbids. Two consequences, neither visible from the inside: the document carried metadata asserting a conformance it did not have, and the reader saw an empty box where the record says “Na⁺”.
Our own check saw nothing, and that was predictable: written by the author of the code, it shares exactly its blind spots. What one did not think to produce, one does not think to look for either. That is the argument for third-party audit, and it holds for a software vendor just as it does for a manufacturer.
What remains: the reference validator now runs at every release, over a document built to defeat it. And the harness carries a deliberately non-conformant witness — if the validator lets the witness through, no other result of that run is retained. “Fifteen conformant files” means nothing coming from a tool that can no longer say no.
Fixing seven defects would be worth little if the eighth had to wait for the next customer. What the exercise mainly left behind is checks.
The execution is recorded in a dated and signed record whose digest is frozen. It is provided on request.
The validation file and the IQ protocol were withdrawn on 2 October 2026: an internal audit found statements in them that the code did not uphold. Their corrected editions will ship with version 1.3.0.
A supplier claiming to have no defects is mostly claiming to have looked for none. What you can ask a vendor for is not an absence of defects: it is that they ran their own procedure, that they say what they found, and that they show you what stops the next one from getting through.
It is also the reason the product exists. Filum does not promise your files will be perfect: it makes sure a discrepancy shows while you can still deal with it, rather than in front of an auditor.