DEV Community: Dimitrii Khristoforidi

From Raw Freight Data to Decision-Ready Context: Building a Reliable Freight Decision Pipeline

Dimitrii Khristoforidi — Tue, 06 Oct 2026 05:35:00 +0000

Freight systems generate enormous amounts of information, but information by itself is not enough to support a good booking decision.

A load posting may tell you where the freight is moving, how much it pays, what equipment is required, and when pickup is scheduled. A broker email may add context. A truck-position feed may tell you where the vehicle is now. A RateCon may confirm the final rate and operational terms. External sources may provide authority, insurance, or risk information.

Each of those inputs is useful, but none of them should automatically be treated as decision-ready truth.

The real engineering challenge is to transform fragmented freight events into a representation that is structured, current enough, traceable, explicit about uncertainty, and relevant to the decision a dispatcher actually needs to make.

A reliable pipeline usually looks more like this:

Raw Event
↓
Ingestion Validation
↓
Normalization
↓
Context Join
↓
Semantic and Cross-Source Validation
↓
Derived Metrics
↓
Decision Signals

Every stage changes the shape of the data and may either increase or reduce confidence. Transformations should therefore record their assumptions, validation results, and any uncertainty they introduce.

The goal is therefore not to collect as much information as possible. It is to create a trustworthy decision object from multiple imperfect sources.

Raw Freight Data Is an Event, Not a Decision

An event records an observation or change at a particular time. Current operational state is derived from one or more ordered events and may change when delayed, corrected, or out-of-order events arrive. The pipeline should not treat the latest received event as automatically representing the latest real-world state.

Freight workflows continuously generate events.

A load board publishes an opportunity. A broker sends an email. A dispatcher updates truck availability. A driver changes location. A RateCon arrives. A carrier or broker record changes.

Each event tells us something about the current state of the operation, but that does not mean the event should immediately influence a booking decision.

Consider a basic load object:

{
  "origin": "Chicago, IL",
  "destination": "Nashville, TN",
  "pickup": "2026-09-22 14:00",
  "delivery": "2026-09-23 09:00",
  "equipment": "Dry Van",
  "rate": 1850,
  "broker_mc": "123456"
}

This looks structured, but several important questions remain unanswered.

What timezone do the timestamps use? Is the pickup time a fixed appointment or a flexible window? Has "Dry Van" been normalized to the same equipment taxonomy used elsewhere in the system? Is the broker MC verified? How far is the assigned truck from pickup? Is the rate still current? Does another source disagree with any of these values?

Until those questions are resolved, the object may be readable by software, but it is not yet reliable enough to support a real dispatch decision.

Stage 1: Preserve the Raw Event

Before transforming data, preserve the original source event. This is important because once a value has been normalized, enriched, or recalculated, you may later need to understand exactly what the source originally provided.

A raw record might look like this:

{
  "source": "load_board",
  "source_id": "LB-847219",
  "observed_at": "2026-09-22T13:40:58Z",
  "received_at": "2026-09-22T13:41:22Z",
  "schema_version": "1.0",
  "payload": {
    "origin": "Chicago, IL",
    "destination": "Nashville, TN",
    "rate": 1850
  }
}

observed_at describes when the source considered the value current, while received_at records when the pipeline received it. The distinction matters when events arrive late or out of order.

Keeping the original payload gives the system a stable reference point for debugging, auditing, reconciliation, and model evaluation.

If a transformed value later looks wrong, the team can inspect the original event instead of trying to reconstruct what happened from downstream state.

That becomes especially important when multiple sources disagree.

Raw-event storage should support idempotency, deduplication, schema versioning, and immutable audit history. Reprocessing the same source event should not create a duplicate downstream action.

Stage 2: Normalize the Schema

Raw freight data rarely arrives in one consistent format.

One system may describe an equipment type

as Dry Van
another as VAN
another as 53' Van
and another as DV

The same problem appears with locations, rates, dates, appointment windows, company identifiers, currencies, and units.

A decision pipeline therefore needs a canonical schema that converts different representations into a consistent internal model.

For example:

{
  "equipment_type": "dry_van",
  "origin": {
    "city": "Chicago",
    "state": "IL",
    "country": "US"
  },
  "rate": {
    "amount": 1850,
    "currency": "USD"
  }
}

Normalization makes records comparable, but it should not erase the source value.

A better structure preserves both:

{
  "equipment": {
    "raw": "53' Van",
    "type": "dry_van",
    "length_ft": 53
  }
}

Normalization should separate equipment dimensions instead of collapsing them into a single category, because trailer type, length, weight capacity, and special requirements can independently affect compatibility.

This approach gives the pipeline the consistency it needs without sacrificing provenance.

The distinction matters because normalization is an interpretation step. Even if that interpretation is usually deterministic, it should still be possible to trace the normalized value back to the original input.

Stage 3: Add Operational Context

Normalized data is easier to process, but it still does not tell the full operational story.

A Chicago-to-Nashville load should not be evaluated only as a lane. It should be evaluated relative to the actual truck, driver, timing, broker, and surrounding constraints.

That context may include:

current truck position;
truck availability;
driver availability;
equipment compatibility;
pickup and delivery timing;
existing commitments;
broker identity;
route context;
trip economics.

The same load can be a strong option for one truck and a poor option for another.

A contextualized object might look like this:

{
"load": {
"origin": "Chicago, IL",
"destination": "Nashville, TN",
"rate": 1850,
"equipment": "dry_van"
},
"truck": {
"current_location": "Joliet, IL",
"available_at": "2026-09-22T12:30:00-05:00"
},
"broker": {
"mc": "123456"
}
}

At this stage, the system can begin asking meaningful operational questions.

How far is the truck from pickup? Can it arrive on time? Does the equipment match? Does the broker information appear consistent? What other loads are competing for the same truck?

Without this context, the load is merely available. With context, the system can begin evaluating whether it fits the operation.

Stage 4: Validate Before You Calculate

Once the data has been normalized and connected to the operation, the next step is validation. This is important because derived metrics are only as trustworthy as the inputs behind them. Validation is not a single stage. Basic structural validation should happen at ingestion, while semantic, cross-source, temporal, and policy validation should continue throughout the pipeline.

Structural Validation

The first question is whether each field has the expected type and shape.

rate = number
pickup = valid timestamp
MC = valid identifier format

A field that cannot be parsed reliably should not silently enter downstream calculations.

Semantic Validation

The next question is whether the value itself makes sense.

delivery_time > pickup_time
rate > 0
loaded_miles > 0

A structurally valid value can still be operationally impossible.

Cross-Source Validation

Independent sources may also disagree.

Suppose the load board shows:

Rate: $1,850

while the RateCon shows:

Rate: $1,750

The correct response is not to choose whichever source appears later in the pipeline.

The system should preserve both values and surface the discrepancy:

rate_status = conflicting

The pipeline should also apply an explicit source-precedence policy. For example, an executed RateCon may be authoritative for the agreed contractual rate, while a newer load-board posting may represent the currently advertised rate. The system must preserve both because they describe different claims, not necessarily competing versions of the same fact.

The same principle applies to pickup time, destination, equipment type, or any other field that can materially affect the booking decision.

Temporal Validation

Finally, the system should determine whether the information is still current enough to use.

A load posting may be perfectly valid as data and still be useless as an opportunity if it was already booked fifteen minutes ago.

This leads to an important distinction: Data can be valid and still be stale.

Stage 5: Treat Freshness as Part of the Data Model

Different freight signals age at different speeds, so freshness should not be handled as a single property attached to an entire record.

Truck location may change continuously. Load availability may become stale within minutes. Broker authority may remain stable longer. A RateCon may remain authoritative for the specific shipment it belongs to.

That means individual fields should often carry their own timestamps.

For example:

{
  "truck_location": {
    "value": {
      "lat": 41.5250,
      "lng": -88.0817
    },
    "updated_at": "2026-09-22T13:55:10Z"
  },
  "broker_authority": {
    "value": "active",
    "checked_at": "2026-09-22T08:00:00Z"
  }
}

The decision system can then determine whether each signal is still usable for the current decision. This is more robust than treating the entire object as simply “enriched,” because enriched data can still be out of date.

For a real-time operational system, freshness is not metadata decoration. It is part of the meaning of the field.

Stage 6: Keep Provenance Attached to the Data

As data moves through a pipeline, one of the easiest things to lose is its origin. The transformed value survives, but the system no longer remembers where it came from.

That becomes a problem when a dispatcher sees:

Broker authority: Active

and wants to know whether that status came from FMCSA, an internal cache, a third-party provider, or a previous verification event.

A stronger representation keeps the source attached:

{
  "broker_authority": {
    "authority_type": "broker_property",
    "status": "active",
    "source": "FMCSA",
    "checked_at": "2026-09-22T14:10:00Z",
    "pending_revocation": false
  }
}

Provenance improves trust, but it also improves system quality.

If a recommendation later appears incorrect, the pipeline can identify whether the problem came from the source, the normalization layer, a stale record, a calculation, or the interpretation logic.

Without provenance, all of those failures become much harder to separate.

Stage 7: Model Uncertainty Explicitly

Reliable systems should never pretend to know something they do not know. Freight data is often incomplete, delayed, contradictory, or unavailable. Those conditions should be represented explicitly instead of being hidden behind default values.

