A digital twin is a model of how your operation behaves, built well enough that you can ask it a question nobody has asked yet and trust the answer. A 3D render shows shape and motion, and it is good for training, for layout, and for getting a project approved. It cannot tell you what happens to Friday’s trucks if the filler runs ten percent slow on Tuesday night. For a digital twin in manufacturing, that gap decides whether the thing you bought gets used every week or becomes a picture nobody opens. I sat in on a demo a while back where a plant turned slowly on a screen. The geometry was beautiful. Valves opened. A little forklift crossed the aisle on a loop. Two minutes in, the scheduler in the room asked whether they could move sanitation to Thursday and still make the Friday order. The room went quiet. Then somebody at the back opened a laptop and started working it out by hand, the way she does every week. The twin was on the big screen. The answer came from the spreadsheet. What a digital twin has to answer The questions an operation actually argues about almost all start with “what happens if.” If this machine is down six hours on Wednesday, what moves, what slips, and who do we call? If we run this product on Line 2 instead of Line 1, what do we give up in changeover and get back in yield? If this supplier lot goes on hold for a deviation, which orders slip and which customer hears about it first? If we add a second sanitation crew, how many more cases ship and what does it cost per case? None of those are questions about appearance. Every one of them needs the model to know how things connect: which order runs on which line, which lot feeds which batch, which limit you hit first when you push on the schedule. A render answers what the plant looks like. A model answers what the plant does next. Adding detail to the picture will never turn the first into the second. Only writing down the rules will. Why digital twin projects in manufacturing end with a picture and no model Because the 3D picture is the part you can buy. A vendor can hand you a rendered plant in eight weeks. It demos well, everyone in the room can see it, and it looks like progress in a steering committee. The model underneath, the one that knows a changeover from product A to B on that line with the night crew takes fifty minutes and not the thirty-five in the standard, is not something anyone can ship you. It lives in six systems and four people, and half of it has never been written down anywhere. So projects buy what is purchasable and hope the rest arrives later. It rarely does, because nobody scoped it, nobody owns it, and the render already satisfied the people who approved the spend. Simulation studies are the honest alternative here. A good simulation study will answer a real what-if question, and I have seen them pay for themselves. The catch is that they are built once, on a snapshot, for one decision. Six months later the line has changed, the study is a PDF, and asking the same question again means starting over. A twin is that study kept current, connected to the operation, and available on a Tuesday afternoon without starting a project. What data a digital twin needs Every operation runs on a set of real things and real actions. The nouns in a plant: the order, the lot, the machine, the work centre, the crew, the spec, the deviation. The verbs: schedule, change over, run, hold, release, ship. Your operation is those things and those actions meeting each other a few thousand times a day. The systems that hold it store rows in tables that mean nothing without a person to translate them. A row is not “the order that is late because the supplier shorted us.” It is a row. The meaning lives in someone’s head, and a model built on top of rows will reason about rows. Before any what-if question works, the model has to hold the things and how they relate, the constraints, and the history. The things and how they relate, so the model knows that a hold on this lot touches those three orders. The constraints, meaning what actually blocks what, including the ones that are not in any standard: the one operator certified on that machine, the tank that has to be empty before the changeover starts. And the history, the record of how long things really take rather than how long the routing says they take. Feed a model the standard times and it will confidently plan a week that has never once happened. That last point is worth being honest about. A model grounded in your real orders, lots, and constraints is still wrong sometimes. The difference is that it is wrong in ways you can see and check, instead of confidently plausible in ways nobody catches until the truck is late. How to test whether a digital twin is a real model You do not need a vendor, a budget, or a proof of concept to find out where you stand. You need an hour and a whiteboard. Write down the five what-if questions your operation actually argued about in the last month. Pull them from real meetings, not from imagination. Real ones are specific and slightly annoying. For each question, list every input the answer needs and name the system that holds it. Mark the inputs that live only in a person’s head or in a spreadsheet on somebody’s desktop. Time how long it takes a person to answer one of them properly today. Then ask how often that answer arrives after the decision was already made. Look at what you marked. If three of your five questions depend on a number only one planner knows, no amount of rendering fixes that. It is a modelling problem and a capture problem, and it will still be there after the twin is installed. That list is now your specification. When someone demos digital twin software, ask it question one. Not a version of question one. The actual question, with your product codes and your crew. What comes back tells you what you are being sold. Your plant already answers what-if questions. It answers them in the hallway, from memory, from the one person who has been there long enough to know, usually a day after the decision had to be made. A picture of the plant does not change that. A model of it does. The cost of that gap never shows up on an invoice. It shows up as the hours somebody spends every Tuesday working out what your operation could have told you, if anything had been keeping track.