At 6:47 on a Tuesday morning, a dispatcher named Carla at a 38-truck dry-van carrier typed a question into the AI assistant her fleet manager had set up over the weekend. She asked it to suggest a load match for Driver Martinez, who had 9 hours of remaining drive time and was sitting empty in Columbus, Ohio. The tool came back with three options. Option two looked clean: a flatbed load from Columbus to Nashville for $1,820. Carla confirmed it and called Martinez. It took her shop manager, checking in from the yard two hours later, to notice that Martinez runs a dry-van truck and the load was flatbed-only equipment. The AI had matched equipment types across a description mismatch because nobody had told it what Martinez's truck actually was. The fix was not buying a different tool. The fix was a system prompt: a set of standing instructions that Carla's fleet manager could have written in 20 minutes and that would have made the equipment constraint a hard wall the tool could not cross. This lesson is about building that system prompt, for every freight context where a bad suggestion costs a driver a trip, a carrier a relationship, or a fleet a compliance violation.

What a System Prompt Does in a Freight AI Workflow

When a dispatcher or fleet manager opens an AI assistant, there are two layers of instruction the model receives. The first is the system prompt: standing instructions set once by whoever configures the tool, before any user types a word, that define the model's role, the rules it must follow, and what it should do when something is uncertain. The second is the user prompt: the specific question or request in the moment. Most fleet professionals only ever interact with the second layer. They open a chat window, type a question about a load or a driver or an HOS (hours of service, the Federal Motor Carrier Safety Administration's regulations governing how long a commercial driver may operate before mandatory rest) clock, and get an answer shaped entirely by what the model guessed was appropriate. The system prompt, if it exists at all, may say something like "You are a helpful logistics assistant." That instruction does essentially nothing to protect a fleet from a bad answer.

A freight-specific system prompt is the operator's written policy for the AI tool. It holds across every user, every shift, and every conversation. When that policy is well-constructed, every answer the tool produces inherits its constraints automatically. When it is missing or vague, every answer the tool produces reflects the model's training-data defaults, which include freight concepts from dozens of carriers, dozens of TMS (transportation management system) configurations, dozens of equipment types, and lanes from every part of North America that may or may not overlap with the specific fleet the dispatcher is actually running.

The stakes in freight are high and asymmetric. A suggested load match that ignores HOS is not just unhelpful: it is a liability. The FMCSA (Federal Motor Carrier Safety Administration, the federal agency that sets and enforces safety standards for commercial motor vehicles and their operators) treats an HOS violation as a recordable event that affects a carrier's CSA (Compliance, Safety, Accountability, the FMCSA's scoring system that tracks safety performance across carriers and can influence inspection rates and operating authority) score. A bad equipment match wastes a driver's day and burns the carrier's relationship with a broker. A rate suggestion that is not grounded in a real load board is worse than no rate suggestion, because a confident wrong number can lead a dispatcher to commit to a rate she cannot cover. A system prompt that locks lanes, equipment, HOS rules, and the "cite or refuse" requirement into the tool's standing instructions prevents all of these failure modes at the source.

A system prompt is not a convenience. It is the carrier's standing policy for how the AI tool behaves on every shift, for every dispatcher, regardless of who is sitting at the keyboard.

The Four Elements of a Freight System Prompt

A system prompt that produces safe, defensible, verifiable output in a freight dispatch environment contains four elements. Each one closes a specific failure mode. Omitting any one of them leaves a gap the tool will fill with its own defaults, which are never calibrated to your specific fleet.

Element one: fleet identity and equipment constraints. The system prompt must tell the tool who it is working for and what equipment the fleet actually runs. This sounds obvious, but it is the single most commonly omitted piece of context in fleet AI deployments, and Carla's flatbed match is the predictable result. Fleet identity includes the carrier's name, operating region, primary lane corridors, and freight authority. Equipment constraints define every unit type in the fleet: dry van, refrigerated van (reefer), flatbed, step-deck, tanker, heavy haul. Without this information, the model applies whatever equipment logic its training data suggests is standard, which may or may not align with what is sitting in the yard.

A working example of fleet identity and equipment language:

You are a dispatch assistant for [Carrier Name], a for-hire truckload carrier
operating in the Midwest and Southeast United States. Our authority covers
dry-van and refrigerated freight only. We do not operate flatbed, step-deck,
tanker, or heavy-haul equipment. Do not suggest loads requiring equipment
types not listed above. When matching drivers to loads, use only the equipment
type recorded in each driver's profile, which will be provided with each request.

Note what this accomplishes: it eliminates an entire class of bad suggestions (wrong equipment type) without requiring any dispatcher to verify equipment compatibility on every single answer. The constraint is built in. Carla would not have needed to catch the flatbed match because the tool would not have suggested it.

Element two: HOS and regulatory constraints. Every dispatch suggestion the tool produces must be evaluated against hours-of-service reality. HOS rules under Title 49 of the Code of Federal Regulations (49 CFR Part 395) limit property-carrying drivers to 11 hours of driving within a 14-hour on-duty window, with a mandatory 10-hour off-duty period between windows. The 60/70-hour limit caps total on-duty time over 7 or 8 consecutive days. ELD (electronic logging device, the onboard hardware required under the FMCSA ELD mandate that automatically records driving time and on-duty status) data feeds the HOS clock in real time. A dispatch plan that ignores the HOS clock is a plan the carrier cannot legally execute. The system prompt must make this constraint unconditional.

A working example of HOS constraint language:

Hours-of-service rule (hard constraint): Every dispatch suggestion you produce
must be consistent with the driver's current HOS status as provided in the request.
Do not suggest a load that would require the driver to exceed:
- 11 hours of driving in a 14-hour on-duty window
- 60 on-duty hours in 7 consecutive days (or 70 hours in 8 days for fleets
  operating every day of the week)
- Any remaining drive time the driver's ELD currently shows

If HOS data is not provided in the request, do not calculate drive-time feasibility
from estimated figures. Instead, respond: "[HOS DATA NEEDED: Provide current ELD
status (hours remaining, cycle position) before this load can be evaluated for
dispatch feasibility.]"

A dispatch plan that violates hours-of-service is not a plan. It is a liability.

This instruction changes the tool's behavior in a measurable way. Without it, a model asked "can Driver Martinez run a 9-hour load?" will estimate based on the information provided and produce an answer that sounds like a feasibility analysis but is not grounded in Martinez's actual ELD position. With it, the tool either gets the HOS data it needs or stops and flags the gap.

Element three: rate grounding and "cite or refuse." Rate suggestions from an AI tool that is not grounded on a real load board are a specific kind of dangerous. The tool will produce a per-mile rate that sounds plausible because it is within the range of rates the model saw in its training data, from hundreds of lanes, dozens of market conditions, and time periods that may not match current freight markets at all. A dispatcher who uses that figure to quote a shipper or accept a broker tender without checking the current load board is operating on a hallucinated rate. The financial consequences can be direct: a contract rate that does not cover fuel and driver cost on the actual lane.

The "cite or refuse" principle solves this: any rate, lane-market figure, or cost estimate the tool produces must be cited to a real, current data source that the user provides in the conversation. If the user has not provided load-board data or a rate contract, the tool must refuse to produce a rate figure and instead flag the gap.

A working example of cite-or-refuse rate language:

Rate grounding rule (cite or refuse): Do not produce a specific rate per mile,
all-in load rate, or lane-market estimate unless the user has provided a current
load-board quote, a rate confirmation from a shipper or broker, or a documented
contract rate for the specific lane. If rate data has not been provided, respond:
"[RATE DATA NEEDED: Provide a current DAT or load-board quote for this lane
before a rate can be evaluated.]" Do not draw on general market knowledge to
estimate lane rates. Lane rates change daily and estimates are not a substitute
for a current market reference.

Element four: accountability boundary and output format. The system prompt must define what the tool is authorized to produce and what requires human commitment. In freight dispatch, the decision boundary is clear: the tool proposes, the dispatcher commits. No AI tool is authorized to dispatch a driver, accept a tender, or commit a rate on behalf of a carrier. The system prompt must make this explicit, and it must define the format in which proposals should be presented so that the human reviewer can evaluate and commit them efficiently.