For example, a single field might be described like this:

{
  "value": "active",
  "availability": "known",
  "freshness": "current",
  "consistency": "conflicting",
  "derivation": "source_reported",
  "verification": "checked"
}

Availability, freshness, consistency, derivation, and verification are separate dimensions and should not be compressed into one status field.

Suppose insurance information cannot currently be retrieved.

A safe representation would be:

{
  "insurance_status": {
    "value": null,
    "status": "unavailable"
  }
}

A dangerous representation would be:

insurance_risk = low

if the system simply failed to find a negative signal.

The absence of a negative signal is not the same as positive verification.

This distinction becomes even more important when generative AI is used in the workflow, because a language model can produce plausible-looking interpretations even when the underlying data is incomplete.

A reliable decision pipeline should preserve uncertainty rather than conceal it.

Stage 8: Calculate Derived Metrics

Once the underlying data has been normalized, contextualized, and validated, the system can begin calculating metrics that do not exist directly in the source data.

Examples include:

loaded RPM;
effective RPM;
deadhead percentage;
estimated fuel cost;
toll cost;
total operational miles;
estimated trip contribution;
pickup feasibility.

Consider effective RPM:

effective_rpm =
rate / (loaded_miles + deadhead_miles)

If:

rate = 1850
loaded_miles = 470
deadhead_miles = 58

then:

effective_rpm = 1850 / 528
= 3.50

The value is derived, so the pipeline should ideally keep enough information to reproduce it.

For example:

{
  "effective_rpm": {
    "value": 3.50,
    "formula": "rate / (loaded_miles + deadhead_miles)",
    "inputs": {
      "rate": 1850,
      "loaded_miles": 470,
      "deadhead_miles": 58
    }
  }
}

This makes the metric auditable.

If the truck position changes and deadhead increases, the system can recalculate the result and explain exactly why the number changed.

Stage 9: Separate Facts From Interpretations

A reliable decision pipeline should distinguish between measured or calculated facts and the interpretations built on top of them.

For example:

Deadhead miles: 58

is a measurable value.

Deadhead impact: Low

is an interpretation.

Likewise:

Pickup window remaining: 2h 10m

is a fact.

Pickup feasibility: Tight

is a decision signal.

Both are useful, but they serve different purposes. Keeping them separate gives the system more flexibility because thresholds can change without rewriting the underlying data.

If the fleet later decides that 58 miles should no longer be considered “low deadhead,” the raw metric remains valid even though the interpretation changes.

That separation also makes recommendations easier to explain.

Stage 10: Build Decision Signals

Once facts and derived metrics are reliable enough, the pipeline can convert them into signals that are easier to interpret operationally.

A decision layer might show:

Economics: Strong
Deadhead: Low
Pickup feasibility: Tight
Broker record matched to the provided MC number; contact identity requires separate verification.
Authority: Active
Rate discrepancy: None
Destination positioning: Weak

This representation is more useful than forcing a dispatcher to interpret dozens of independent fields every time.

At the same time, the signal should still be traceable to the underlying facts.

For example:

Economics: Strong

because:

effective RPM = $3.50
deadhead = 58 miles
toll exposure = low

A system may still calculate an overall ranking or score, but that score should sit on top of transparent decision signals rather than replace them.

A number such as:

Load Score: 86

has limited value if the dispatcher cannot understand why the score exists.

Transparent inputs, policy rules, assumptions, and limitations make a ranking more useful as decision support.

Stage 11: Define What “Decision-Ready” Means

Decision-ready does not mean that the system has accumulated a large
amount of data.

It means the system has enough reliable context to support the next operational decision without hiding major uncertainty.

A decision-ready freight object should usually have several properties:

key fields are structured;
relevant operational context has been attached;
derived metrics are available;
important conflicts have been surfaced;
freshness is known;
uncertainty is explicit;
decision signals are explainable;
source provenance is retained.

At that point, the object can support actions such as comparison, ranking, recommendation, flagging, or explanation.

This does not mean the system must make the final decision automatically.
It means the information has reached the point where a human or controlled automation layer can reason over it responsibly.

Data Contracts Matter

As pipelines become more complex, explicit data contracts become increasingly useful. A field should not simply exist. The system should also know how that field is supposed to behave.

A data contract defines static properties such as type, requiredness, nullability, units, allowed values, and derivation rules. Runtime metadata separately records provenance, freshness, consistency, and verification status for each observed value.

A simplified contract might look like this:

{
  "rate": {
    "type": "number",
    "required": true,
    "source_required": true
  },
  "deadhead_miles": {
    "type": "number",
    "derived": true
  },
  "broker_authority": {
    "type": "string",
    "nullable": true,
    "verification_required": true
  }
}

Contracts make assumptions explicit. They also make it easier to determine whether an object is ready to move to the next stage of the pipeline.

If a critical field is missing or unverified, the system can stop, downgrade confidence, or request additional validation instead of continuing as though nothing is wrong.

Derived Data Should Be Reproducible

Any derived value that materially influences a booking decision should ideally be reproducible.

If a dispatcher asks why the system shows an effective RPM of $3.50, the answer should not be:

The AI calculated it.

The system should be able to show the inputs and formula:

Rate: $1,850
Loaded miles: 470
Deadhead miles: 58

Effective RPM:
1850 / (470 + 58)
= 3.50

This distinction matters because deterministic calculations should remain deterministic.

AI can help interpret the result, summarize tradeoffs, or explain why one opportunity ranks above another, but it should not obscure calculations that can be reproduced exactly. This creates a cleaner architecture and makes the system much easier to trust.

Decision-Ready Does Not Mean Autonomous

A freight object can be decision-ready without being automatically booked. The purpose of the pipeline is to reduce the amount of manual interpretation required before a decision, not necessarily to remove the
dispatcher from the process.

A human-in-the-loop workflow might look like:

recommend
→ dispatcher reviews
→ dispatcher decides

A more automated workflow might look like:

recommend
→ rules validate
→ predefined action executes

The appropriate level of automation depends on the decision, the quality of the underlying data, and the consequences of getting it wrong.

The transition from raw freight data to decision-ready context is therefore only one part of a larger system. The broader sequence from ingestion and enrichment through calculations, decision signals, document processing, and human approval is described in the full AI dispatch decision workflow.

Example: How One Load Evolves Through the Pipeline

Consider the following raw event:

{
  "origin": "Chicago",
  "destination": "Nashville",
  "rate": "1850",
  "equipment": "VAN"
}

At this stage, the record contains useful information, but it is still ambiguous and disconnected from the operating context.

After Normalization

{
  "origin": {
    "city": "Chicago",
    "state": "IL"
  },
  "destination": {
    "city": "Nashville",
    "state": "TN"
  },
  "rate": {
    "amount": 1850,
    "currency": "USD"
  },
  "equipment_type": "dry_van"
}

The values are now consistent enough to compare with other records.

After Context Join

{
  "truck_deadhead_miles": 58,
  "loaded_miles": 470,
  "truck_available": true,
  "broker_mc": "123456"
}

The load is now connected to a specific truck and broker context.

After Validation

{
  "rate_status": "verified",
  "equipment_match": true,
  "broker_authority": "active",
  "pickup_data_status": "current"
}

The pipeline now has more confidence that the important inputs are usable.

After Derived Metrics

{
  "posted_rpm": 3.94,
  "effective_rpm": 3.50,
  "total_operational_miles": 528
}

The system can now evaluate the economics more realistically.

After Decision Signals

{
  "economics": "strong",
  "deadhead": "low",
  "pickup_feasibility": "tight",
  "broker_context": {
    "record_match": "matched",
    "authority_check": "active_at_last_check",
    "contact_identity": "not_verified"
  },

  "destination_positioning": "weak"
}

At this point, the system is no longer describing only what the load is. It is providing enough context to help answer whether this load is a strong choice for this truck under current conditions.

That is what decision-ready context means in practice.

A Reliable Freight Decision Pipeline

When all of these stages are combined, the overall architecture may look like this:

Source Event
↓
Immutable Raw Storage
↓
Ingestion Validation and Deduplication
↓
Schema Normalization
↓
State Resolution and Context Join
↓
Semantic, Cross-Source, and Freshness Validation
↓
Derived Metrics
↓
Action-Specific Readiness Check
↓
Decision Signals and Ranking
↓
Human Review or Policy-Controlled Action
↓
Outcome and Audit Event

The exact implementation will vary between systems, but the underlying principles remain consistent.

Preserve the original source. Normalize before comparing. Attach operational context before evaluating. Keep provenance. Track freshness. Represent uncertainty explicitly. Make derived metrics reproducible.
Separate facts from interpretations. Keep recommendations explainable.

Those principles are what turn fragmented freight data into something reliable enough to support a real operational decision.

Final Takeaway

The hardest part of building a freight decision system is not collecting more data. The harder problem is determining when that data is structured enough, current enough, contextual enough, and trustworthy enough to influence a booking decision.

Raw events tell the system what happened. Normalization gives those events a consistent structure. Contextualization connects them to the specific truck, route, broker, and operating conditions. Validation determines whether the information is reliable enough to use, while derived metrics transform validated inputs into operational measurements. Decision signals then make those measurements easier to interpret and compare.

Only after those steps does the system have something that can reasonably be called decision-ready context.

The transition is therefore not:

