Deciding where to put an arriving container looks trivial and is not. The choice determines how many times that box will be touched before it leaves, how much of the yard stays usable and how long the next truck waits. Container yard management software automates that decision using rules and learned patterns. This article explains what it optimises for, where it works, and why the data underneath it matters more than the algorithm on top. The wider yard series covers the neighbouring topics.

Key Takeaways

• Stacking decisions balance four objectives that conflict: retrieval effort, space efficiency, safety and equipment travel. No allocation is optimal on all four at once.
• The strongest predictor of a good slot is expected departure time, which is why booking data and dwell history matter more than any clever optimisation.
• Constraint handling is where products differ most. Reefer power, dangerous goods segregation, weight limits and equipment reach are hard rules, not preferences.
• An allocation engine reasoning about an inaccurate yard picture produces confident bad decisions, so observation quality sets the ceiling on stacking quality.

The Four Objectives a Stacking Decision Balances

The first objective is retrieval effort. A container placed where it will need three lifts to extract has cost the terminal three unbilled moves before it leaves. Minimising expected future lifts is the objective that produces the most direct financial return.

The second is space efficiency. Yard area is finite and expensive, so stacking higher and packing tighter uses the asset better. This objective pulls directly against the first, because every extra tier increases the chance that a box is buried.

The third is safety and compliance. Weight distribution, stack stability, dangerous goods segregation and reefer proximity to power are constraints rather than preferences, and violating any of them is not a trade off the software is allowed to make.

The fourth is equipment travel. A slot that is optimal in every other respect but sits at the far end of the yard from the machine that will handle it costs travel time on every touch, which is invisible in a slot level analysis and material across a shift.

These four cannot be simultaneously maximised, which is why stacking is an optimisation problem rather than a lookup. Every allocation is a weighted compromise, and the weights should reflect what is scarce at your terminal rather than a vendor default.

A terminal short of yard area weights space efficiency heavily and accepts more reshuffles. One with space and equipment constraints does the opposite. Getting those weights wrong is a more common cause of poor results than any deficiency in the underlying algorithm.

Most container yard management software exposes these weights somewhere in configuration, and most terminals have never revisited them since implementation. Reviewing them once a year against what is currently scarce, rather than what was scarce when the system was installed, is one of the cheapest improvements available in the whole yard.

What the Algorithm Actually Uses

Expected departure time is the most valuable input by a wide margin. If the software knows roughly when a box will be called for, it can group boxes leaving together and avoid burying an early departure under a long stay one. Everything else is secondary to this.

That expectation comes from two sources. Booking and vessel data give a planned departure for boxes that have one. Historical dwell patterns by customer, commodity and origin give a statistical expectation for those that do not, which is where learned models earn their place.

Container attributes come next. Size, type, weight, whether it is refrigerated, whether it carries dangerous goods and whether it is empty all constrain which slots are even eligible before any optimisation begins.

Yard state is the third input and the one that has to be current. Which slots are occupied, by what, at what height, and which are reachable given where equipment is now. A stale picture here produces recommendations that cannot be executed.

Equipment context is the fourth. Which machines are working, where they are and what they are already tasked with determines whether a theoretically good slot is practically sensible in the next ten minutes.

Notice that three of those four inputs are about the present state of the world rather than about the algorithm. That proportion is roughly right, and it explains why terminals that improve their data see larger gains than terminals that change their optimiser.

It also suggests a cheap diagnostic. Ask your planners how often the recommended slot is unusable when the machine arrives. A high rate means the yard state feeding the engine is stale, which is an observation problem dressed up as a software complaint, and no amount of retuning will resolve it.

Where Learned Models Help and Where Rules Are Better

Rules should govern anything that must never be violated. Dangerous goods segregation, weight limits, stack height maxima and reefer power availability are hard constraints, and expressing them as learned preferences is both unsafe and unnecessary.

Learned models earn their place in prediction. Estimating how long a container will actually dwell, given its customer, commodity, origin and the time of year, is a statistical question that historical data answers better than a planner intuition does.

