Carrier and lane performance histories: what AI teams learn from them

What a carrier and lane performance history contains#

A carrier and lane performance history is the load-by-load record of how each carrier performed on each lane: who was offered the load, whether they accepted, when they picked up and delivered against the appointment, and what went wrong. Scorecards summarize it; the load history underneath holds the detail.

Brokers, 3PLs and shippers with dedicated carrier networks build these records in a TMS such as McLeod, supplemented by visibility platforms, EDI 214 status messages, telematics feeds from tools such as Samsara for asset fleets, and spreadsheets the carrier team keeps for quarterly reviews. The archive is usually larger and messier than the scorecard suggests, and the messy part is where most of the learning sits.

Links break in predictable places. Reason codes change when a TMS is reconfigured, so a code from one year may mean something else later. Check-call notes sometimes live in email rather than on the load, and carrier records may be merged or split after an acquisition. Note each break in a data inventory so a buyer knows what every field means in every period.

Which scorecard fields matter most to AI teams?#

The scorecard fields that matter most are the ones that record a decision, a deviation and a cause. A clean on-time rate tells a model little; a late delivery with its reason code, the check-call note and the rebooked appointment tells it a great deal.

Note who assigned each reason code. A cause reported by the carrier, a cause verified by your team and a cause disputed by the customer are different facts, and AI teams handle them differently when they train a system to explain delays.

Keep mode and equipment on every load. Truckload, LTL, intermodal and specialized freight behave differently, and an unlabeled mix is hard for any AI team to use.

What AI teams learn from lane histories#

AI teams use lane histories to train and test systems that predict how a load will go and recommend what to do when it starts going wrong. Typical tasks include estimating arrival times, ranking carriers for a tender, forecasting rejection risk and drafting the explanation a customer service rep sends after a miss.

Length of history matters because lanes are seasonal. A produce lane during harvest behaves nothing like the same lane in winter, and a system tested on a single season will mislead. Several years of consistent records let an AI team check whether a system holds up across peaks, weather and capacity swings.

Evaluation is often as valuable as training. A developer building a carrier-selection assistant needs real past decisions with known outcomes to check whether the assistant would have chosen better or worse than your dispatchers did.

Why carrier identities are removed before licensing#

Carrier identities are removed before licensing because the performance pattern is useful and the name is not, while the name carries confidentiality, reputational and privacy risk. A buyer learning how carriers behave on a lane does not need to know which carrier ran late.

The fix is one consistent token per carrier, applied across every year of the archive, so the same carrier keeps the same token on every lane. Fleet-size bands or equipment labels can replace exact fleet details where a buyer needs context. Rates and carrier pay are usually removed, or kept only in generalized form after counsel's review.

• 1Broker-carrier agreements often include confidentiality terms covering rates, customers and shipment details, and some restrict how carrier information may be used.
• 2A scorecard that leaks in any form could harm a carrier's reputation and your relationship with it.
• 3Many small carriers are owner-operators whose business name is a personal name, so carrier data can be personal data.
• 4MC and DOT numbers, driver names, phone numbers, truck and trailer numbers and insurance details identify a carrier as surely as its name.

Illustrative: a brokerage turns its scorecard archive into a lane history package#

Illustrative: a fictional truckload brokerage has run on the same TMS for most of a decade and builds carrier scorecards in spreadsheets each quarter. Its COO wants to know whether the history has any use beyond carrier reviews.

The operations team finds that tender, appointment and actual times are complete for most loads, but late reason codes were optional until a later TMS reconfiguration. The package starts at that change, links each load to its check-call notes and claims, and drops the spreadsheets, which only summarize data already in the TMS.

Carrier names, MC numbers, driver contacts and all rates are removed. Carriers and customers get consistent tokens, and lanes are kept as origin and destination regions. Counsel confirms that the carrier agreements allow de-identified use, and the COO approves the scope.

How SourceX scopes performance histories#

SourceX judges a carrier and lane history with the SourceX Enterprise Data Value Framework, its own qualitative method rather than an industry standard. Dispatcher notes and coded causes on each load supply domain expertise and human-generated signal, recent seasons add recency, and consistent reason codes count as data cleanliness. Scorecard summaries are easy to reproduce, so they add little, and carrier tokenization adds preparation cost that is weighed against the rest.

In the Supply step of the SourceX five-step transaction, the fit check collects only metadata, such as the TMS in use, years of load history and which fields are populated. Files move only after the supplier approves the scope, and the carrier tokenization method is documented in the SourceX Evidence Packet.