data → AI

It is closer to:

raw evidence
→ structure
→ context
→ validation
→ derived meaning
→ decision support

A reliable freight decision pipeline should make every one of those stages visible enough to trace, reproduce, and challenge when necessary.

That is what turns freight data from passive information into something operationally useful.

Freight Data Enrichment: What Should Happen Before a Booking Decision?

Dimitrii Khristoforidi — Tue, 29 Sep 2026 06:09:42 +0000

A freight load is not a decision-ready object.

A typical load posting may contain enough information to describe the shipment:

Origin: Chicago, IL
Destination: Nashville, TN
Pickup: Today, 14:00
Delivery: Tomorrow, 09:00
Equipment: Dry Van
Rate: $1,850
Weight: 39,000 lb
Broker: ABC Logistics

At first glance, that looks like enough information to make a booking decision. In practice, it is not.

A dispatcher may still need to understand how far the truck is from pickup, what revenue per operational mile looks like after known deadhead, how the load performs after relevant trip costs and time constraints are considered, whether the pickup and delivery windows are operationally feasible, whether the broker information matches trusted records, whether there are counterparty risks, and whether the RateCon contains terms that
differ from the original posting.

Those are not simple data-entry questions. They are decision-context questions.

This is where freight data enrichment becomes important.

What Is Freight Data Enrichment?

Freight data enrichment is the process of taking raw shipment information and adding the operational, financial, geographic, counterparty, document, and risk context needed to support a booking decision.

The objective is not simply to collect more data. It is to transform:

raw freight data

into:

decision-ready freight context

That distinction matters.

A dispatch system should not rank or recommend loads simply because it has access to a load board feed. Before a recommendation becomes useful, the underlying data usually needs to be normalized, enriched, validated, and converted into explainable decision signals.

1. Establish a Valid Canonical Representation Before Decision Enrichment

Basic validation begins at ingestion. Some normalization steps, such as geocoding and company-identity resolution, may themselves require external reference data. The process is iterative rather than strictly linear.

Enrichment should not begin with inconsistent inputs. Freight data can arrive from load boards, broker emails, TMS platforms, spreadsheets, APIs, RateCons, and carrier portals. The same field may be represented differently across each source.

For example:

Chicago, IL
Chicago IL
CHICAGO, Illinois
60601
Chicago

These values may refer to overlapping geographic areas, but they do not have equal precision. Normalization should preserve that distinction rather than collapse every value into the same location.

Normalization may include standardizing city and state formats, resolving ZIP codes, normalizing equipment types, parsing pickup and delivery timestamps, converting local times correctly, separating fixed appointments from flexible windows, standardizing currency and rate fields, normalizing MC and DOT identifiers, and detecting possible duplicate or updated postings while preserving their source, version, and observed differences.

For example, a normalized location record can keep its level of precision explicit:

{
  "city": "Chicago",
  "state": "IL",
  "postal_code": "60601",
  "country": "US",
  "precision": "postal_code"
}

A repeated posting may be a duplicate, an update, or a separate opportunity on the same lane. The pipeline should resolve identity without discarding potentially meaningful changes.

The principle is simple:

Enriching inconsistent data usually produces more inconsistent data.

A reliable enrichment pipeline starts by making sure the input has a stable structure.

2. Add Geographic Context

The next layer is geographic enrichment.

A raw load may provide origin and destination, but the dispatch decision depends on more than those two points. Useful geographic context can include origin and destination coordinates, loaded miles, truck-to-pickup deadhead, estimated route, toll exposure, time zones, destination positioning, and next-load availability context.

One distinction matters especially:

Posted mileage is not the same as operational mileage.

A load may be listed as 470 miles from Chicago to Nashville. But if the truck is 58 miles away from pickup, the actual decision should consider:

Loaded miles: 470
Deadhead miles: 58
Total operational miles: 528

These distances should be calculated from sufficiently precise locations using a truck-appropriate routing method. The result should retain its provider, route assumptions, units, and calculation timestamp.

That immediately changes the economics.

A freight decision should therefore be evaluated relative to the actual truck position, not only the lane itself.

3. Add Financial Context

Raw rate is another field that looks useful but is incomplete by itself.

Suppose a load pays $1,850.

That number becomes meaningful only when it is connected to mileage and operating cost.

A basic calculation might start with:

Posted RPM = Rate / Loaded Miles

For a $1,850 load over 470 loaded miles:

$1,850 / 470 = $3.94 per loaded mile

That looks attractive.

But after including 58 miles of deadhead:

Effective RPM =
Rate / (Loaded Miles + Deadhead Miles)

the calculation becomes:
$1,850 / 528 = $3.50 per operational mile

That may still be a good result, but it is already a different decision.

A more complete financial layer may also estimate fuel consumption, tolls,
repositioning cost, variable trip costs, or expected contribution margin.

For example:

Estimated Contribution =
Rate

Fuel
Tolls
Other Incremental Trip Costs

Cost categories should be mutually exclusive and defined by a versioned carrier-specific cost policy.

These calculations are mostly deterministic. They do not require an LLM.

That is an important architectural point: use AI where interpretation is useful, but use deterministic logic where the answer can be calculated reliably.

4. Add Counterparty and Risk Context

A profitable load can still be a poor booking decision if the counterparty creates unacceptable operational or financial risk.

Before booking, a system may need to enrich the load with information such as MC and DOT identity, operating authority, broker information, applicable authority, registration, bond or trust, insurance, and filing information for the relevant entity type factoring and payment signals, fraud indicators, identity consistency, or recent company changes.

The important design principle is that risk enrichment should add context, not create unexplained certainty.

For example, this is not very useful:

Broker Risk Score: 72

unless the dispatcher can understand what contributed to that number.

A better representation may look like this:

MC record match: Matched against the checked source
Contact identity: Not independently verified
Payment data: No material negative indicators found in available coverage
Recent company changes: None found in the sources checked
Communication mismatch: Review required

Now the dispatcher can see the inputs behind the signal. That is much easier to trust and audit.

5. Add Operational Constraints

A freight opportunity does not exist in isolation. The same load may be a good choice for one truck and a poor choice for another.

Operational enrichment can include current truck position, driver availability, equipment type, pickup and delivery feasibility, Hours of Service constraints, current commitments, home-time requirements, expected dwell, and future repositioning implications.

This makes enrichment contextual.

The system is no longer asking:

Is this a good load?

It is asking a more useful question:

Is this a good load for this truck, at this time, under these constraints?
That distinction is fundamental to useful decision-support systems.

6. Enrich the Load With Document Data

A RateCon often becomes available only after the carrier and broker have provisionally agreed on the load. Its analysis therefore belongs to a pre-commitment verification stage rather than the initial opportunity-enrichment stage.

A document-processing layer may extract the final agreed rate, pickup and delivery details, appointment times, accessorial terms, detention rules, tracking requirements, lumper instructions, penalties, and special handling requirements.

But document extraction should not silently overwrite existing data.

Suppose the load posting says:

Rate: $1,850

while the RateCon says:

Rate: $1,750

The system should not simply choose one value. It should surface the conflict:

Rate discrepancy detected

Load posting: $1,850
Rate confirmation: $1,750

Action: Dispatcher review required

The same principle applies to pickup times, destinations, equipment types, and other critical fields.

Conflicting data is not noise. It is a decision signal.

7. Track Source, Freshness, and Provenance

Enriched data is only useful if the system knows where it came from and how current it is.

A useful enrichment object might look like this:

{
  "broker_authority": {
    "value": "active",
    "source": "FMCSA",
    "checked_at": "2026-09-22T14:12:00Z",
    "freshness_policy": "authority_status_v1",
    "freshness": "current"
  }
}

This introduces three important concepts.

Source tells you where the information came from.

Freshness indicates whether that observation is still usable under the policy for the current decision.

Provenance tells you how the value entered the decision pipeline.

These details matter because freight signals age at different speeds. Load availability can become stale within minutes, route conditions can change quickly, truck position may change continuously, and authority or insurance information may update on a different schedule.

That means:

Enriched does not automatically mean current.

A reliable decision-support system should know whether the data behind a recommendation is fresh, stale, missing, or conflicting.

8. Separate Deterministic Logic From AI-Assisted Logic

Not every dispatch problem should be solved with AI.

Calculations such as RPM should use deterministic formulas. Distance and toll estimates should come from appropriate routing services. Authority and registration status should come from authoritative external records with retrieval timestamps. These are deterministic workflows, but not necessarily local calculations.

AI becomes more useful where the task involves interpretation or synthesis. Examples include extracting information from unstructured documents, summarizing a RateCon, identifying unusual patterns, comparing multiple decision factors, explaining tradeoffs, drafting broker communication, or helping prioritize opportunities.

A useful architectural rule is:

Do not use an LLM to calculate something that can be calculated reliably with deterministic logic.

The strongest systems often combine both approaches. Deterministic components create reliable facts, while AI-assisted components help interpret and organize those facts.

9. Build Decision Signals, Not a Magic Score

After enrichment, the system can begin turning data into decision signals.

For example:

Economics: Above this carrier’s configured target
Deadhead: Within the configured threshold
Pickup feasibility: Tight under current HOS and routing assumptions
Authority record: Active at last check
Counterparty review: Contact identity not independently verified
Destination positioning: Weaker based on the selected market dataset

