Tamper-Evident Document Verification

Prove What Was Officially Issued— And Prove It Has Not Been Altered

TransmittalProof helps engineering, commissioning, and operations teams verify that issued drawings, procedures, manuals, and reports are the official approved versions. It adds an independent integrity record without replacing your existing document system.

The Problem

In real projects, documents move between engineering, document control, contractors, commissioning, and operations. Even when teams follow good procedures, files are often:

  • Re-saved or re-exported
  • Renamed or reformatted
  • Re-issued under a new revision
  • Overwritten by a newer version
  • Quietly modified after approval

That creates confusion, rework, claims risk, and audit problems.

The Solution

TransmittalProof solves that by creating a tamper-evident proof of issue for every official document release. Once a document set is approved and anchored, any change — no matter how small — can be detected instantly.

What TransmittalProof Does

For each issue event or transmittal, TransmittalProof performs the following:

1

Reads the transmittal register

2

Fingerprints each issued file using SHA-256

3

Creates an issue manifest

4

Anchors the manifest fingerprint to the XRP Ledger

5

Generates a verification page and QR code

6

Lets anyone verify whether a file is the official issued version

This means you can prove:

Which revision was issued
When it was issued
Whether a file has been altered
Whether a user is holding the official copy

Who It Is For

Designed For

  • Engineering firms
  • EPCs
  • Document control teams
  • Commissioning teams
  • Owner/operators
  • QA/QC and audit teams

Typical Document Types

  • P&IDs
  • Isometrics
  • General arrangement drawings
  • Single line diagrams
  • Procedures
  • Vendor manuals
  • Reports
  • Turnover and handover packages

How It Works

The complete issue lifecycle from creation to field verification.

1

Create an Issue Event

A user creates a new issue event in TransmittalProof. This can represent an IFC issue, an IFR issue, an as-built issue, a controlled procedure release, or any official document transmittal.

2

Upload the Register and Files

The user uploads the transmittal register or controlled document list along with the issued PDF files. The system matches document number, revision, title, and status.

3

Fingerprint the Files

TransmittalProof computes a SHA-256 fingerprint for each uploaded file. This fingerprint is unique to the exact file bytes. If even one character, pixel, or byte changes, the fingerprint changes. The exact file can be verified later, but the actual document content does not need to be stored on-chain.

4

Generate the Issue Manifest

The system creates a manifest containing document number, revision, status, file name, file hash, and issue metadata. The manifest acts as the official machine-readable record of what was issued.

5

Approve the Issue

Once the issue is reviewed, the approver confirms it as official. Typical approvers include Lead Engineer, Engineering Manager, Commissioning Manager, or Ops Superintendent.

6

Anchor the Manifest to XRPL

After approval, the manifest hash is anchored to the XRP Ledger. This creates an independent timestamp, an immutable external proof, and a defensible record outside the client's own internal system. The PDF files are not stored on the ledger — only the cryptographic fingerprint is.

7

Generate Verification Outputs

TransmittalProof generates an Issue Certificate PDF, a verification URL, a QR code, and later, QR-stamped document copies.

8

Verify in the Field or Office

A user scans the QR code or opens the verification link. They can view official issue information, check document list and hashes, and upload a PDF to test whether it is an exact match. If the file matches, it is confirmed as the official issued version. If it does not match, the system returns NOT MATCH.

Why It Matters

Prevents Silent Changes

Once a document is officially issued, even a tiny change can be detected.

Reduces Wrong-Revision Risk

Users can confirm whether they are holding the official version.

Improves Auditability

Auditors can review an independent proof trail for issued documents.

Strengthens Claims and Dispute Defense

Teams can prove what was issued and when.

Works Alongside Existing Systems

TransmittalProof does not replace SharePoint, ProjectWise, Aconex, or other DMS platforms. It adds an independent proof layer.

Frequently Asked Questions

Common questions about how TransmittalProof works, what it stores, and how it fits into your existing workflows.

It solves the problem of proving which document version was officially issued and whether it has been changed after approval. In real projects, the same drawing or procedure may exist in multiple copies across email, shared folders, SharePoint, contractor devices, and field printouts. That creates uncertainty. TransmittalProof removes that uncertainty by providing a tamper-evident proof of issue.