They also help with pattern detection. Recognising that a particular customer collects late in the week, or that a commodity spikes seasonally, lets the allocation anticipate rather than react, and those patterns are tedious for a person to maintain by hand.

Where they are oversold is in the allocation decision itself. Given accurate inputs and clear weights, slot selection is a well understood optimisation problem that classical methods solve efficiently and explainably.

Explainability matters more than it sounds. A planner who cannot see why a slot was recommended will override it, and a system that is routinely overridden delivers nothing regardless of its theoretical quality. Recommendations should carry a reason.

The sensible architecture is therefore hybrid. Learned models for prediction, deterministic rules for constraints, transparent optimisation for the decision, and a visible explanation attached to each recommendation so the yard team can trust or challenge it.

Why Input Quality Sets the Ceiling

An allocation engine reasons about the yard it is told about. If a block is recorded as holding thirty containers and physically holds thirty two, every recommendation involving that block is built on a false premise, and the engine has no way to know.

This is why terminals sometimes deploy sophisticated stacking software and see disappointing results. The optimiser is working correctly on data that does not describe reality, and the symptom is planners overriding it, which looks like resistance and is actually good judgement.

The dependency runs back to the gate. A container that entered under a mis keyed number is wrong in the record from its first moment, and every downstream decision about it is wrong too. Identity accuracy at the boundary is the foundation of stacking quality.

It also runs to observation inside the yard. Unreported repositioning creates divergence that no planning system can detect on its own, which is why an independent check on physical position raises the ceiling on what allocation software can achieve.

The practical sequence follows from this. Fix identity, add observation, then tune allocation policy and weights. Terminals that reverse the order spend money on optimisation and then explain to themselves why it did not work.

Docker Vision approaches stacking from that direction deliberately, deriving position observations from cameras already installed for recognition rather than starting with an optimiser. The reasoning is set out in our guide to the yard layer as a whole.

Conclusion

Smart stacking is less about the algorithm than about what the algorithm is told. Expected departure time is the input that matters most, hard constraints belong in rules rather than in learned preferences, and every recommendation should carry a reason a planner can read. Above all, fix identity and observation first, because they set the ceiling on everything above them. Ask Docker Vision what your current yard picture supports.

Frequently Asked Questions

How does software decide where to place a container?

It balances four competing objectives: minimising future retrieval lifts, using yard space efficiently, respecting safety and segregation constraints, and limiting equipment travel. The weighting between them should reflect what is scarce at your particular terminal.

What is the single most useful input to a stacking decision?

Expected departure time. If the software knows roughly when a container will be called for, it can group departures together and avoid burying an early leaver under a long stay box, which is where most reshuffles originate.

Do stacking systems use machine learning?

The good ones use it for prediction, such as estimating dwell time from customer, commodity and season. Hard constraints like dangerous goods segregation stay as explicit rules, because those must never be treated as learned preferences.

Why do planners override the system recommendations?

Usually because they know the yard picture is wrong, or because the recommendation carries no visible reason. Both are fixable. Improve the input data and attach an explanation to each suggestion, and override rates fall quickly.

Can better stacking software fix a yard with inaccurate inventory?

No. The optimiser reasons about the yard it is told about, so inaccurate inventory produces confident bad recommendations. Identity accuracy at the gate and observation inside the yard set the ceiling on what any allocation engine can deliver.

Does stacking higher always save space?

It saves ground area and increases the chance that a container is buried, so it trades space against reshuffles. The right height depends on your dwell distribution and should be modelled rather than set to whatever the equipment can reach.

How are reefers handled in allocation?

Refrigerated containers are constrained to slots that have available power and monitoring access, which is a hard rule rather than a preference. Power availability effectively creates a separate and much smaller allocation problem sitting inside the wider yard.

What is opportunistic repositioning in a stacking context?

It is correcting a poorly placed container while a machine is already working in that row for another reason, so the marginal cost is close to zero. Good systems surface those moments rather than only scheduling dedicated moves.

Where should a terminal start with smart stacking?

Start with gate identity accuracy, then add independent position observation, and only then tune the allocation weights. Reversing that order is the most common reason stacking projects disappoint. Our explainer on container number recognition covers the first step.