Each signal should retain the policy version, underlying facts, relevant timestamp, and carrier-specific threshold that produced it.

This is generally more useful than simply showing:

Load Score: 87/100

A single score may be convenient for ranking, but it should not hide the logic underneath.

If one load receives a higher ranking than another, the dispatcher should be able to understand why.

For example:

Load A ranks higher because:

lower deadhead
stronger effective RPM
better pickup feasibility
weaker next-load positioning

Explainability turns ranking into decision support. Without it, the system becomes a black box.

10. Missing Source Data Should Not Become Invented Fact

One of the most dangerous mistakes in data enrichment is converting uncertainty into certainty.

For example, the status of a single data field can be described like this:

{
  "availability": "known",
  "freshness": "stale",
  "consistency": "conflicting",
  "derivation": "source_reported",
  "verification": "not_verified"
}

Availability, freshness, consistency, derivation, and verification should be represented separately rather than compressed into one status.

Suppose insurance information cannot be retrieved.

A safe representation is:

Insurance status: Unavailable

A dangerous representation would be:

Insurance risk: Low

if the system simply failed to find any negative signal.

The absence of a risk signal is not evidence of low risk.

Similarly, if a field is inferred rather than verified, that distinction should remain visible.

Missing source facts should remain explicitly missing. Derived or inferred values may still be useful, but they must be labeled as estimates and retain their method, assumptions, and uncertainty.

11. What the Pre-Booking Data Pipeline Can Look Like

A simplified pipeline may look like this:

Raw Load Data
↓
Ingestion Validation and Identity Resolution
↓
Canonical Load Representation
↓
┌ Geographic and Route Context
├ Financial Calculations
├ Counterparty Context
└ Truck and Driver Constraints
↓
Action-Specific Readiness Check
↓
Decision Signals and Comparison
↓
Dispatcher Negotiation / Selection
↓
RateCon Verification, if received
↓
Final Commitment

The dependencies matter more than a single fixed order. Independent enrichment steps can run in parallel, but recommendation should wait until the requirements for that specific decision are satisfied.

Readiness should be defined per action. Ranking may tolerate estimated mileage or incomplete counterparty data, while negotiation, signing a RateCon, and committing a truck should require progressively stronger validation and approval controls.

Recommendation should happen after the system has enough reliable context to support the recommendation.

This enrichment stage is only one part of the broader dispatch architecture. The complete sequence from load ingestion and data enrichment through calculations, decision signals, document processing, and dispatcher approval is covered in how AI dispatch works.

12. A Practical Example: Chicago to Nashville

Consider a dry van load from Chicago to Nashville.

The raw load looks like this:

Origin: Chicago, IL
Destination: Nashville, TN
Rate: $1,850
Loaded miles: 470
Equipment: Dry Van
Pickup: Today

At first glance:

Posted RPM = $3.94

That may look like enough information to make a quick decision.

Now enrich it.

Geographic Context

Truck position: 58 miles from pickup
Deadhead: 58 miles
Operational miles: 528

Financial Context

Posted RPM: $3.94
Effective RPM: $3.50
Fuel estimate: calculated
Toll exposure: low

Operational Context

Pickup feasibility: achievable, but tight
Driver availability: confirmed
Equipment match: confirmed

Counterparty Context

Broker authority: active
Identity match: confirmed
Major risk signal: none detected

Network Context

Destination positioning: weaker than alternative load

Now compare that with another opportunity:

Load B

Rate: $1,720
Loaded miles: 455
Deadhead: 12 miles
Effective RPM: $3.68
Pickup feasibility: strong
Destination positioning: better
Broker context: acceptable

The first load has the higher posted rate. Based on the factors shown, Load B appears stronger on effective RPM, deadhead, pickup feasibility, and destination positioning. A final comparison would still require equivalent cost, timing, counterparty, and driver-context data for both loads.

That is the difference between raw load data and enriched decision context.

13. What Freight Data Enrichment Should Not Do

A good enrichment layer adds context without hiding uncertainty.

It should not invent missing values, silently resolve conflicting sources, mix stale and current data without distinction, convert unknown information into low risk, replace deterministic calculations with AI guesses, hide where a recommendation came from, or automatically execute irreversible actions without appropriate controls.

The purpose of enrichment is not to create artificial certainty. It is to reduce the amount of uncertainty a dispatcher must resolve manually.

From Data Enrichment to Decision Intelligence

The most important part of freight data enrichment is not the number of external data points a system can attach to a load. It is whether those data points improve the booking decision.

A useful enrichment layer should make it easier to answer questions such as:

Is this load actually profitable after deadhead?
Can this truck realistically make the appointment?
Does the counterparty information make sense?
Are there conflicts between the load posting and the RateCon?
Does this load create a stronger or weaker next position?
Which parts of the decision are certain, uncertain, or missing?

That is where enrichment becomes decision intelligence.

The raw load tells the dispatcher what is available. The enriched load helps the dispatcher understand what the opportunity actually means.

Final Takeaway

Better dispatch decisions do not begin with more automation. They begin with better context.

A reliable pre-booking workflow should move through several distinct stages:

ingest and validate
→ normalize and resolve identity
→ enrich
→ validate sources and freshness
→ calculate
→ surface uncertainty
→ build decision signals
→ check action-specific readiness
→ recommend
→ review

Only after that should the booking decision happen.

The strongest freight systems will not be the ones that simply collect the most data or automate the most clicks.

They will be the ones that can turn fragmented freight information into clear, current, explainable decision context — without pretending that uncertainty does not exist.

Why Human-in-the-Loop AI Makes Sense in Freight Dispatch

Dimitrii Khristoforidi — Mon, 21 Sep 2026 15:02:32 +0000

Freight dispatch is not a simple classification problem. It is a sequence of decisions made under changing constraints, incomplete information, time pressure, and operational risk.

A dispatcher may need to evaluate rate, loaded miles, deadhead, fuel and toll costs, pickup and delivery windows, driver hours, broker authority, identity and payment risk, destination market, reload opportunities, driver preferences, and customer relationships. Some of these variables are structured and easy to calculate, while others depend heavily on context.

That is why fully autonomous dispatch is not always the most useful goal.

A more practical model is Human-in-the-Loop AI, where AI and automation handle repetitive analysis, data enrichment, prioritization, and anomaly detection, while humans remain responsible for judgment, negotiation, exceptions, and final commitments.

For freight dispatch, this is not a compromise between manual work and automation. In many cases, it is the better system architecture.

What Human-in-the-Loop AI Means

Human-in-the-Loop, or HITL, describes systems where automation performs part of the workflow while a person remains involved at defined decision points.

The basic pattern looks like this:

Data → system processing → recommendation or alert → human decision → action

That differs from full automation:

Data → automated decision → automatic action

And it also differs from a fully manual process:

Data → human research → human calculation → human decision → action

The advantage of HITL is that each side handles the kind of work it performs best. Software is effective at processing large volumes of information quickly and consistently, while humans are better at interpreting ambiguity, weighing context, and making judgment calls.

Freight dispatch contains both types of work, which makes it a natural use case for this model.

Why Freight Dispatch Is Difficult to Fully Automate

At first glance, dispatch can look like a straightforward optimization task: a truck is available, loads are available, so the system should simply choose the best one.

In reality, “best” is rarely determined by one variable.

A load with the highest rate may have too much deadhead, weak reload potential, a difficult delivery window, questionable broker signals, poor fit with remaining driver hours, or a destination the carrier wants to avoid.

A lower-paying load may be strategically better because it positions the truck for another market, fits the driver's schedule, comes from a trusted broker, reduces empty miles, or supports a recurring lane.

Dispatch decisions combine deterministic calculations with contextual judgment. Deterministic software is usually better suited to calculations and rule-based checks, while AI can help interpret unstructured information and assemble relevant context. Humans remain responsible for consequential judgment calls.

Where AI Creates the Most Value

A large share of dispatch work is repetitive.

For each potential load, someone may need to read the details, calculate total miles, account for deadhead, calculate rate per mile, estimate fuel and toll costs, check the broker, review authority or risk data, compare the load with alternatives, inspect incoming documents, and identify obvious problems.

Doing this once is easy. Doing it continuously across dozens of opportunities creates cognitive load.

AI and automation can compress much of that process before the dispatcher needs to engage deeply.

A practical workflow might look like this:

Raw load data
↓
Data normalization
↓
Cost and RPM calculations
↓
Broker and risk enrichment
↓
Document analysis
↓
Opportunity ranking
↓
Human review

The goal is not to remove the dispatcher. It is to move the dispatcher closer to the actual decision by eliminating repetitive research and calculation.

Not Every Dispatch Problem Needs AI

This distinction matters because not every part of the workflow benefits from probabilistic systems.

Some dispatch tasks are deterministic and should stay deterministic.

For example:
total_miles = loaded_miles + deadhead_miles
rpm = rate / total_miles

estimated_contribution_margin = rate

fuel_cost
toll_cost
estimated_operating_cost
other_expected_costs

These calculations do not need an LLM. They need reliable software and accurate inputs.

AI becomes more useful when the system has to interpret less structured information, such as free-form emails, RateCons, incomplete descriptions, unusual broker communication, conflicting data, exceptions, or risk signals spread across several sources.

