Why this question matters for engineering documents
Engineering reports, drawings, and certificates become part of construction records,
regulatory submissions, and insurance claims — sometimes years after they were issued. A
contractor may claim a specification said something different. An insurer may question
the date of a geotechnical assessment. A certifier may need to confirm which revision of
a drawing was current at a particular time.
In most small and mid-sized practices, the answer to those questions today is an email
thread. The firm searches its sent folder and hopes the attachment, the date, and the
recipient line up. That works until it is genuinely contested.
The four checkable attributes
1. Recorded issuer attributes. Which organisation stood behind the
document when it was issued — captured through defined identity checks completed before
certification, not inferred from a letterhead or an email address.
2. The submitted file's hash. A SHA-256 fingerprint of the exact file
that was recorded. If the file a recipient holds produces the same hash, it is the same
file, byte for byte. If it differs in any way, the hash will not match.
3. The timestamp. An RFC 3161 timestamp evidences that the recorded
hash existed by the recorded time. This answers "when did this file exist in this form"
independently of file-system dates or email headers, which are easy to alter.
4. Current status. Whether the document is still current, has been
superseded by a newer revision, or has been revoked. This is the attribute a static PDF
can never carry, because status changes after issue.
How a recipient actually checks these
The practical test for any verification workflow is whether a recipient can perform the
check without special software, without creating an account, and without calling the
issuing office. A QR-linked verification page meets that test: the recipient scans the
code or follows the link, sees the recorded issuer attributes, the recorded hash, the
timestamp, and the current status, and compares the file they hold against the record.
Verified.Tools is running an invite-only private beta of this workflow with Australian
and New Zealand engineering firms — testing whether a recipient-accessible record fits
how firms already issue their PDFs.
What a recipient cannot verify — from any record
No verification record shows that the engineering content is substantively correct, that
the design is sound, that the author held a particular registration, or that the
document satisfies a specific statutory requirement for a specific use. Those questions
are answered by professional review and, where needed, legal advice. A verification
record answers a narrower and complementary question: is this the file that was
recorded, by this organisation, at this time — and is it still current?
Firms evaluating any verification product should be sceptical of broader claims. The
value is in what is concretely checkable, stated plainly.
Related reading
How to verify a PDF document
Emailed PDFs are no longer enough for important issued documents