Skip to main content
BrokerDefender
Verification

How packet verification works.

Every BrokerDefender Due Diligence Packet is independently verifiable by anyone holding the file. This page describes the verification workflow and what a successful verification proves.

What's inside a packet

A Due Diligence Packet is a single ZIP file containing four PDFs and three supporting files:

  • 01_Executive_Vetting_Report.pdf — the operational determination.
  • 02_Compliance_Attestation.pdf — the procedure followed, in formal sections.
  • 03_Transportation_Risk_Audit.pdf — a PASS / WARNING / CRITICAL matrix.
  • 04_Forensic_Audit_Record.pdf — the chain-of-custody record, including SHA-256 hashes.
  • raw/carrier_snapshot.json — the unmodified FMCSA payload the vetting was based on.
  • raw/metadata.json — structured metadata, including the file manifest.
  • raw/report_hash.txt — a plain-text SHA-256 manifest, suitable for sha256sum.

The integrity anchor

When BrokerDefender generates a packet, it computes the SHA-256 of the ZIP and stores that hash against the corresponding vetting record on the server. The hash cannot be inside the ZIP — the ZIP would have to contain its own fingerprint, which is mathematically impossible. Instead the hash lives outside the packet, in two places where the packet's holder can find it:

  • On the vetting result page in BrokerDefender, alongside the download button, visible to the broker who created the vetting.
  • On the public verification endpoint at /verify/{vettingId}, visible to anyone holding a packet (no sign-in required).

The four-step verification

  1. Open the packet. Locate the QR code on either the Compliance Attestation (Section 5) or the Forensic Audit Record (Cryptographic Anchors section). Both QR codes point at the same URL.
  2. Visit the verification page. Scan the QR code with a phone or visit the printed URL in a browser. The page displays the vetting's fingerprint: vetting ID, carrier USDOT, carrier legal name, generation timestamp, decision outcome, and packet SHA-256.
  3. Compare the fields. The fingerprint on the verification page should match the corresponding fields inside the packet: vetting ID and timestamp in the metadata block, carrier USDOT in the Carrier Identification table, decision outcome in the Executive Vetting Report's hero banner.
  4. Recompute the ZIP hash. On any computer: shasum -a 256 packet.zip on macOS/Linux, or Get-FileHash packet.zip in PowerShell on Windows. The result must match the Packet SHA-256 shown on the verification page exactly.

What a successful match proves

A successful match across all four steps confirms three things:

  • The packet is one BrokerDefender generated (not fabricated).
  • It was generated for the carrier and at the timestamp shown.
  • No byte of the packet has been altered since generation.

What it does not prove

Verification confirms the packet's authenticity and integrity. It does not constitute legal advice, an endorsement of the carrier, or an opinion on whether the broker's diligence was sufficient in any given case. The Executive Vetting Report inside the packet is the authoritative source for the vetting's findings.

What happens if verification fails

If the packet SHA-256 doesn't match the value on the verification page, the packet has been modified after generation — either intentionally or through accidental corruption. Treat the packet as unreliable evidence and request a fresh copy from the original requester. If the verification page returns a "page not found," the vetting record is no longer on file, typically because it was deleted under the broker's plan retention policy. The packet's own content remains intact, but the integrity anchor is gone.