A strong freight AI system should therefore combine deterministic logic with probabilistic interpretation rather than use AI for every step.

Where the Human Still Matters

Negotiation

Suppose the system calculates that a load becomes attractive at $2,750 instead of the posted $2,500.

That does not mean software automatically knows the best way to reach that number. Negotiation depends on broker urgency, truck availability, lane conditions, timing, relationship history, and how much room the broker is likely to have.

AI can suggest a target, but a dispatcher can interpret the conversation and decide how aggressively to negotiate.

Driver Context

Two trucks may look identical in a scheduling system but be operationally very different.

One driver may need to return home, avoid a region, have limited available hours, prefer a certain lane, have a maintenance appointment, or already be positioned for another load.

Some of this information can be structured, but some of it exists only as operational context that humans understand better.

Exceptions

Freight operations are full of edge cases. Appointment changes, detention, incorrect pickup data, last-minute route problems, suspicious documents, unusual payment requests, driver delays, and weather disruptions can all break an otherwise normal workflow.

Well-defined cases with validated inputs and known failure modes are often easier to automate. The system must still detect when a case falls outside those conditions. Exceptions are where human judgment becomes especially valuable.

Risk Acceptance

AI can flag risk, but it cannot always decide how much risk a company should accept.

Consider two loads.

Load A

good RPM;
familiar broker;
predictable lane;
simple pickup.

Load B

higher margin;
unfamiliar broker;
recent contact change;
unusual payment information.

Software can surface those differences, but the final decision depends on the carrier's risk tolerance, operating strategy, and current context.

That is a business judgment rather than a classification task. Repeated operational constraints should be captured as structured, permissioned data where possible. Human review should cover temporary circumstances and context that has not yet been recorded, rather than compensate permanently for missing system data.

The Better Question Is Not “Can AI Make the Decision?”

A better question is:

Which parts of the decision should AI handle, and which parts should require human judgment?

A practical division might look like this:

Parse load data

System role: AI-assisted extraction
Human role:Review exceptions

Calculate RPM

System role: Deterministic
Human role: Set targets

Estimate trip costs

System role: Deterministic
Human role: Override assumptions

Compare loads

System role: Rules + ranking
Human role: Apply strategy

Check broker data

System role: Data enrichment
Human role: Decide acceptable risk

Flag inconsistencies

System role: Rules + AI
Human role: Investigate

Summarize RateCon

System role: AI-assisted
Human role: Review critical terms

Suggest negotiation range

System role: Decision support
Human role: Negotiate

Rank opportunities

System role: Rules + AI
Human role: Select final load

Commit the truck

System role: Prepare action
Human role: Final approval

This is better understood as decision augmentation than autonomous dispatch.

Human-in-the-Loop Is a Reliability Pattern

Human review improves reliability only when the reviewer has enough information, time, and authority to challenge the system. A confirmation button by itself is not a meaningful control. The interface should expose sources, assumptions, uncertainty, and the reason a case was escalated. There is another reason HITL makes sense: many AI models used for language, document, and pattern interpretation produce probabilistic outputs.

A deterministic rule behaves predictably:

if rpm < target_rpm:
mark_economics_below_target

A deterministic rule can reliably identify that a threshold was missed without deciding, by itself, that the load should be rejected.

An AI system may instead interpret documents, messages, inconsistent terminology, incomplete fields, or risk patterns.

That flexibility is useful because freight data is rarely perfectly clean, but it also introduces uncertainty.

For low-impact tasks, that uncertainty may be acceptable. For decisions with financial or operational consequences, it often makes sense to introduce review thresholds.

For example:
if required_data_valid
and no_material_risk_signals_detected
and economics_above_target:
prioritize_for_dispatcher
else:
route_to_the_relevant_review_queue

The policy should distinguish between missing data, economic exceptions, identity concerns, document conflicts, and operational constraints rather than treating every exception the same way.

The system does not need authority over every downstream action. It needs to reduce the number of situations that require deep manual investigation.

Confidence-Based Escalation

One useful HITL pattern is validation- and confidence-based exception routing. Model confidence or uncertainty signals can be useful inputs, but they should be combined with schema validation, source agreement, required-field checks, deterministic business rules, and out-of-distribution or novelty detection where applicable.

Instead of sending every case to a human, the system escalates only situations that are unusual, incomplete, or ambiguous.

A normal case might have complete information, no material identity mismatch, economics above target, no material discrepancies across the checked broker data, and clear document extraction. In that situation, AI can process and summarize the opportunity.

An exception case might contain conflicting company information, a suspicious contact change, missing fields, unusual payment details, unclear document terms, or low-confidence extraction. That case should be routed for human review.

This is more efficient than either full manual processing or blind automation because human attention is reserved for the decisions where it creates the most value.

Human Attention Is the Scarce Resource

In freight operations, data is not always the main bottleneck. Attention often is.

A dispatcher may simultaneously be searching load boards, monitoring email, talking to brokers, coordinating drivers, calculating margins, reviewing documents, and resolving exceptions.

Every additional lookup consumes attention.

If AI and automation remove ten routine checks and surface one material exception, the value is not simply automation. The value is better allocation of human attention.

The dispatcher spends less time retrieving information and more time deciding what to do with it.

A Practical HITL Architecture for Freight Dispatch

A useful architecture can be split into several layers.

Layer 1: Data Ingestion
The system receives information through authorized APIs, supported integrations, user-provided documents, and explicitly permitted inbox or browser workflows. Access should follow least-privilege principles and the connected platform’s terms.

Layer 2: Data Enrichment
Additional context can then be added, including operating authority, carrier insurance information where applicable, broker bond or trust information, payment or factoring signals, route data, and historical interactions. Each enrichment result should retain its source, retrieval time, coverage, and validation status. Missing or stale data should be shown explicitly rather than interpreted as a positive result.

Layer 3: Deterministic Processing
Calculations that should remain predictable are handled by deterministic software. This includes total miles, deadhead, RPM, fuel estimates, toll estimates, and margin calculations.

Layer 4: AI Interpretation
AI becomes useful for tasks such as extracting document fields, summarizing communication, detecting inconsistencies, grouping and explaining potential risk signals for review, and highlighting why a load may deserve attention.

Layer 5: Decision Policy
The system determines whether a case can continue through the standard workflow or whether it requires human review.

For example:
if not required_data_complete:
route_to("data_review")

elif identity_mismatch_detected:
route_to("identity_review")

elif document_conflict_detected:
route_to("document_review")

elif operational_constraint_detected:
route_to("operations_review")

elif expected_margin < target:
route_to("economic_exception")

else:
prioritize_for_dispatcher()

Layer 6: Human Decision
The dispatcher sees the opportunity together with relevant calculations, risk signals, supporting context, uncertainty, and a recommended next step.

From there, the dispatcher decides whether to contact the broker, negotiate, reject, investigate, or book.

That is the core idea behind AI Dispatch: use automation and AI to compress information and surface decisions, while keeping humans involved where judgment and commitment matter.

Human-in-the-Loop Does Not Mean Human-in-Every-Step
HITL should not mean requiring someone to approve every automated calculation. That simply recreates manual work with additional software around it.

A better pattern is selective intervention.

For example, from 100 opportunities:

60 fall below predefined economic thresholds
25 meet requirements but rank lower
10 are strong candidates
5 require exception review

The dispatcher should not need to reconstruct all 100 cases.

The system should make the 10 strong opportunities easy to compare and the
5 unusual cases easy to investigate.

Human involvement becomes targeted rather than universal.

Keep Humans in Control of Irreversible Actions

A useful design principle is to separate reversible and irreversible actions.

Lower-impact, reversible actions can usually be automated more aggressively, provided their outputs remain traceable and easy to inspect.
Their cumulative effects should still be monitored: an incorrect ranking or summary repeated at scale can materially influence decisions.

Higher-impact actions such as committing a truck, accepting contractual terms, approving a questionable counterparty, sending sensitive information, or creating a financial obligation deserve stronger human control.

The closer an action gets to creating an external commitment, the stronger the case for explicit human approval.

Human Decisions Create Better Feedback

Keeping dispatchers in the loop also creates useful feedback.

Suppose AI recommends Load A, but the dispatcher chooses Load B because it positions the truck better for tomorrow, the broker relationship is stronger, the delivery window is safer, or the driver prefers the destination.

That override contains valuable information.

With explicit feedback, outcome tracking, privacy controls, and periodic evaluation, those decisions can become useful signals for improving future recommendations. An override should not automatically be treated as a correct training label.

The feedback loop becomes:

AI recommendation → human decision → operational outcome → improved future recommendation

Human judgment is therefore not just a safeguard. It can also become a source of learning for the system.

AI Dispatch Should Reduce Cognitive Load, Not Remove Judgment

The strongest role for AI in dispatch may be decision compression.

Instead of showing a dispatcher rate, miles, deadhead, fuel estimate, toll estimate, broker data, documents, and several messages as separate inputs, the system can summarize the situation into something more actionable:

Strong margin. Moderate deadhead. Required broker checks completed against the listed sources. No material risk signals were identified in the checked data as of [timestamp].

Delivery fits the current schedule.

The underlying information still exists, but the dispatcher no longer has to reconstruct the meaning from scratch every time.

That is where AI becomes genuinely useful.

The Future of Freight Dispatch Is Probably Neither Manual nor Autonomous