No. TransmittalProof does not store document contents on the ledger. It only stores a cryptographic fingerprint of the issue manifest. That fingerprint can later prove whether a document set matches the approved issue. This keeps the solution practical and privacy-conscious.

For each issue, the system writes a small proof record containing the manifest hash, the issue identity, issue type, and the timestamp provided by the validated transaction. This is enough to prove integrity without exposing the actual document contents.

A manifest is the official structured list of what was issued. It contains document number, revision, file name, status, file hash, and issue metadata. Think of it as the digital fingerprint register for the issue event.

Each file is hashed so the system can later confirm whether a PDF is the exact same file that was officially issued. If someone re-saves the PDF, modifies the title block, changes the revision cloud, prints and re-exports it, or edits even a tiny detail — the hash changes. That is how TransmittalProof detects tampering or drift.

The approval step marks the issue as official. At that point, the manifest is finalized, the manifest hash is anchored to XRPL, and the issue becomes verifiable through the platform. This approval event is the point at which the document set becomes the recognized official issue.

Verification works in two ways. Issue-level verification lets you open the verify page, review issue details, confirm the issue is validated, and review included documents. File-level verification lets you upload the PDF you have — the system calculates its SHA-256, compares that result against the official issued set, and returns MATCH or NOT MATCH.

Because the system verifies the exact file bytes, not just visual similarity. A file may look the same but still fail if it was re-saved, compressed, OCR processed, printed and re-exported, flattened, edited in markup software, or exported from a different source. This is actually the strength of the system: it proves exact file integrity.

Copying a PDF to another folder does not change the file, so it will still be a MATCH.

What matters is the file contents, not:

  • the folder location
  • the filename
  • the email it came from
  • where it is stored

It will still match if:

  • someone copies the PDF to another folder
  • someone sends the same PDF by email
  • someone uploads the exact same file from SharePoint, desktop, USB, etc.
  • someone renames the file only

It will NOT match if the file itself changes. Examples:

  • re-saved from Bluebeam or Acrobat
  • printed to PDF again
  • OCR applied
  • markup flattened
  • title block edited
  • revision cloud changed
  • metadata rewritten by some export process
  • scanned again from paper

The rule is simple: same file bytes = MATCH. Changed file bytes = NOT MATCH.

This is one of the strongest selling points — TransmittalProof does not care where the file lives, only whether it is still the exact official issued file.

No. The same workflow can be used for procedures, manuals, reports, turnover packages, QA/QC records, commissioning documents, and any controlled PDF-based issue. The underlying model supports any controlled document.

No. TransmittalProof is designed to sit alongside existing systems. It is a proof and verification layer, not a replacement document management system. That makes adoption much easier.

The value is practical, not theoretical: fewer wrong-revision mistakes, better field confidence, stronger audit trail, reduced claims ambiguity, and easier proof of official issue.

XRPL provides an external, independent, timestamped proof that does not depend on a single company's internal database. That matters when multiple parties are involved, documents pass across organizational boundaries, disputes occur, or audits happen months or years later. The ledger acts as an external integrity anchor.

No, not in the way most people think. Users do not need wallets, tokens, crypto experience, or blockchain knowledge. XRPL is simply the backend proof layer. The user experience is: upload, approve, scan, verify.

A superseded issue remains verifiable historically. That means you can still prove what was official at a prior date, what was current at the time of issue, and what changed later. This is useful for claims, audits, and historical records.

A typical workflow: (1) Document controller creates issue event, (2) Register and PDFs are uploaded, (3) System matches rows to files, (4) System hashes files and generates manifest, (5) Approver confirms issue, (6) Manifest hash is anchored to XRPL, (7) Issue certificate and QR outputs are generated, (8) Recipients scan or verify files as needed. That is the complete issue lifecycle.

Ready to Prove What Was Officially Issued?

TransmittalProof adds tamper-evident proof of issue without replacing your current document system.

Detect changes instantly. Verify documents in seconds.

Contact Us for a Pilot or Demonstration