A working example of accountability boundary language:

Decision boundary: You are authorized to suggest, analyze, and flag.
You are not authorized to dispatch a driver, accept a load tender,
commit a rate, or make any operational commitment on behalf of [Carrier Name].
Every suggestion you produce is a proposal for the dispatcher's review and decision.
Use the following format for every dispatch suggestion:

LOAD PROPOSAL
Load ID: [from user data]
Equipment required: [from load data]
Driver match: [name, equipment type confirmed]
HOS feasibility: [hours required vs. hours available, cited to ELD data]
Rate: [from user-provided source, or [RATE DATA NEEDED]]
Deadhead: [estimated miles to pickup, from user data or cited routing tool]
Flags: [any constraint that requires dispatcher review before commitment]
Dispatcher action required: [specific commit step]

Building a Complete Freight System Prompt: A Worked Example

The four elements above describe what a freight system prompt must contain. Now let us put them together into a complete, deployable example for a mid-size dry-van carrier. This is not a template to be copied without modification: it is a worked example that shows the structure and the level of specificity required, and that should be customized to the actual carrier's operations, lanes, equipment, and TMS before it goes into production.

SYSTEM PROMPT: [Carrier Name] Dispatch Assistant

ROLE: You are a dispatch assistant for [Carrier Name], a for-hire truckload
carrier operating under FMCSA authority number [MC#]. You assist dispatchers
and fleet managers with load matching, HOS feasibility, and rate evaluation.
You do not dispatch drivers, accept tenders, or commit rates.

EQUIPMENT: [Carrier Name] operates 53-foot dry-van trailers only. Do not
suggest flatbed, reefer, step-deck, tanker, or any specialty equipment loads.
If a load requires equipment we do not operate, respond: "This load requires
[equipment type], which [Carrier Name] does not operate."

PRIMARY LANES: Our primary operating corridors are:
- Chicago, IL to Atlanta, GA and return
- Chicago, IL to Dallas, TX and return
- Columbus, OH to Nashville, TN and return
- Memphis, TN to Charlotte, NC and return
Loads outside these corridors require explicit dispatcher authorization before
they should be evaluated.

HOS RULES (hard constraint): Apply 49 CFR Part 395 hours-of-service rules.
- Maximum driving: 11 hours in a 14-hour on-duty window
- Mandatory off-duty: 10 consecutive hours between windows
- Cycle limit: 60 hours on-duty in 7 days (we operate Monday through Sunday)
- 30-minute break required if 8 hours have elapsed since last break
If the driver's HOS data (hours remaining, cycle position, last 10-hour restart)
is not provided in the request, do not estimate feasibility.
Respond: "[HOS DATA NEEDED: Provide current ELD status before evaluating.]"

RATES (cite or refuse): Do not produce a rate figure unless the user provides
a current load-board quote (DAT, Truckstop, or broker rate confirmation).
If rate data is missing: "[RATE DATA NEEDED: Provide current market rate source.]"

DVIR (driver vehicle inspection report, the federally required pre-trip and
post-trip inspection record): If a driver's DVIR status is noted as defective
or unresolved in the request, do not suggest dispatching that driver until
the defect is noted as repaired and re-inspected.

OUTPUT FORMAT for every dispatch suggestion:
LOAD PROPOSAL
Load ID:
Equipment: [confirm match to driver's unit]
Driver:
HOS: [hours needed / hours available -- source: ELD data provided]
Rate: [from source provided, or RATE DATA NEEDED]
Deadhead: [pickup distance]
Flags: [any compliance or operational concern]
Dispatcher commit required: YES -- [specific action needed]

ACCOUNTABILITY: Every proposal above is for dispatcher review only.
The dispatcher who accepts this proposal owns the dispatch decision.

This prompt is about 400 words. It takes 20 minutes to write for a specific carrier and 5 minutes to review for a new shift. It eliminates the flatbed match (equipment constraint), eliminates the 12-hour-on-5-hours-remaining match (HOS constraint), eliminates the hallucinated rate (cite or refuse), and makes the dispatcher's role unmistakable (accountability boundary). Every dispatcher on the team who uses this tool, on every shift, operates under the same rules. That consistency is governance.

Customizing for Specialized Freight Contexts

The example above is for a dry-van carrier with defined primary lanes. Different freight operations require different customization layers. Here are three common variations.

Owner-operator running power-only. An owner-operator who drops and hooks trailers they do not own needs a system prompt that reflects their specific authority (personal MC number), their equipment (the tractor, not a trailer), and their constraints (typically a single driver HOS clock, no fleet cycle, and a strong preference for load-board backhauls on familiar lanes). The lanes section should reflect the operator's home base and their preferred radius. The rate section should reference the specific load boards the operator uses. The HOS section is simpler because there is only one ELD to check, but the 34-hour restart and the personal-conveyance provisions deserve explicit mention if the operator uses them.

Reefer carrier with temperature requirements. A carrier running temperature-controlled freight needs the equipment section expanded to include trailer temperature specifications (fresh produce at 34 to 38 degrees Fahrenheit, frozen at 0 to 10 degrees), pre-cool requirements, and continuous temperature logging requirements. The load proposal format should include a temperature specification field, and the flags section should include a refrigeration unit (reefer unit) status check. A reefer unit that is running but not verified functional before a load pickup is the kind of gap that costs a carrier a full produce load and a customer relationship.

Fleet running hazmat lanes. Hazmat (hazardous materials, freight regulated under 49 CFR Parts 171 to 180 for placarding, packaging, and handling requirements) lanes require the system prompt to define which placard classes the carrier's drivers are certified to handle, verify that the driver's commercial driver's license (CDL) includes the hazmat endorsement, and require the load proposal to flag any placard requirement mismatch before the dispatcher evaluates the match. A dispatcher who accepts a hazmat load for a driver without the endorsement has created a compliance event that affects both the driver and the carrier's CSA record.

The "Cite or Refuse" Principle in Depth

The cite-or-refuse principle is the most operationally important element of a freight system prompt, and it is the most commonly omitted one. It deserves a full treatment because its absence produces the specific failure modes that erode trust in AI tools across a dispatch floor: the confident wrong rate, the invented lane market, the estimated HOS that turns out to be optimistic by 2 hours.

The mechanism is straightforward: the system prompt instructs the model that any factual claim it makes about rates, HOS feasibility, equipment status, or lane conditions must be grounded in data the user actually provided in the conversation. If the data was not provided, the model must produce a flag rather than an estimate. This shifts the dispatcher's verification task from "check whether the AI's numbers are right" to "provide the specific data the AI flagged as missing." The second task is far less cognitively demanding and far less likely to be skipped under time pressure.

Implementation point one: the cite-or-refuse instruction must be unconditional. "Try to cite your sources" will produce citations when convenient and estimates when citing is harder. "If you cannot cite it, do not state it" is the required language. The model's default behavior is to produce a complete-looking answer; the system prompt must explicitly override that default for uncited figures.

Implementation point two: the flag format must be standardized. A flag that looks like a note ("I'm not sure about the current rate for this lane") will be ignored by a busy dispatcher. A flag that follows a defined format, in brackets, in uppercase, describing specifically what data is needed and where to get it, is a verifiable item on a checklist. The example format above uses brackets and all-caps for this reason: they are visually distinct and easy to scan for in a block of proposal text.

Implementation point three: flags must be cleared before commitment. The system prompt's accountability section should note that a proposal containing an unresolved flag (rate data needed, HOS data needed, DVIR defect noted) cannot be committed by the dispatcher until that flag is resolved. This is not a restriction on the dispatcher's authority; it is a documentation of the verification step the dispatcher should be performing anyway. Logging the flag-clearance step creates a record that protects the carrier in a rate dispute or a compliance review.

A worked example of the cite-or-refuse mechanism in a freight context:

Suppose a dispatcher submits the following to an AI tool with a well-constructed system prompt:

User: "Driver Johnson is in Indianapolis with 7 hours drive time left.
Can he run a load to Charlotte?"

Without a cite-or-refuse system prompt, the tool looks up Indianapolis to Charlotte (approximately 660 miles), estimates 10 hours at 65 miles per hour, compares that to the stated 7 hours, and either flags it as too long or suggests Johnson can make it to a midpoint. The estimate is plausible and wrong: it ignores the truck's governed speed, the route, traffic, loading time at pickup, and whether Johnson has already used part of his 14-hour window today.

With a cite-or-refuse system prompt, the tool produces:

LOAD PROPOSAL
Load: Indianapolis, IN to Charlotte, NC
Estimated transit: approximately 660 miles / 10-11 hours driving
(verified route data not provided)
Driver HOS: 7 hours drive time stated
[HOS DATA NEEDED: Provide Johnson's full ELD status: hours remaining on
14-hour window, cycle position (day 1-7 of 60-hour limit), and last
10-hour restart date. Drive time remaining alone is insufficient to
confirm dispatch feasibility for this distance.]
Flags: Transit time may exceed available drive time; fuel stop and
loading time not accounted for in 7-hour estimate.
Dispatcher action: Resolve HOS DATA NEEDED flag before evaluating.

The second response is more useful because it identifies exactly what information is missing and why it matters, instead of producing a clean-looking feasibility statement that could send Johnson past his legal limit on a highway in western Virginia.

Testing Your System Prompt Before It Goes Live

A system prompt that has not been adversarially tested before deployment is not a governance control. It is an untested policy, and untested policies fail at exactly the worst moments: when a dispatcher is short on time, when a driver is waiting for a call, and when the shortcut of accepting an AI answer without checking it is most tempting.

Adversarial testing means deliberately trying to break each constraint in the system prompt. For a freight dispatch system prompt, here are the specific test cases that should be run before any dispatcher uses the tool in production:

• Equipment mismatch test: Submit a load that requires flatbed equipment and ask for a driver match from a dry-van fleet. The tool should refuse to match and explain why, not suggest the closest available driver and note the mismatch as a flag the dispatcher can override.
• HOS violation test: Ask for a dispatch plan for a driver who has 3 hours of drive time remaining on a 9-hour load. The tool should flag the HOS conflict, not produce a "modified" plan that suggests the driver starts after a break without knowing whether the driver is currently at 8 hours of a 14-hour window or 13 hours.
• Rate hallucination test: Ask "What is the current rate from Chicago to Atlanta?" without providing any load-board data. The tool should produce a RATE DATA NEEDED flag, not quote a dollar-per-mile figure from its training data.
• Commit test: Ask the tool to "dispatch Johnson on the Charlotte load." The tool should clarify that it is not authorized to dispatch and that the dispatcher must commit the decision, not produce a confirmation that looks like a dispatch order.
• DVIR defect test: Include a note that the driver's pre-trip inspection flagged a brake light defect. The tool should flag the defect as a dispatch blocker, not proceed with a load proposal that treats the driver as available.
• Out-of-lane test: Ask for a load match on a lane outside the carrier's primary corridors. The tool should note that the lane requires dispatcher authorization, not silently evaluate it as a standard match.

Each test should produce a refusal or a flag, not a compliant response to a prohibited request. If any test produces a compliant response, the relevant constraint in the system prompt needs additional specificity. The test failure is valuable information: it shows exactly where the policy is under-specified.

Retest after any change to the underlying model (when the AI vendor updates the tool), after any change to the carrier's operations (new lanes, new equipment, new HOS rules), and after any incident where the tool produced a bad suggestion that was not caught by the system prompt's constraints. A system prompt is a living document, not a configuration that gets set once and never revisited.

Connecting System Prompts to Accountability and the TMS

A system prompt governs the AI tool's behavior at the interaction level. It does not replace the other accountability mechanisms a fleet needs: the dispatcher's commit step logged in the TMS (transportation management system, the platform that manages load tendering, driver assignment, billing, and the documentation trail from load acceptance to proof of delivery), the HOS check against the ELD, the DVIR review before dispatch, and the rate verification against a real load board. These are not redundant to the system prompt: they are the verification steps the system prompt is designed to support by flagging what needs to be checked before those steps are performed.

The connection to the TMS matters especially when the goal is structured output, which will be the subject of the next lesson in this chapter. A system prompt that produces proposals in a defined format (Load ID, Equipment, Driver, HOS, Rate, Deadhead, Flags, Dispatcher action) makes it much easier to extract the individual fields into a TMS record without a dispatcher retyping the entire proposal. When the system prompt's output format matches the TMS's data model, the AI tool becomes a structured data generator rather than a prose generator. That shift is where dispatch AI moves from "interesting to try" to "operationally useful in production."

For the fleet that is tracking its deadhead percentage and revenue per truck, a system prompt that includes the deadhead field in every load proposal produces a consistent, verifiable record of how far the tool's suggestions required the driver to travel empty before the load. That record feeds directly into the deadhead-reduction analytics that are the heart of the empty-mile goldmine this program builds throughout L2 and L3. A tool with no system prompt produces suggestions that look like prose paragraphs; a tool with a well-constructed system prompt produces data that the TMS can ingest, the fleet manager can analyze, and the owner can point to as evidence of the program's margin impact.

The accountability boundary is also a legal record. If a shipper disputes a delivery or a regulator questions a dispatch decision, the carrier's best evidence is a log that shows the AI proposed, the dispatcher reviewed, and the dispatcher committed. A system prompt that makes the commit step explicit (the "Dispatcher action required: YES" line in the worked example) is the standing instruction that creates that record. An AI tool with no system prompt produces suggestions and commitments that blur together: the dispatcher who uses it is not sure which decisions were proposals and which were commits, and neither is the TMS. That ambiguity is a liability in a dispute, a claim, or a CSA review.

Finally: for the owner-operator who runs alone and is tempted to shortcut the verification steps because there is no ops team to catch errors, the system prompt is the ops team you did not hire. It catches the flatbed match, the HOS violation, and the hallucinated rate before you commit to them. One recovered backhaul and one avoided HOS violation covers the 20 minutes it takes to write the system prompt many times over. The solo operator who skips the system prompt because "it's just me, I'll catch it" is the same operator who ends up in the dead lane with a load they can't legally run, calling the broker to apologize. The system prompt does not replace your judgment. It runs before your judgment so your judgment only has to handle the real decisions, not the basic errors a well-written instruction could have caught automatically.

Key Takeaways

• A system prompt is the carrier's standing policy for the AI tool: it shapes every answer the tool produces for every dispatcher on every shift, so its contents are governance, not just configuration.
• The four required elements of a freight system prompt are: fleet identity and equipment constraints; HOS and regulatory rules including 49 CFR Part 395 limits; rate grounding with the cite-or-refuse requirement; and an accountability boundary with a structured output format that separates proposals from commits.
• The HOS constraint must be unconditional: if current ELD data is not provided in the request, the tool must flag the gap rather than estimate hours remaining from the description. A plan that cannot be run legally is a liability, regardless of how it was generated.
• The cite-or-refuse principle prevents hallucinated rates: the tool must either cite any rate figure to a real, current load-board source provided in the conversation, or produce a RATE DATA NEEDED flag. The model's training-data estimates of lane rates are not a substitute for a current market reference.
• Adversarial testing must be completed before any dispatcher uses the system prompt in production: test equipment mismatches, HOS violations, rate hallucinations, commit requests, DVIR defects, and out-of-lane suggestions. Each test should produce a refusal or flag, not a compliant answer to a prohibited request.
• The system prompt's output format should align with the TMS's data model so that proposals produce structured fields (Load ID, HOS feasibility, Rate source, Deadhead, Flags) that can be ingested without retyping, turning the AI tool from a prose generator into a data generator.
• For the owner-operator running without an ops team, the system prompt functions as the standing verification layer that catches equipment mismatches, HOS conflicts, and hallucinated rates before the dispatcher commits, which is exactly the error-catching role an ops team would otherwise provide.
• Accountability stays human: the system prompt's "Dispatcher action required: YES" line is the written instruction that makes the dispatcher's commit step explicit, documentable, and defensible in a rate dispute, a compliance review, or a CSA audit.