Submitted Sep 8, 2026
Ask most yard software what is happening at a facility right now and it will tell you about tasks. A check-in was completed. A dock door was assigned. A trailer was moved. Each of those is true, each is recorded, and none of them tells you whether anything is actually progressing.
That is the gap between digitising a yard and running one. A task list is a record of activity. It is not a description of what a driver came here to do, and it cannot tell you whether they are closer to leaving than they were an hour ago.
The alternative is to make the unit of work the whole job rather than its pieces. Terminal calls that unit a mission.
What a Yard Mission Actually Is
A yard mission is the end-to-end workflow a driver, load or robot moves through to accomplish a single goal at a facility, expressed as a connected sequence of discrete actions that a system can orchestrate rather than merely record. Arriving, checking in, being staged, being assigned a door, loading and departing is one mission, not six unrelated tasks.
Ryan Arroyo, SVP of Product and Engineering at Terminal Industries, puts the distinction in one line: "A mission is a collection of tasks."
The reason that matters is not vocabulary. It changes what the software is able to do. "A task could be seen as a discrete action," Arroyo says. "A check-in, an assignment to a dock door, an unload or load. Those are tasks. Missions bring them all together into an end-to-end workflow that can then be orchestrated."
A system that holds tasks can tell you a truck checked in. A system that holds missions knows the check-in was step one of seven, knows what step two is, and can initiate it without waiting for a human to notice.
The question every mission answers
There is a useful test for whether something is a mission. Arroyo points to the question every driver is asked on arrival at every facility in the world.
"Why are you here is a classic first thing that every operator gets asked when they arrive at a facility, and effectively the answer to that is the mission, which then loads the series of nodes that then can become orchestrated by a site."
If your software cannot answer "why is this driver here" in a single field, it is holding tasks.
Why Task-Based Yard Software Stalls
It documents the past instead of driving the present
The structural problem with most yard systems is not that they lack features. It is the direction they face.
"The majority of what is available today is documenting what has already happened," Arroyo says. "A truck moves through a gate, something happens, you have to remember to update the software to let the software know that the truck went by. And so it's not helping your operation, you've just added another task for your team to do. Check in the truck, and then go to the software and check in the truck."
His conclusion is blunt: "It's just a digitisation process that adds work versus taking work away."
The tell is whether your team performs an action and then reports it, or whether performing it is the report. If someone is retyping reality into a system after the fact, the system is a ledger. Arroyo's description of what that produces is unflattering and accurate: "Think about that as a really fancy spreadsheet. A really fancy database."
Nobody would accept this anywhere else in logistics
The rear-view model looks normal in the yard only because it is universal there. Move it to any other high-throughput environment and it becomes absurd immediately.
"Can you imagine running a high-speed rail system rear-view mirror?" asks Josh Kivenko, Terminal's Chief Marketing Officer. "Oh, train A31 came in from Osaka, right, okay, write it down." His point is not that it would be inefficient. "There's no way to do it. It just doesn't work efficiently, it just doesn't function."
The yard tolerates a standard that no comparably complex operation would accept, and the reason is historical rather than technical.
There is nobody left to do the data entry
The rear-view model has a dependency most operators have not thought through: it requires a human to be standing there to record what happened.
"You move to the future where we need to be able to orchestrate movement autonomously, because we're taking humans out of the yard or interacting with autonomous vehicles and robots," Arroyo says. "Then you can't be in the past. There's no one to enter the data for that truck that entered the yard, because there's no one there."
This is why the mission model is a prerequisite for automation rather than a nicer way to view it. Remove the gate guard from a task-based system and the system goes blind. Remove them from a mission-based one and the workflow continues, because the sequence was already defined and the sensors already feed it.
How Missions Are Built
Missions are assembled from nodes: discrete actions that map to things that really happen in a yard. The architecture matters because it determines who can change it.
Signals come in. Computer vision at the gate, integrations with the WMS or TMS, driver input, telematics, and whatever sensing the site has. The system learns a truck has arrived without anyone telling it.
The mission is identified. The arrival is matched to a purpose: which shipment, which carrier, on time or late, live load or drop. This is the "why are you here" answer, resolved automatically.
Nodes are sequenced into a workflow. The mission loads the actions required for this specific purpose at this specific site.
Decisions are made on the operator's behalf. "AI is used to make decisions on behalf of humans," Arroyo says, "qualified, accurate decisions, so that they can leverage their time more effectively, manage more of the operation, manage more of a network, by only focusing on the things that AI can't figure out." Humans handle exceptions, not the routine path.
The configuration belongs to the operator. "It's configurable in a no-code way by the industry," Arroyo says. "When you think about how every yard works different, we have that covered, and the greatest thing about that is you can over time configure these yourself."
That last point is where the model earns its keep. No two yards run identically, so a fixed set of workflows would fail everywhere except the site it was designed for. Arroyo is explicit that the interesting outcome is customers building sequences Terminal did not anticipate: "We're excited for our future when we see our customers creating missions which are unique combinations of nodes that we've never seen before."
Determinism, and the Part Nobody Can Program in Advance
There is an obvious objection. If a mission is a defined sequence, what happens when the yard does something nobody defined?
This is where the mission model separates from simple workflow automation. A rail network is largely deterministic: a train leaves A and arrives at B, and the states in between are documented. A yard is not. Kivenko raises the Rumsfeld problem directly, the things you do not know that you do not know, and asks how a system accommodates them.
Arroyo's answer is architectural rather than predictive. Because missions are built from a growing library of composable nodes rather than hard-coded end-to-end paths, the system does not have to anticipate every scenario. It has to be able to assemble a response from parts it already has.
"You're not building for every scenario," Kivenko summarises. "You're able to have a platform that's flexible enough to accommodate an unforeseen scenario."
Arroyo adds the qualifier that matters: "That's fundamentally the AI revolution that we're seeing." With guardrails. A yard is a physical environment with safety consequences, which rules out purely probabilistic decision-making. The system has to be flexible in what it can assemble and rigid about what it will permit.
A Diagnostic: Are You Running Tasks or Missions?
Can your system answer "why is this driver here" as a single value, or does someone have to infer it from a sequence of records?
When a truck completes check-in, does the next step begin automatically, or does someone have to notice and start it?
If you removed the person who updates the system, how long before the system's picture of the yard is wrong?
Can a site manager change the order of steps for a workflow without raising a ticket with a vendor?
Does your software know that these six records are one job, or does it hold six unrelated rows?
When something unexpected happens, does the system have a path for it, or does it simply stop and wait for a human?
If the no answers cluster around the first three, you have a rear-view system. If they cluster around the last three, you have a workflow tool that is not configurable enough to survive contact with a real yard.
Where This Sits in the Platform
Missions are the execution layer of a Yard Operating System, which is the distinction Terminal draws between a YOS and a traditional yard management system. A YMS records yard state. A YOS orchestrates yard movement, and missions are the mechanism by which it does.
In practice that runs across gate automation at arrival, dispatch and spotter orchestration for the moves in between, and yard visibility as the layer that makes the whole thing legible to a network operator rather than a single site. The agentic AI layer sits on top of the mission backbone rather than beside it, which is why Arroyo describes the AI as infrastructure rather than a feature.
Frequently Asked Questions
What is a yard mission? A yard mission is the end-to-end workflow a driver, load or robot moves through to accomplish a single goal at a facility, expressed as a connected sequence of discrete actions that a system can orchestrate. Arriving, checking in, being staged, being assigned a door, loading and departing is one mission rather than six separate tasks.
What is the difference between a yard mission and a yard task? A task is a single discrete action such as a check-in or a dock assignment. A mission is the collection of tasks that together accomplish the driver's actual purpose, held as one connected workflow so that completing one step can trigger the next automatically.
Why does the distinction matter operationally? Because a system that holds tasks can only record that something happened, while a system that holds missions knows what should happen next and can initiate it. It is also the precondition for removing labour from the yard, since a task-based system depends on a human being present to enter what occurred.
Can yard missions be configured without a developer? Yes. Missions are assembled from a library of nodes and are configurable without code, so an operator can reorder or customise a workflow for a specific site rather than requesting a change from the vendor.
How does a mission handle a situation nobody planned for? By being composed of reusable nodes rather than hard-coded end-to-end paths. The system assembles a response from components it already holds instead of requiring that every scenario be anticipated in advance, with guardrails constraining what it is permitted to do in a physical environment.
Where to Start
If your yard is digitised and your team is still doing data entry, the problem is the unit of work, not the software's feature list.
Terminal's Yard Operating System is built on the mission model described here. See how a YOS differs from a YMS, or explore the platform and walk through gate automation yourself with no sales call.
This article draws on Lights-Out Yard Episode 2 with Ryan Arroyo, SVP Product and Engineering at Terminal Industries.