The AI debate is often framed as two extremes: either humans do everything or AI does everything.

Freight dispatch points toward a third model.

Machines are good at processing large volumes of information, repeating calculations, monitoring many signals, summarizing documents, identifying patterns, and ranking opportunities.

Humans are better at interpreting ambiguity, negotiating, understanding relationships, handling exceptions, balancing competing priorities, and deciding how much risk to accept.

A strong dispatch system should combine both.

The practical architecture is simple:

Deterministic software handles calculations. AI helps interpret and organize complex information. Humans retain authority over judgment, exceptions, and external commitments.

That is not incomplete automation.

For freight dispatch, it may be the more reliable form of automation.

How AI Decision Support Fits Between Load Boards and TMS

Dimitrii Khristoforidi — Tue, 15 Sep 2026 06:28:51 +0000

Freight dispatch software has traditionally been built around two major systems.

On one side, there are load boards - marketplaces where carriers and dispatchers discover available freight.

On the other, there are Transportation Management Systems (TMS) — systems primarily used to plan and manage transportation operations, including dispatch, drivers, documents, billing, tracking, and reporting. Some TMS platforms also support quoting and pre-booking workflows.

Both are essential. But there is a gap between them.

A load board can answer: What loads are available?

A TMS can answer: What loads are we already managing?

Neither system consistently brings together every carrier-specific factor needed to answer the question dispatchers face dozens or hundreds of times per day:

Is this particular load worth booking right now?

That gap creates an opportunity for AI-assisted decision support that connects existing systems and adds carrier-specific analysis.

Rather than replacing load boards or TMS platforms, an emerging class of tools can act as a decision-support layer between freight discovery and execution.

TL;DR

Load boards answer: What freight is available?
TMS platforms answer: How do we execute and manage the load?
The missing layer answers: Should we book this load?
An AI decision layer combines load economics, deadhead, route context, broker data, risk signals, and other information before the decision.
The dispatcher stays in control; AI reduces research, calculations, and context switching.
LoadConnect is one example of this architecture, working alongside existing load boards and TMS platforms rather than replacing them.

The Traditional Dispatch Stack

A simplified carrier workflow often looks like this:

Load Board → Dispatcher → TMS

The load board provides freight opportunities.

The dispatcher evaluates them.

Once a load is accepted, the TMS becomes the primary operational system.

The architecture looks simple, but the dispatcher step in the middle is usually anything but simple.

Before accepting a load, a dispatcher may need to evaluate:

linehaul rate;
loaded miles;
deadhead to pickup;
total trip miles;
revenue per mile;
estimated fuel impact;
tolls;
pickup and delivery timing;
available driver hours and appointment feasibility, based on authorized HOS/ELD data when available;
broker authority;
broker payment history;
fraud indicators;
factoring compatibility;
route positioning;
the likelihood of finding the next load.

Much of this information does not exist in one place.

The actual workflow therefore looks more like this:

Load Board → Maps → FMCSA / broker checks → Rate calculator → Email → Spreadsheet → Dispatcher judgment → TMS

The dispatcher becomes the integration layer.

That works, but it does not scale particularly well.

Why Load Boards Do Not Solve the Entire Decision

Load boards are optimized for freight discovery. Their primary job is to connect available capacity with available freight.

Modern platforms may also provide rate information, broker ratings, routing tools, saved searches, alerts, and other useful signals.

But the existence of those signals does not necessarily mean the entire booking decision happens inside the load board.

Consider a simplified example.

A dispatcher sees two loads:

Load A

Rate: $2,800
Loaded miles: 1,000

Load B

Rate: $2,550
Loaded miles: 900

At first glance:

Load A RPM = $2.80
Load B RPM = $2.83
Load B appears slightly better.

But then deadhead is added:

Load A deadhead: 20 miles
Load B deadhead: 170 miles

Now the economics change.

Then the dispatcher notices:

Load A delivers into a strong outbound market.
Load B delivers into a weak reload market.
Broker A has established payment history.
Broker B requires additional verification.
Load B also creates a scheduling problem for the driver's next appointment.

The decision is no longer a simple load-board query. It is a multi-variable decision problem.

Why the TMS Does Not Fully Solve It Either

A TMS is usually the system of record for transportation operations.

Once a load enters the operation, a TMS can manage:

load assignments;
driver status;
equipment;
documents;
billing;
settlements;
tracking;
customer communication;
operational reporting.

But many TMS platforms are optimized around execution, not necessarily around evaluating every external spot-market opportunity before it is accepted.

That creates an architectural gap:

Freight discovery → ????? → Operational execution

The missing component is not another freight marketplace. It is a decision-support system.

The AI Decision Layer

An AI decision layer sits between discovery and execution.

A simplified architecture looks like this:

Load boards and operational systems → Decision-support layer → Dispatcher
Dispatcher-approved actions → TMS and communication tools

The purpose of the middle layer is to combine fragmented information before the dispatcher makes the final decision.

That can include:

Load data + route data + deadhead + rate information + carrier economics + broker information + fraud signals + historical context + communication + documents
Decision context

The output does not have to be:

Book this load.

A more useful system might provide:

Estimated RPM: 2.74
Deadhead: 31 miles

Broker:

Authority active
Established operating history
No major risk indicators found in the sources checked

Route:

1,042 total miles
Historical and currently available market data suggest stronger reload potential for this equipment type. Availability is not guaranteed.

Potential issue:

Delivery window may conflict with next planned load

The dispatcher still makes the decision.

The software reduces the amount of research required to make it.

Decision Support Is Different From Full Automation

This distinction matters. There is a tendency to describe every AI product as an autonomous agent that will eventually perform the entire workflow.

Freight dispatch is more nuanced.

Some tasks are highly automatable through calculations, rules, APIs, document-processing models, or a combination of these approaches:

Calculate RPM
Calculate deadhead
Extract a rate from a document
Look up an MC number
Compare structured records
Draft an email
Detect a changed field

Not every automated step requires AI. Deterministic calculations and authoritative data checks should remain deterministic; AI is most useful for interpreting unstructured information, assembling context, and explaining tradeoffs.

Other tasks depend heavily on context:

Should we accept $2.55/mile on this lane today?
Is the expected value of repositioning this truck greater than the additional fuel, time, HOS consumption, and risk of waiting for the next load?
Should we negotiate or take the current offer?
Does this broker relationship justify accepting a weaker rate?
Is this load strategically useful because of where it delivers?

Those decisions combine data with operational judgment.

A practical AI architecture therefore looks less like:

AI → autonomous booking

and more like:

AI → analysis → dispatcher decision → action

This is the human-in-the-loop model.

Where the Data Comes From

An AI decision layer becomes useful only when it can combine information from multiple sources.

For example:

Load Board → Route Data → Broker Data → Carrier Costs → AI Decision Layer → Dispatcher → TMS

The architecture becomes particularly useful when it can operate inside the existing workflow rather than forcing users to constantly open another dashboard.

That is why authorized APIs and TMS integrations are preferred where available. Browser extensions and inbox integrations can provide useful workflow access, but they require appropriate permissions, security controls, and compliance with the connected platform’s terms.

A Practical Example

Imagine a dispatcher searching a load board. A promising load appears.

Without an additional decision layer, the process might be:

Open load
Copy pickup address
Open maps
Calculate deadhead
Calculate total miles
Calculate RPM
Search broker
Check authority
Check payment information
Return to load board
Write broker email
Wait for response
Compare against another load

With a workflow-embedded decision layer:

Load data received through an authorized API, integration, or supported in-workflow interface → Route calculated → Deadhead calculated → RPM calculated → Broker context retrieved → Risk signals surfaced → Communication prepared → Dispatcher reviews

The important change is not that AI replaces the dispatcher.

The change is that information assembly becomes software work rather than dispatcher work.

Why This Architecture Matters

Freight software has accumulated many specialized systems:

load boards;
TMS platforms;
ELD systems;
mapping software;
email;
broker databases;
accounting tools;
factoring platforms;
safety databases;
document-management systems.

The problem is not a lack of software.

The problem is that the dispatcher often has to connect all of it manually.

An AI decision layer creates a different architecture:

Systems of Data → Decision Layer → Human Judgment → Systems of Execution

That pattern is not unique to trucking. Similar decision-support architectures are appearing in other data-heavy workflows where humans need to make frequent decisions using fragmented information.

Load Boards, Decision Layers, and TMS Solve Different Problems

The easiest way to think about the three systems is:

LOAD BOARD
What freight opportunities are available?
↓
DECISION-SUPPORT LAYER
How does each opportunity fit our economics, constraints, and risk criteria?
↓
DISPATCHER
Which tradeoffs are acceptable right now?
↓
TMS
How do we plan, execute, and manage the selected load?

This is why an AI decision layer should not necessarily be evaluated as a replacement for either system.

Its role is different.

A carrier may continue using DAT or Truckstop for freight discovery.

The same carrier may continue using its existing TMS for execution.

The AI layer sits between them and helps reduce the manual reasoning and data assembly required before a load enters the operational system.

An Example: LoadConnect

LoadConnect is one example of this architecture.

Rather than positioning itself as another load board or a full TMS replacement, it works around the existing dispatch workflow.

Its role is to provide an AI decision layer around load evaluation by bringing together signals such as:

