How our data is verified

"Verified" means a named check on a named date

We avoid vague claims that a whole list is "verified". On our site and in our files, "verified" means: the checks described below, cross-checked across multiple sources, on the date shown in the last_verified column. The verify_method column (where present) says which kinds of checks the record passed.

Step 1: the right population

• New authorities start from operating authority grants, not from new USDOT registrations.
• Active small carriers start from carriers with active common or contract authority, one to three power units and an active USDOT registration.
• Brokers and forwarders start from active broker or freight-forwarder authority.

Step 2: current status, not old events

Current authority status comes from current status, never from the history of authority events, because an old revocation in that history may already be cured. Carriers with a revocation pending are removed from the active feeds, and a status of "Pending" does not count as active.

Step 3: insurance

For new authorities we compare liability insurance on file with the federal minimum. For older carriers we show the insurance company and the effective date of the latest filing.

Step 4: contacts

• Phone validation. Numbers are validated and typed as mobile or landline where possible.
• Shared contacts. A phone number or email that appears on three or more carriers in the same build is treated as belonging to a third party (for example a filing service or dispatcher) and the row is left out of callable feeds.
• Agent domains. Email domains that look like filing, permit, compliance or dispatch services are flagged.
• Owner-direct. For the active small-carrier feeds, we keep contacts that look like the owner's own.

Step 5: automated verification and specialist spot-checks

Every build passes automated verification before release, and every feed is checked again daily. A random sample and the rows our checks flag are checked for contact validity, authority status, agent and shared contacts, duplicates, the removal list, freshness and sharp changes in the number of rows. A serious failure stops the build; smaller issues above a set rate hold it for a data specialist, and our data specialists spot-check samples. When a check finds a rule that let a wrong row through, we fix the rule and add a regression test.

Step 6: the removal list

Identifiers submitted on the removal page are excluded inside the query that builds every file, dashboard table and API response, and checked again on every row before it leaves our system.

Step 7: freshness rules

A feed is not built or served when its status checks are older than the feed allows. When that happens you see "refresh pending" on the site and the API returns a stale_source error instead of old data.

What we do not promise

• Records reflect what businesses registered. If a company registered a wrong phone number, the record can be wrong.
• Status can change after the last_verified date. Check the carrier yourself before contracting.
• We do not screen numbers against Do Not Call registries.
• When we publish the result of an audit of a sample of records, we state the sample size, the number that passed and the date, not a rounded marketing claim.