How a vetting flows

A vetting on tdport.io is three things in sequence: run the checks, seal the record, hand off the cert. That's it.

1. Run the checks

Open the workbench. Search for a carrier by MC number, DOT number, legal name, or phone. The workbench finds the carrier in our FMCSA mirror and shows the identity panel: legal name, DBAs, MC and DOT, principal address, officers, fleet size.

From there, click Run all to fire every available check, or click an individual row to run just that one. Each check resolves to a status:

• Clean — the data source returned nothing the source itself flags as problematic.
• Flag — the source raised a non-critical advisory (a CSA BASIC alert percentile, a non-standard address, etc.).
• Alert — the source raised a serious problem (Unsatisfactory rating, out-of-service order, undeliverable address).
• Not run — the check is idle.
• Error — the check itself failed (typically a transient upstream outage).

Click any row to open the report popout, which shows the raw data the check captured plus source timestamps.

Today, the live checks are FMCSA QCMobile, USPS address validation, and Secretary of State (entity verification across ten states, manual-verify elsewhere). Three more are designed and on the way; see Coming next.

2. Seal the record

When you're satisfied with the checks, click Seal. Three things happen in your browser, in this order:

1. The page assembles every check result into a single bundle — the FMCSA snapshot, the USPS response, all the timestamps, and a deterministic PDF rendering of the result.
2. The browser encrypts that bundle with a fresh per-document key, then signs the encrypted bundle with your account's signing key.
3. The encrypted, signed bundle is posted to the TDPort proof chain. The chain records the cryptographic envelope (block hash, witness co-signatures, timestamp) and returns a record ID and a verify URL.

The proof chain never sees the plaintext bundle. The encryption key never leaves your machine until you choose to share it (it's encoded into the cert PDF's QR code).

3. Hand off the cert

The page renders a printable cert PDF locally. It contains:

• A large QR code that encodes the record ID and the decryption key for the bundle.
• The signer's legal name and account.
• The carrier vetted, with MC and legal name.
• The sealed-at timestamp.
• The verify URL printed in plain text below the QR.

Before the seal commits, you acknowledge the disclaimer in the seal modal: you are solely responsible for the carrier-selection decision, and no representation is made about carrier safety. Clicking Seal on that modal is the acknowledgement. The cert itself reads as your own record, not as something we co-signed.

The PDF downloads to your machine. A .txt copy of the same record is auto-saved as a backup. The sealed record also appears in your vault for future reference.

That's the whole flow. Open /vet, run checks, click Seal, download cert.

Three years later, in discovery

A claim adjuster or opposing counsel asks for proof that you vetted the carrier before tendering the load. You hand them the PDF.

They scan the QR code. The TDPort verify page returns the encrypted bundle plus the public proof envelope (block hash, co-signatures, timestamp). The QR's decryption key opens the bundle. They now have:

• The full FMCSA data exactly as it stood when you vetted.
• Cryptographic proof that the bundle existed at the sealed-at timestamp.
• A signature from your account's key proving you ran the vetting.

What they do with that proof is their job. What you can show is that you did the work and kept the receipt.

See The sealed cert for more on the PDF's contents and the verify flow.