RPM;
deadhead;
route context;
broker information;
factoring context;
fraud-related signals;
communication;
document analysis.

For a deeper look at how this type of system works, see AI Dispatch Software.

The broader idea is more important than any individual product: AI becomes most useful when it connects systems that already contain valuable information and surfaces that information at the moment a human needs to make a decision.

This layered model is likely to matter more as freight software becomes more specialized.

The Future Is Probably Layered, Not Monolithic

There is a recurring assumption in enterprise software that one platform will eventually replace every specialized tool.

Freight may move in the opposite direction.

The future dispatch stack may look more modular:

Marketplace Layer → Decision Layer → Execution Layer → Financial Layer → Analytics Layer

Each system can continue doing what it does best. AI becomes the connective layer that interprets data across them.

For dispatch teams, that may be more practical than replacing an entire TMS or abandoning the load boards where freight is already available.

The most important question therefore may not be:

Which AI system can automate dispatch?

It may be:

Where in the dispatch workflow does AI reduce the most decision friction without removing useful human judgment?

That is the architectural problem worth solving.

How We Decide What NOT to Automate

Dimitrii Khristoforidi — Fri, 28 Aug 2026 14:50:43 +0000

A follow-up on building an AI copilot for freight dispatch

TL;DR: We don't decide whether to automate a task based on how repetitive it looks. We look at four things: how much the right decision varies between real-world cases, the cost of being wrong, whether the task’s value comes from speed or judgment, and how quickly a wrong output would be detected.

Together, those determine whether our AI dispatch copilot should suggest, ask for confirmation, act autonomously, or stay out of the way.

Automation is not the default win condition

There's an assumption baked into a lot of AI product thinking right now: if a task can be automated, it should be. Manual is friction, automation is progress, ship it.

We don't work from that assumption anymore. Not because automation is bad - obviously most of what we build is automation - but because treating "can we automate this" as the only question skips the one that actually matters: should this specific task be automated, given what happens when it's done wrong, and how often "wrong" looks different each time.

That second part - how often "wrong" looks different - turned out to be the real hinge. A task can be low-stakes and still be a bad automation candidate if every instance of it is weird in its own way. And a task can look scary and still automate well if the failure mode is boring and consistent.

The four questions we actually ask

We stopped trying to have one big "automation philosophy" and instead run four concrete questions per feature. None of them require ML expertise. They require someone who understands the actual operational process and is willing to ask honest questions about it.

1. How much does the right decision vary from one instance to the next?

Extracting predefined fields from a rate confirmation can be relatively consistent once the prompt and extraction logic have been properly refined. In practice, reaching that level of consistency may require several rounds of prompt improvement and validation. Even then, the task is not entirely straightforward: the total may combine linehaul, fuel surcharge, accessorials, different currencies, or handwritten adjustments.

High-variance tasks are different. Negotiating detention time with a broker who's annoyed about a missed appointment involves interpreting tone, the history with that broker, and how much leverage the carrier actually has that week. Two instances of what appears to be “the same task” can therefore require completely different judgment calls.

Low decision variance → a potentially good automation candidate, provided the inputs are reliable, the output can be validated, and failures are detectable.

High decision variance often means the task cannot be made reliably automatable through prompt engineering alone. It may require richer context, structured rules, specialized tools, historical data, or human review to handle different scenarios consistently.

2. What does a wrong output cost, and does the cost scale with volume?

This sounds like the reversibility question from our earlier post, “Where Should an AI Agent’s Autonomy End?”, but it's slightly different — it's about whether errors compound. Auto-flagging a possible detention clause mismatch that turns out to be a false positive costs a dispatcher thirty seconds of annoyance. Auto-sending a rate counter-offer that's off by a meaningful margin, at volume, across dozens of loads a week, doesn't just cost thirty seconds each time - it can quietly damage a broker relationship you didn't even know was at risk until the relationship is already gone.

Even small errors create operational costs, and those costs accumulate as volume grows. Some errors scale roughly in proportion to the number of occurrences, while others create disproportionate or delayed damage by eroding trust, reputation, or a counterparty’s willingness to work with you again.

3. Is the value of doing it mostly about speed, or mostly about judgment?

Some manual tasks are slow because nobody's built the tooling yet - that's a straightforward automation opportunity. Others are slow because they require judgment, and the slowness isn't the bug; it's the mechanism by which a human catches something a faster process would have missed.

Confusing these two is probably the single most common mistake in early-stage automation decisions: “this takes a dispatcher ten minutes” gets read as “this is inefficient” instead of “this is where the actual thinking happens.”

4. How quickly and reliably will we detect a wrong output?

A reversible error is only safe if someone notices it in time. Some failures become obvious immediately — through a validation check, a dispatcher catching the issue, or a product metric moving in the wrong direction. Others may surface only days or weeks later, through a damaged broker relationship, a lost customer, or a pattern of operational friction that is difficult to trace back to a specific automated decision.

This matters beyond the product itself. An incorrect output can affect how a dispatcher communicates with a broker and, if it goes unnoticed, influence the relationship between them.

The longer and less reliable the feedback loop, the less autonomy we should give the system.

This is also how we think about agent autonomy: it's not a property we give an agent once. It's something we earn task by task.

Autonomy should be earned per task, not granted to the agent as a whole.

That's why we don't think about an AI copilot as simply being “autonomous” or “not autonomous.” Different tasks can - and should - have different levels of autonomy.

We start with decision variance and failure cost, then adjust the level of autonomy based on how much judgment the task requires and how quickly and reliably failures can be detected.

That's the approach we're taking with LoadConnect's dispatch workflow automation, where different tasks can have different levels of autonomy depending on decision variance, failure cost, and the need for human judgment.

A framework, roughly

We use decision variance and cost-if-wrong as the first pass — effectively a 2×2 for determining the initial level of autonomy:

Low variance + Low cost if wrong → Automate freely
Low variance + High cost if wrong → Automate + confirmation
High variance + Low cost if wrong → Draft / suggestion + human finalizes
High variance + High cost if wrong → Keep manual

The matrix is only the first pass. Whether the task’s value comes primarily from speed or judgment acts as a separate filter: if judgment is central to the task, we lower the level of autonomy by one step.

Detection speed is another. Even a low-cost, reversible failure deserves less autonomy if we are unlikely to notice it quickly and reliably.

In practice, these autonomy levels map to different system designs. “Automate freely” still means validation and logging. “Automate + confirmation” means generating a structured action but requiring explicit dispatcher approval. “Draft / suggestion” means the model can prepare the response but cannot execute it. “Keep manual” means AI may retrieve context or summarize information, but the actual decision remains outside the agent.

The more autonomy we give a task, the more explicit its validation, logging, and failure signals need to become.

The goal isn't maximum automation. It's the right level of automation for the task.

The high-variance, high-cost category is smaller than people expect. But it is also where the “automate everything” instinct can do the most damage. These tasks often look repetitive and well-defined from a distance, but become much less predictable once you examine real-world cases and the consequences of getting them wrong.

An example that goes the "wrong" way on purpose

Most of what I write about tends to be examples where we correctly chose not to automate something. It's worth including one where we got it wrong first.

Early on, we built a feature that automatically sent a standard response when a load’s pickup window changed slightly — a templated “here’s the updated appointment, please confirm” type of message. On paper, it looked like a low-variance task: a time changed, so send an update.

In practice, the reasons behind those pickup window changes turned out to be far more varied than the template assumed. Sometimes the change was routine. Other times, it signaled a larger issue with the shipper that the dispatcher needed to address directly rather than paper over with an automated message.

We had measured variance at the surface of the task — a timestamp changed — instead of at the level of the decision underneath it, where the real variation was.

Surface-level variance ≠ decision-level variance.

We walked the automation back to a suggestion the dispatcher reviews before sending, rather than an auto-send.

The lesson wasn't "don't automate messaging." It was: **measure variance at the level that actually matters, not the level that's easiest to measure. **A timestamp is easy to check for variance. The judgment call underneath it isn't, and that's usually the one that counts.

What this costs us

Being disciplined about this has a real cost, and it's worth naming instead of glossing over: it means shipping fewer flashy "the AI just does it for you" features than we technically could. Some AI demos look more impressive because they auto-execute actions that we deliberately keep behind a confirmation step.

We've made peace with that trade. A demo that auto-books a load looks great in a thirty-second clip. It looks a lot worse the first time it books the wrong one, and in freight, that first time is a phone call and a canceled contract, not a bug report.

The checklist, if you want to steal it

Before we automate a task fully - not just assist with it, actually remove the human step - we want honest answers to:

If we sampled a representative set of real instances — including rare and high-impact edge cases — would they require essentially the same decision, or are meaningfully different situations hiding under the same label? Are we measuring variance at the level of the actual decision, rather than just the surface of the task?
Does a wrong output stay a small, contained mistake, or can its financial, operational, or reputational cost compound as volume grows?
Is the current “slowness” of this task mostly wasted motion, or is it where a human is actually doing the hard part?
If the system gets this wrong, how quickly and reliably will we know — and who is likely to notice first, us or the customer?

That last one matters more than it sounds. Some bad automation decisions surface immediately, in your own metrics. Others surface three weeks later, in a broker's inbox, and by then it's not really a product decision anymore - it's damage control.

Closing thought

