A simulation replays your operation, truck by truck, order by order and hour by hour, under conditions you choose. That lets you ask questions that are hard to answer any other way:
- Where is the real bottleneck? Not where people think it is, but where trucks, crews and orders actually wait, and why.
- Will my warehouse handle the peak? What happens to dock queues, yard space and pick rates when volume jumps for a season or a promotion.
- What will a new product introduction do to the flow? New pack sizes, new handling, new demand patterns on the same docks and the same people.
- What happens when something goes wrong? A late carrier, a closed dock, a short shift. How far the disruption travels and how long recovery takes.
- Is the process change worth it? A planned dock schedule versus ad-hoc docking, call-forward versus first-come-first-served, tested before anyone changes how the site runs.
Too often, these questions get argued with opinions rather than numbers. Dock queues, full yards and late carriers become visible only after the day has already gone wrong. Spreadsheets help, but they miss the knock-on effects: one late truck that blocks a dock, which delays the next three, which fills the yard.
I built FlowTwin, a demo suite of logistics simulators, working with an AI coding agent. It took about a week and 50+ prompts, including fine-tuning it to real-world models and parameters.
FlowTwin is five models on one simulation engine. They cover a warehouse and yard, a plant’s inbound docks, the same inbound twin as a 2D map, a parking yard with only 20 positions, and finished-vehicle outbound from end of line to carrier. It runs in a browser, sits behind a simple sign-in, and can be shared as a link.
FlowTwin’s sign-in page.
The warehouse and yard twin mid-run, with a door closure injected and bottlenecks tracked over time
Here is how it answers each of the old barriers.
The learning curve. I didn’t start by learning a simulation tool. I started by writing down how the operation works: the processes, the resources, the KPIs and the disruptions. That brief, plus an instruction to plan, build and test each phase, produced the first working version. After that, most of my prompts were driven as a product manager, refining an individual component, adding a feature or a question to understand something before changing it.
The look and feel. The twin runs as a live 3D view, and when the 3D view felt cluttered, the same simulation was given a 2D map, with an operations style and a satellite style. The view changed; not a single calculation did. A map is something people already know how to read.
The inbound twin, shown as a 2D operations map
Customisation. Each model replicates a specific site and a specific concern. At a plant’s inbound docks, the question is ad-hoc docking versus a planned schedule. In a parking yard with 20 positions, it is manual call-forward versus SMS alerts and display boards. Nothing is generic, because nothing needs to be.
Cost. About a week, rather than a project.
What makes it useful for decisions, not just impressive to watch, is how it compares options. Every simulated day is drawn once, from one seed, so the current process (“As-Is”) and the alternative (“Controlled”) face exactly the same trucks, the same delays and the same defects. Any difference in the result comes from the process, not from a lucky day. An Experiment Lab runs many seeds and reports averages with confidence intervals.
As-Is and Controlled, compared on the same simulated demand
In one demo comparison in the parking-yard model, on illustrative settings and a single replication, call-forward with SMS and display boards cut average total truck time from 128 to 104 minutes and parking wait from 61.6 to 36.4 minutes. The same Lab also answers the peak question. In a high-volume season, total truck time rose to 231 minutes As-Is, against 143 minutes with call-forward. These are illustrative demo numbers, not a client result. The point is that a leadership team can see the difference, and the reason for it, before changing anything on site.
The reason matters as much as the number. In FlowTwin, every wait has a reason attached: waiting for a yard slot, waiting for a dock call. Those reasons are grouped and ranked, so the bottleneck shows itself. Disruptions can also be injected into a live run, 17 types in the warehouse and yard model alone, to see how far they travel.
Disruptions logged as they happen in the inbound twin: a gate outage, paperwork mismatches, line-side shortages
WHAT I LEARNED ABOUT BUILDING FAST, AND BUILDING RIGHT
Speed comes with a responsibility: simulation bugs are quiet. The model keeps running and the numbers are simply wrong.
In the finished-vehicle model, the better process first scored worse than the current one. I treated that surprise as a hypothesis to test, not a finding. The cause was a queue that blocked behind its first carrier. Fixing the model, not the numbers, gave the result: in a demo run on default settings, turnaround of 73 minutes with controlled dispatch against 188 minutes As-Is.
Three habits kept FlowTwin honest:
- Test the rules, not just the code. 151 automated tests check things like the same seed always giving the same answer, and no truck ever being in two places or a dock being double-booked.
- Look at it, every time. Some problems, like parked vehicles overlapping, were found by eye, not by tests.
- Ground it in real data. The inbound twin was calibrated against real operating data by tuning behaviour, never by copying reported figures into the model.
A fair challenge is that a quickly built simulator can be wrong in ways an established platform has already been validated against. That’s true, which is why these habits are not optional. FlowTwin is purpose built for a particular problem statement. And very large, highly integrated network questions may still justify a full platform. But for a specific question about your own operation, a purpose-built simulator is now within reach.
AND SIMULATION IS ABOUT TO GET FAR MORE REALISTIC
The technology underneath is moving fast. On 27 October 2026, Google DeepMind announced Genie 4, a world model for real-time interactive simulation with more realistic physics and natural human motion. Users can change a running simulation with plain language, for example changing the weather or introducing a new object, and DeepMind says enterprise partners are evaluating it for rapid scenario generation. It is still a research preview, and DeepMind is open that details can drift over longer simulations and that spatial accuracy is still being worked on. DeepMind also points to hybrid world models that combine structured reasoning with visual simulation as a promising path.
My read is that, for operations, the numbers will still come from logic-based simulators like FlowTwin. World models like Genie 4 show what those simulators may soon look and feel like: a realistic, steerable view of your own site.
SO, HOW SURE ARE YOU?
The computer game I saw in my industrial engineering days is finally practical for the people who make supply chain decisions.
How do you currently understand whether your supply chain is built to handle rough weather: a peak season, a new product launch, a disrupted day? Are you confident of that? Let us know.
At Smartlinks, our only focus is helping customers make better decisions and build better supply chains with AI, through a consultative, customer-first approach you’ll enjoy working with. Interested in building a custom simulator for your own question? Reach out to us.