"What should we automate" gets asked constantly in AI products right now. "What should we deliberately not automate, and why" gets asked a lot less, and it's usually the more useful question - because it's the one that forces you to actually understand the task instead of just measuring how often it repeats.

What's one task your team has deliberately kept human-in-the-loop - and what made you decide not to automate it?

Where Should an AI Agent's Autonomy End?

Dimitrii Khristoforidi — Fri, 14 Aug 2026 12:13:38 +0000

Notes from building an AI copilot for freight dispatch

TL;DR: Every few weeks, another "AI agent" launches that can act on someone's behalf — booking things, sending things, updating things. The interesting engineering question isn't "what can it do?" It's "where should we draw the line, and why?" This post is about how we thought through that line while building the AI assistant inside LoadConnect, a dispatch tool that helps truck carriers and dispatchers analyze loads, rate confirmations, and carrier information.

The wrong question

When people talk about AI agents, the conversation usually starts with capability.

Can it read a document? Fill out a form? Call an API and take an action without a human in the loop?

That's a fun question to build for. It's also, in my experience, the wrong first question.

A more useful question is: what does the agent have access to, what can it do with that access, and what happens when it gets something wrong?
These are related, but they're not the same thing:

Capability - what the model can understand, generate, or reason about.
Access - what data, sessions, and systems the agent can technically reach.
Autonomy - what the agent is allowed to do with that access without human confirmation.

You can have a highly capable model with almost no autonomy - it analyzes and recommends, but never acts. You can also have a relatively simple system with dangerously high autonomy because it can make changes on its own.

So the risk profile isn't determined by model capability alone. It depends on the combination of access, autonomy, likelihood of failure, and potential impact.

Two axes, not one

Capability still matters, but it's not the main architectural lever we can control. For the system we were building, the most useful way to reason about risk was to map access and autonomy separately:

Low Access + Low Autonomy → Low Risk
Low Access + High Autonomy → Moderate Risk
High Access + Low Autonomy → Moderate Risk
High Access + High Autonomy → High Risk

The dangerous quadrant isn't necessarily "highly intelligent AI." It's a system that combines broad access with broad autonomy.

Capability affects how well an agent can perform a task - and how sophisticated its mistakes might be. But access and autonomy determine how far those mistakes can propagate.

A highly capable model with access limited to a single document and no ability to take external actions has a relatively small blast radius. A much simpler system can become significantly riskier if it can access sensitive data and make irreversible changes without confirmation.

That distinction became one of the most useful mental models for us when deciding what our assistant should - and shouldn't - be allowed to do.

Why this isn't abstract in freight

Dispatch is a good stress test for this idea because the cost of a wrong autonomous action is immediate and expensive. If an agent misreads a rate confirmation and books the wrong appointment window, that's not a UX bug - it's a missed delivery, a detention fee, or even a damaged relationship with a broker.

So when we were designing the AI assistant, "what should it be allowed to decide on its own" wasn't a philosophical question - it was a product requirement with real financial consequences.

Consider a rate confirmation. Before signing or otherwise accepting the final terms, the dispatcher reviews it to verify that it matches the negotiated load. The assistant helps with the understanding part - extracting the rate and mileage, calculating RPM, flagging detention terms, catching inconsistencies between the document and the load details, summarizing what deserves attention. It does not touch the commitment part - it doesn't accept the load, message the broker, change the appointment, or modify the booking on the carrier's behalf.

The distinction isn't about whether the model could technically perform those actions. It's about whether the system should give the model the permissions required to perform them. We want the assistant to reduce the work required to make a decision - without quietly becoming the decision-maker.

That split turned into two separate design decisions we now make independently for every feature:

What information does this feature actually need to see to do its job - not what would be convenient, but the minimum required.
What is the agent allowed to do with what it finds - surface it, or act on it?

Treating these as one decision ("give it access and let it be smart about the rest") is, in my opinion, where most agent projects get into trouble.

Access: a deliberately narrow scope

The basic architecture is intentionally boring:

User selects a document or load
↓
Relevant content is extracted
↓
Scoped AI task is created
↓
AI analyzes the available information
↓
Recommendation / result is returned
↓
Human decides what happens next

The important part is what isn't in this flow. The agent doesn't get access to the user's authenticated browser session, cookies, or credentials. It doesn't continuously observe other tabs or websites. It doesn't have a general-purpose action layer that can execute arbitrary changes.

A simplified permission model looks more like this:

AI Assistant
├── Read selected document
├── Analyze extracted data
├── Calculate relevant metrics
└── Recommend an action

✕ Access credentials
✕ Read unrelated browser sessions
✕ Monitor activity in the background
✕ Send external messages
✕ Book or modify loads
✕ Change external systems

This creates a useful property: even if the model produces an unexpected output, the set of things that output can affect is already constrained by the architecture - not by a rule the model is trusted to follow.

The instinct when building an assistant is to wire it into everything, because more context makes the model perform better in demos. The problem is that "better in demos" and "safe in production" can pull in opposite directions. The rule we settled on is simple to state and annoying to actually follow: an agent should only touch what its current task needs, for as long as the task requires it. No background processes, no session or credential access, no cross-site visibility, no accumulating data "because it might be useful later."

None of this is exotic security engineering - it's mostly saying no to permissions during the design phase instead of restricting them with policy afterward. Saying no early is a lot cheaper than walking back scope creep once a feature ships and people depend on it.

Autonomy: think in terms of blast radius, not just error rate

The second axis is where it gets more interesting, because autonomy is about trust as much as it is about architecture.

There's a meaningful difference between an agent that says "this rate confirmation has a mismatched detention clause, you should look at it," and one that silently updates the record itself. Both use the same model. Both might even be equally reliable most of the time. But only one of them leaves a human in a position to catch the cases where the model is wrong before that mistake becomes a real-world consequence.

Not every model error has the same consequence, so it's worth separating capability from what happens when that capability fails:

Extract information → Misreads a rate → Incorrect recommendation
Calculate RPM → Uses the wrong mileage → Poor dispatch decision
Flag a contract issue → Misses a clause → Risk goes unnoticed
Send a broker message → Sends incorrect information → External commitment
Change an appointment → Picks the wrong time → Operational disruption
Book a load → Selects the wrong load → Financial and reputational impact

A wrong recommendation can be reviewed and may be caught before it produces an external consequence. A wrong external action may already have created a commitment before anyone notices. That's why we think about autonomy partly in terms of reversibility: the more consequential or irreversible an action is, the stronger the case for keeping a human confirmation step - regardless of how confident the model is.

A useful rule of thumb that came out of this: analyze → recommend → confirm → execute. The first two steps are where an AI assistant provides real leverage. The last two are where human responsibility stays, on purpose.

That doesn't mean every AI action needs a confirmation dialog - low-risk, reversible operations can often run on their own. But when an action creates an external commitment or is hard to reverse, the default should be human confirmation. The question isn't "can the model do this?" It's "what happens if the model is wrong and nobody stops it?" That question changes the design discussion considerably.

In our case, it led to a deliberately conservative boundary: the agent analyzes, flags, and recommends. It does not approve, execute, or take ownership of an outcome, because accountability must remain assigned to identifiable people and organizations; it cannot be delegated to the model. If something goes wrong, "the agent decided" isn't an answer anyone in freight - or honestly, anywhere - is going to accept.

We're building LoadConnect as an AI dispatch copilot that helps dispatchers analyze information, surface risks, and make better decisions while keeping higher-risk actions and external commitments under human control.

A framing that's helped more than any specific rule

The framing we kept coming back to, especially when a new feature request tempted us to expand scope, was this: don't build a system that's secure because of policy - build one where the risky thing simply isn't possible by design.

A policy says "the agent shouldn't do X." Architecture should make prohibited high-impact actions unreachable by the model, while policy, authorization, monitoring, and data-handling controls address the remaining risks. It's a more boring way to build software. It's also a lot more resilient, because it doesn't depend on every future engineer remembering the rule, or every prompt update preserving the guardrail.

Questions worth asking before you widen an agent's scope

If you're building an AI agent right now, here's roughly the checklist we run through before adding a new capability:

What does the agent actually need to see? Does this feature require a new data source, or would access simply be more convenient?
What's the blast radius if it gets this wrong? A bad recommendation, or an external commitment?
Is this analysis or action? Are we asking the agent to understand something, or to change something?
If it's an action - is it reversible? The harder it is to undo, the stronger the case for human confirmation.
What's the minimum permission required? If the feature works without credentials or persistent sessions, don't add them "just in case."
Do we need this access now, or are we adding it for a possible future use case? If it's the latter, don't add it yet.

The goal isn't to make an agent incapable of doing useful work. It's to make the boundary between what the agent can understand and what it can change explicit - as a product decision, a security decision, and an architectural decision, not something left to a prompt.

None of these questions require exotic tooling to answer. They mostly require being willing to say no to your own feature ideas, which is the actual hard part.

Closing thought

The capabilities will keep expanding. The boundary shouldn't have to move at the same speed.

What an agent can do will keep getting more impressive every quarter. What it should be allowed to do on its own is a much slower-moving, much more durable question - and it's the one that ultimately determines whether people trust the system enough to let it near their real work.

I'm curious how other teams building AI agents are drawing this line internally — especially in domains where a wrong autonomous action has a real, immediate cost. Happy to compare notes in the comments.