Digital Twins on Azure: What Should You Actually Model?

0:00 Here's the problem most vendor skip. Everyone wants a digital twin, but almost nobody starts with the problem their plant actually needs to solve. You've already got ERP, MES, a historian, and an IoT layer running in Azure. Data lives in all of them, but an operator still has to call planning, planning still checks a spreadsheet, and maintenance hunts through alarms, trying to figure out what a fault will actually affect. The systems hold facts, but they don't share enough meaning between them. Let's cut through the hype. A twin isn't a polished copy of a machine with sensor values pasted on it. It's a way to represent the operating facts around that machine. Its identity, its current state, the work tied to it, the events changing it, and the relationships that explain why anyone should care.

0:40 We'll work through what deserves a twin and what doesn't, and one relationship type can change the whole design, not location, but impact on production. Start with the question most projects skip. Start with the decision, not the asset. Before you build a model, ask a plane question, who needs to make a different decision, and what do they need to know at that exact moment? That question sounds basic, but it cuts through weeks of architecture diagrams. If nobody can name the person, the decision, the timing and the action, then you don't have a twin use case yet, and you've got a data collection idea. Picture a line supervisor at 1015 on a busy shift. A machine in the middle of the line stops and throws a fault code. That tells the supervisor something but not enough. They need to know whether the fault blocks the order you later that day, whether the next operation has enough material to keep running, and whether another resource can take the work.

1:25 That's the decision loop. The supervisor calls maintenance, the planner, resequences work, and the material team stops issuing stock to an order that can't move. Each person needs a different view, but all of those views depend on the same connected operating context. An asset register can't provide that context on its own. It tells you machine 47 exists, where it is, who owns it, maybe it's serial number and service date. Useful stuff, but it doesn't tell you what machine 47 is doing to production right now. Think of an asset register as the plants address book. A digital twin model is more like an operating map. It connects the machine to the current job, the job to its order, the order to a due date, and the machine to the material or downstream process that turns a local fault into a wider problem. Here's what usually happens. A team says let's model the factory.

2:07 It sounds ambitious, but it has no boundary, which factory, every asset, every tag, every pallet, every work instruction, you can spend a year building a large graph that still can't answer the question someone asks at 10.15. Start smaller, but don't start shallow. Choose a repeat decision that already causes delay, confusion or handoffs between teams. For example, when a bottleneck resource enters a fault state which released orders face a risk or when an upstream material shortage appears which planned operations needed decision before the next shift starts, those are good twin questions because they cross systems in time. The fault comes from the shop floor, the order and due date come from ERP, the operation status comes from MES, and a plan sits in APS. No single screen shows all of that without someone stitching it together by hand.

2:49 You don't need to model every part of the plan to answer one of these questions, only the entities that change the answer. For a bottleneck response, that means the resource, the active operation, the production order, the root step and the material constraint that prevents an alternate path. Anything outside that decision stays in its source system until a real question pulls it into scope. That gives you a hard test for every proposed twin. If it's current condition changes, does it drive a different action? If the answer is no, it belongs in a historian an asset system or a report. Not yet in the twin graph. Here's something that feels backward at first, a detailed machine twin can be less useful than an order twin. The machine reports that it stopped fine, but an order connects that stop to customer demand, a root, a due date, material, and a set of resources that may substitute for each other or not.

3:33 The order carries the operational stakes. Without it, you can see the red machine, but you still can't tell what to do, so don't begin with the most visible physical asset. Begin with the repeating decision, then work backward into the facts and relationships that support it, which leads to the next question. When we say twin, what are we actually creating? A twin is an instance with context. Let's start with what a digital twin actually is, because most people get this wrong. A digital twin in Azure isn't a CAD file sitting in the cloud, and it isn't a dashboard tile that turns red when a tag value changes. Those things can connect to a twin, but neither one defines it. A twin is an instance of a model. The model describes a type of thing your business recognizes, machine tool, production order, storage location, and the twin represents one specific thing within that type.

4:16 It carries its own identity, current facts, and links to other things that matter during day to day work. Take a machining center, you might define a model called machine tool with fields like mode, fault state, planned capacity, and maintenance status. Then you create a twin for one actual machine, probably with an ID that sticks with that machine through its working life, even when someone changes the display name or moves it between cells, that instance matters because it carries context. The identity answers, which exact thing are we talking about? The model type answers, what kind of facts and links can this thing carry? The properties answer, what do we currently believe about it? And the relationships answer questions a flat record can't answer cleanly. What worked as it perform, which area contains it or which other entity depends on it?

4:58 Then there's change history. A twin holds the current operating picture, but if you expect people to trust that picture, changes need a time and a source attached to them. When a machine shows a fault state, you need to know when that state entered the graph where the update came from, and whether it still describes the floor rather than a connection that went silent an hour ago. That sounds like a small detail. It isn't. A property without a source and timestamp can look precise while telling you almost nothing. In a real plant, that creates the worst kind of argument. Two people look at the same screen, each trusts a different system and both think the other person has bad data. Now, a model doesn't have to describe only physical equipment. This is where people often narrow the idea too soon. You can create twins for a production order, a batch, a root operation, a storage location, a tool or a quality hold.

5:41 You can model a person where the work calls for it, though you should be careful about what data belongs there and why. Maybe you represent an operator's current assignment or a qualification for a process without turning the twin graph into an HR system by accident. The point is simple, a twin represents something with identity and operating context, whether it's physical or logical doesn't change that. Picture a production order moving through a line. The order isn't something you can walk up to and touch, but it has a clear ID, a current status, planned and actual dates, material needs, and a link to the operation running right now. If the order changes, planning may need to act. If the order links to a faulted resource, the fault stops being an alarm on one screen and becomes a production issue, someone can assess, that logical twin may actually carry more useful context than the machine twin sitting beside it.

6:25 The same physical asset can also need more than one representation, depending on the question. Maintenance might view a machine through condition, service plans, replaceable parts, fault classes, and maintenance work. Production might view that exact machine through its capability, current job, cycle condition, available capacity, and position in the root. You don't solve that by creating two unrelated copies of the same machine and hoping they stay in sync. You keep a stable identity, then give the model enough structure to connect the machine to different kinds of work. One view asks, can we keep this machine healthy? The other asks, can this machine complete the operation we need? Same asset, different context. This is why the graph matters more than the icon on a screen.

7:05 In Azure Digital Twins, each twin becomes a node and the links between twins form the graph. The graph isn't there to look clever in an architecture slide. It gives your systems a connected operating map, where you can start from one known fact and move to the work, place material or resource tied to it. A flat table can tell you a machine is in cell four. The graph can also express that the machine performs a certain operation, supports active work, and connects to the surrounding process. That's a different kind of model. It captures how the plant operates, not just what the plant owns. Once you see a twin this way, a few nearby terms start to look less interchangeable. Device twin, 3D model simulation, each has its own job, and mixing them together creates bad designs very quickly. Digital twin, device twin, 3D model and simulation.

7:48 People use these terms as if they mean the same thing. They don't, and that confusion causes bad scope decisions before the first model even exists. Start with the IoT Hub Device Twin, a device twin belongs to a managed device, an edge gateway, a PLC connected device or a sensor package. It holds desired properties that cloud side systems want the device to use, plus reported properties that the device sends back about its own state and configuration. Say an edge device reports its software version, connection state and the sampling rate it currently uses for a vibration signal. Operations can change the desired sampling rate and the device reports whether it applied that change. That's a useful device management pattern, but it doesn't tell you which order the machine is running. It also doesn't know whether a stopped asset blocks a downstream pack line, whether it's tool fits an alternate resource or whether material for the next operation is sitting on quality hold.

8:32 You can connect an IoT Hub Device Twin to a wider model, but the device twin stays focused on the device and its cloud connection. Azure Digital Twin's handles a different layer of the problem. It gives you a graph where equipment, orders, batches, locations, operations and other business entities can exist together and carry links between them. The device can sit inside that graph, but it isn't the center of every question. Think of a device twin as the field service record for a connected endpoint. It tracks how that endpoint receives settings and reports its condition. Azure Digital Twin's becomes the operating context around it where the endpoint data can contribute to a much larger question. That distinction keeps your architecture clean. A PLC tag may show a machine is stopped and Edge Device may report that it still has a healthy connection.

9:13 Azure Digital Twin's can represent the machine's current operating condition and connected to the active work and process context. Each layer tells the part of the story it actually owns. Now consider the 3D factory scene because this is where a lot of teams get pulled off course. A 3D view can help people orient themselves, a maintenance lead might use it to locate an asset in a large area. A safety team may need spatial context around a fault. Someone walking aside remotely may find a scene easier to use than a list of asset IDs and coordinates. That's a good use of a 3D view, but the scene consumes the model. It maps visual objects to twin IDs and reads state from the graph. A machine turns amber because the underlying twin reports a condition. The scene doesn't create the operating relationships.

9:54 It displays them or at least the small part that fits on the screen. If your graph can't answer a useful question without the 3D scene, you don't have a model problem solved by more polygons. You have a missing context problem. You can prove this very quickly. Hide the 3D view and ask a planner which released work faces a delay from a resource fault. If the data model can't support that question through an API, a query or a plain table, the animated plant won't save it. It may look good in a steering meeting. The shift still has to run, simulation sits nearby, but it has its own job as well. A simulation takes a representation of the current or planned operating situation and asks what may happen if conditions change? What if a resource stays down for two hours? What if demand rises? What if a root moves work to a different resource?

10:35 It applies rules, constraints and assumptions to test possible outcomes. The twin supplies context for that work. It can give the simulation a current resource state, active work, relevant material status and known relationships. But the simulation isn't the twin because a simulation produces a scenario based on inputs and assumptions. The twin keeps the current operating representation current. You need both when the decision calls for both. A current graph might show that a machine fault affects two active orders. A simulation may then compare different recovery parts, maybe waiting for repair versus moving eligible operations elsewhere. The first answer describes the plant now. The second explores a future that hasn't happened. Don't let the second override the first. APS works in a similar way, although it focuses on plans and constraints rather than every live fact on the floor.

11:17 APS can calculate a feasible future schedule based on capacity, calendars, material, rules and priorities. It helps planning ask, if we schedule this work here, what follows? ERP records the business transaction and the formal order record. It holds demand, order dates, inventory positions and the facts the business needs to transact an account for. Neither system becomes less useful because you introduce a twin model. They each answer different questions. A twin graph can connect what APS intends, what ERP records and what the physical process appears to be doing without forcing them into one false version of the world. Plants change, execution drifts, devices report incomplete evidence. That tension needs a model that can hold context rather than a diagram that pretends every system always agrees.

11:58 With those labels separated, we can move to the first modeling rule. Establish identity before you start pumping telemetry into anything. Model identity before you model telemetry. Before you wire up a single PLC tag to a twin property, there's a boring problem you actually have to solve first. How do you know which machine that tag belongs to? Most plants have multiple answers and they almost never agree. The PLC program might call it MC04, MES knows it as filler 2 and the ERP system calls it WC220. Meanwhile, the maintenance system uses an asset number from a register created years before the current line existed. None of those ideas are wrong. They just describe the same equipment from different system angles. If you push every source into Azure Digital Twins without a clear identity rule, you can end up with four twins for one machine, one shows a fault, another shows the active job, a third holds maintenance status, and the fourth just sits in a hierarchy because someone imported the asset list.

12:53 Then people ask why the graph disagrees with itself and honestly that's a fair question. Pick one canonical twin ID for the thing you're modeling and make sure it stays stable through normal changes in names, locations, system integrations, and user preferences. It doesn't need to replace the IDs in ERP, MES, or maintenance. It just gives them a common reference point they can all agree on. For example, a machine twin might use an internal asset identity like asset plant A, machine 0, 0, 0, 4, 7, 2. Then the MES equipment ID, ERP, WorkCenter code, PLC equipment name, and maintenance asset number sit beside it as source references. Those source IDs still matter because connectors need them, but they don't each become a separate identity. Keep the mapping visible and owned. Across reference table, master data service, or controlled mapping process can hold the relationship between the canonical ID and each source system ID.

13:40 The point is that a team can answer without guesswork which source record points to which twin. This gets harder when names seem stable but aren't. A display name can change because the line layout changes, an engineering team adopts a new naming rule. Or someone decides that press three should become forming station three. A location can change too. A machine may move from one cell to another, or a temporary setup puts it in a different area for a month. Neither change should create a new machine identity. Serial numbers help, but they don't cover every case. A machine keeps its operational identity through upgrades, but some major rebuilds may justify a new asset record. A replaced controller doesn't create a new machine, but a full replacement of the frame, drive train, and control system might.

14:21 You need life cycle rules that people can apply before a project team starts inventing IDs under pressure. Think about awkward cases early. If a machine moves, does its twin stay and its location link change? Usually yes. If a motor fails and maintenance swaps it, does the motor need its own identity? That depends on whether you track that motor through service history, condition data, and replacement cycles. The answer isn't technical first. It's what your plant actually needs to trace. The same discipline applies beyond equipment. A production order needs an ID that stays tied to the business order even as it moves between planned, released, active, and complete states. A batch needs an identity that survives storage moves and quality checks while a material lot needs a source reference from the system that manages traceability.

15:01 Tools, fixtures, gauges, and molds need identities if you plan to connect their availability or history to work. People need special care. You may need an operator ID to connect an assignment or qualification to an operation, but you don't need to copy every HR field into an operational graph. Use the smallest identity and context that supports the work and let the source system retain the rest. Now, this work can feel slow when everyone wants live data on a screen, but identity errors spread quietly. A bad sensor mapping affects one reading, while a duplicate identity splits the story of an asset across systems. Every query, alert, and report then has to guess which copy to trust. I usually ask teams to test identity with a plane scenario. A planner sees a resource name in MS, maintenance sees an asset ID in their system, and an automation engineer sees a PLC tag group.

15:46 Can all three trace those references to one shared twin ID with no manual detective work? If they can't, telemetry will only make the confusion arrive faster. Once identity holds, you can decide which current operating facts belong on that twin. State means the current operating fact. Once an entity has a stable identity, the next question is simpler. What do you need to know about it right now to make a decision? That's state. And state isn't every fact you could collect about a machine and order or a batch. It's the latest trusted condition that changes what someone should do next. It also needs enough context, so a person can judge whether it still describes the shop floor. Take a machine on an active line. It state might include its operating mode, whether it's running idle blocked, starved, in setup or faulted. It may also include the active job, the last completed cycle, a fault category, or the material condition that prevents the next operation from starting.

16:33 Those aren't just fields for a screen. They're current operating facts. A planner sees a late order differently if its active operation is running on a resource with available material. But the same order needs attention if that resource sits faulted and the next batch is on hold. Order status alone won't answer that and machine status alone won't either. Current state connects those facts at the time of the decision. But be careful with the word current. It doesn't mean last value we happen to receive. A value becomes useful state only when you know what it means who supplied it and how old it is. Imagine a property called machine mode with the value running. That looks clear until you ask a few basic questions. Did the PLC report it directly or did an integration rule infer it from several tags? When did the source observe it? Did the message arrive late?

17:14 Did the edge gateway report bad data quality? Has the connection been silent long enough that the value should no longer guide a production decision? Without those answers running is just a confident looking word. Put the source, source time, quality, and where useful, confidence next to any state that drives action. A state update from an MES transaction may carry a different level of trust than an inferred state from a machine signal. A calculated material risk may carry a confidence level based on incomplete inventory data. You don't need to bury users in metadata but the model needs to preserve it. In practical terms, you might hold a current property such as operating mode, then record metadata that tells you the update came from a defined source was observed at a known time and passed or failed a quality check.

17:56 Your app can then treat a fresh, good quality state differently from one that has aged beyond its agreed limit. That gives you a better answer than forcing every field into a clean yes or no. A plant runs through imperfect data all the time. A gateway loses connection, a PLC tag freezes, or an MES confirmation comes late because an operator finishes the transaction after the operation ended. If your model keeps showing a green, clean value through those conditions, it isn't helping anyone. It's hiding uncertainty behind a dashboard color. Use an explicit unknown state when the evidence no longer supports a confident answer. Use stale when you still know the last state, but you no longer know whether it remains true. Those are different conditions. For example, a machine may last report running at 0942 and at 0947 the data path breaks.

18:38 The system shouldn't quietly carry running forward as if nothing happened. Instead, it can state that the last observed mode was running. The observation came at 0942 and the present condition is stale. An operator then knows what they know and what they don't. That may feel less tidy. It is more honest. The same applies to material availability. Available can mean physical stock exists. Stock is reserved for the order, stock past quality checks or someone expects a delivery later in the shift. Those are different facts with different sources. If the decision concerns whether an operation can start, model the version of availability that answers that question and retain the source detail needed to challenge it, don't turn the twin into a bucket for every incoming value. Raw signal streams have their own job and treating each new reading as current operating state fills the graph with noise before anyone has defined what the readings mean.

19:24 And telemetry is evidence, not the model. Here's the problem most people don't think about when they start building a twin graph. It fills up fast if you treat every sensor reading like a property. Temperature, vibration, motor current, power draw, part counts, pressure, and cycle signals can arrive every second or more often. Those readings matter, but they don't all belong as the current state of a business entity. They belong in time series storage where you can keep the sequence, inspect patterns, and look back at the signal without turning your operating model into a stream archive. Take a machine that sends a spindle temperature every two seconds during a shift. The current reading helps with a live condition check but the last six hours tell a different story. Warm up behavior, load changes, drift, maybe a temperature rise that only happened during a certain product run.

20:07 You need the full series for that work. Now here's how I think about splitting the responsibilities. Azure Digital Twins holds the fact that someone needs to act right now while Azure Data Explorer, Microsoft Fabric, or another time series store holds the evidence that led to that fact. They answer different questions and mixing them together makes both harder. A raw signal doesn't carry its own business meaning. A vibration value of 8.2 might be normal on one machine concerning on another and meaningless if the sensor came loose. That number needs context. What component does it describe? What operating mode was the machine in? What baseline applies? And what rule turns that reading into a condition worth showing to maintenance? This is where you need to write the rule down. Don't model a twin property that simply says vibration echoes 8.2 and expect users to decide what that means every time they see it.

20:54 Keep the raw vibration series in the history store then use a processing rule that evaluates the data against the correct operating context. The rule might determine that vibration stays within normal range while the machine runs at low speed or it could detect repeated elevated readings during a loaded cycle, compare them with a baseline for that component and set a current condition such as condition status equals needs review. That status has meaning. It tells someone why the machine appears in their work queue. See the difference? A threshold on its own only says that a number crossed a line. A maintenance relevant condition can say that the reading crossed the line during the right operating state persisted long enough to rule out a short spike, came from a sensor with acceptable data quality and relates to a component that maintenance actually tracks.

21:37 The first version creates alerts. The second version supports a decision. You don't need to hide the raw value. A maintenance engineer may want to open the time series trend and see the evidence behind the condition, but the twin should carry the current result that connects to operational work, not a copy of every sample that led to it. Cycle signals work the same way. A PLC may expose individual tags for cycle start, cycle complete, machine ready, safety state and part counter changes. Those signals help you derive a cycle condition, but none of them automatically explain whether the operation is healthy, delayed or waiting for material. You need a defined rule tied to the process that turns device evidence into a fact people can use. That rule should come from automation engineers, process engineers, production leads and maintenance, not from a dashboard developer guessing what a tag name means.

22:24 The storage split also protects you from a common failure mode. If someone asks why a twin changed from normal to needs review, you can trace the current state back to source readings and the rule that assessed them. If the rule changes later, you can test it against historical data without rewriting the history to match a new opinion. Keep the signal history as observed evidence and the twin state as the latest operating meaning derived from that evidence. There will be cases where a raw reading belongs on a twin for a short period. Maybe where an operator needs a current live value. But even then, treat it carefully. Ask whether the value itself drives the decision, whether it needs a source time and quality status and whether the update rate fits the graph rather than overwhelming it. The graph should stay readable because it represents the plant as people need to reason about it.

23:06 A high frequency stream does not become more useful just because it has a twin ID attached. And a current condition still leaves out part of the story. It can tell you that a machine needs review but it can't fully capture when the condition began, what caused the response, or which operating change turned a normal shift into an exception. That's the shift we need to make from raw values to meaningful changes. Events explain what changed and why. A current condition tells you where things sit now. An event tells you that something changed when it changed, where the message came from, and what else was involved when it happened. That different sound small until a shift goes wrong. A machine twin may currently show faulted, but the event record can tell you that the fault began at 101432 came from a name PLC source, followed a product change over, and occurred while a specific operation ran against a specific order.

23:54 The state tells you where to look and the event gives you a trail. Use business language for events wherever you can. Work order released, machine fault raised, batch moved and quality hold applied, are events that people across production, maintenance and planning understand, even though each may come from a different system or trigger a different response. A raw message such as Alambit 128 EG1 might start the chain, but that's not the event your plant needs to manage. An integration rule can interpret that signal in context and publish an event like machine fault raised with the fault class, source time, affected resource, and any available job context attached. That event can travel, but the raw alarm tag usually can't.

24:34 Take a work order release, ERP may change the order from planned to released, and that change needs to reach MES, the material process, and perhaps the twin graph. The event should record the order ID, release time, source transaction, root version were relevant, and the state that changed. Later, if someone asks why a material reservation appeared, or why a resource entered the candidate list for a job, you have more than a current status field with no story behind it. The same idea applies to batch movement. A batch may move from a mixer to a hold area, and the current batch state shows its present location. But a batch-moved event carries the departure point, arrival point, time, actor or system source, and perhaps the reason code. Those details matter when quality asks where the batch sat before a hold, or when production tries to explain why a later operation waited.

25:19 Not every state update deserves its own business event. A temperature reading changes constantly, but it doesn't need an event each time it moves by a fraction. Even a machine mode can update more often than anyone needs to know. An event should represent a meaningful occurrence that changes workflow, traceability, or the way someone interprets the operating situation. For example, machine mode, Eplol's running is state. While machine entered running mode after plan change over completed, maybe an event. If that transition starts a production record, clears a delay or begins a timing rule. The exact boundary depends on the process. Write it down with the people who run that process. This also gives you a cleaner route for downstream action. A fault event may create a maintenance notification, add a review item for the planner, and enter an audit trail for later root cause work.

26:03 A quality hold event may notify the warehouse process and prevent a batch from moving into the next stage until someone releases it. The twin graph updates its current facts, while event routing sends the named occurrence to the services that need to respond or retain history. Those are separate jobs. Don't force one mechanism to do both. You might route events through event grid when systems need notification through event hubs when you need a stream for processing or analytics, or through service bus where a workflow needs reliable message handling and controlled delivery. The Azure service choice follows the delivery need, not whichever icon appears first in a reference diagram. A production or safety related action also needs boundaries. A fault event can open a work request or raise a planning review. It should not automatically command a machine to stop or re-root production just because a cloud rule notice the data change.

26:49 The control path belongs under the controls, safety rules and approval process your plant already uses. Now, shop floor messages don't always arrive in the need order people imagine during a demo. A gateway can reconnect and send buffered messages. MES may confirm an operation after the PLC signal that suggested completed. A network delay may deliver a fault clear message before the original fault event reaches your processing service. If your model accepts every message blindly, a late update can override a newer condition and leave the graph telling a false story. Give each event a stable event ID where the source can provide one and process it in a way that tolerates duplicates. That's idempotency. If the same fault message arrives twice, you record and act on it once, rather than creating two work requests and a very annoyed maintenance planner.

27:33 Time also needs rules. Keep the source time, not only the time your cloud service received the message. Compare incoming updates against the last accepted state and decide what happens when messages arrive late. Sometimes the right answer is to record the event for history, but not let it replace the newer current state. Sometimes a late message corrects an earlier gap and should trigger reconciliation. There isn't one universal rule, but there should be a clear rule for each event type. Once you can tell what changed and why, the next problem becomes more interesting. How do you show what that change affects? State and events only become operationally useful when they connect to the other things around them. Relationships carry the operational meaning. Here's the problem most factory models don't talk about.

28:13 They start with a containment tree, plant, area line, cell, machine. And sure, that structure works when you need to know where equipment sits or who owns the floor, but containment only tells you where something is, not how it connects to everything else. A machine might sit and sell through, but still affect work way beyond that cell. It feeds a pack line, consumes a material lot, performs an operation for several product routes, requires a shared fixture, blocks a downstream process, or sits under condition monitoring from a separate device. Those are operating relationships. They describe how workflows and where a local problem can ripple into a full production stop. Take two machines that fault at the same time. The first runs a non-constrained operation with spare capacity elsewhere.

28:54 The second feeds a pack line already running at its limit, supporting orders with no approved alternate route. On a flat alert list, both look identical, faulted, red, unavailable. They aren't identical because machine B has a relationship that changes the response. That single feed link tells planning that the fault could affect more than just the work at the machine. It could stop downstream flow, strand material between operations, and push risk into orders that haven't even reached the machine yet. That's the kind of context a twin graph needs to hold. In practice, you model a feeds relationship from a filling machine to a pack line, a consumes from an operation to a material lot, and a produces from that operation to an output batch. A resource performs an operation, and that operation might require a tool, a skill, or a material condition.

29:37 One process blocks another, where flow rules make it true, and a condition monitoring device sits in a monitored by a relationship with the asset it watches. The relationship name should read like a sentence in engineer or planner can understand. If you can't explain what it means without opening a data dictionary, the name needs work, and the relationship carries facts of its own. A root link might need a position because the order of operations matters. A resource to operation link might need effective start and end times because a machine can gain or lose a capability after a change. A feed relationship might need a capacity share, because one upstream machine supplies two downstream lines, but not equally. A requirement link might include priority as well, since one tool can support several jobs, but only one gets first claim.

30:17 Those aren't just decorations on an edge in a graph. They change the answer to real questions. Take machine a feeding pack line to, but only during the day shift while a temporary setup runs. If you model a static feeds link, a night shift fault query might flag a risk that doesn't exist. Add an effective time window and the graph reflects the actual operating arrangement instead of a simplified drawing nobody updated after the last layout change, or consider capacity share. A mixer feeds two lines with line one taking most of its output during one product family and line two taking the balance. When the mixer slows down, both lines face some exposure but not the same exposure. That difference belongs in the relationship because it describes the connection between the entities, not a trait of either one by itself.

30:57 This is where graph queries earn their keep. Start with a resource that faulted, follow its performs links to active operations, then to effected production work. From there, move through producers, consumes and feeds links to see if material, downstream capacity, or related batches are at risk. The question shifts from which machines are down. To which released work is exposed, what material sits in the path, and where does the risk spread next? That's a much better question because it gives a plan or something to act on instead of just another alarm to acknowledge. You can also work from the other direction, start with a late order, follow root and active operation links, identify the assigned resource, then check whether that resource needs material, tooling, or an upstream output that now looks shaky.

31:40 The graph lets you travel through the same operating context from whichever fact comes first. A containment tree can't do any of that on its own. It can tell you the machine sits under a cell, line, area and plant, but it can't tell you if that machine performs the operation for an order, whether that operation needs a held batch or whether the next process depends on its output, plants need containment, planning needs dependency. So instead of starting your relationship design in a workshop with generic boxes and arrows, start with actual work moving through the plant, ask the people on the floor how they decide what a stop, hold, or shortage will affect, and draw the links they already carry around in their heads. That relationship map usually looks less tidy than the asset hierarchy, but it also looks a lot more like the plant you actually need to run.

32:21 The factory has more than one structure. Let's be clear, a factory doesn't have just one structure. It has several all laid over the same equipment and each answers a different question. There's the physical layout, building area, line, cell, machine location, which maintenance needs when someone has to find an asset, isolate a zone or understand what sits nearby. Then there's the asset hierarchy that follows ownership, maintenance responsibility, or engineering design, where a motor belongs to a machine, the machine to a production line, and the line to a plant. That helps manage equipment over time, but it still doesn't describe how production flows through that equipment today. Process routing adds another layer, a product might pass through cutting, forming, inspection, assembly, and packing, but those steps don't always follow the physical path through the building and routes change by product family, by customer rule, by material grade, or because one resource can't run a certain variant.

33:14 Material flow gives another view. Raw material enters one part of the plant, becomes work in process, waits in a buffer, splits into separate streams, then meets up later, traveling through storage locations that don't sit neatly under the same line hierarchy as the machines using it. And control structure has its own logic. A PLC can control several devices, and Edge Gateway collects data from a group of PLCs, and one controller might span a physical cell boundary while one machine exposes data through multiple control parts after years of upgrades. Plans rarely arrive as a clean diagram. They come from projects, extensions, replacements, and a few decisions nobody wrote down. If you try to force all of that into one parent child tree, you get false simplicity. Take one forming machine. Physically, it sits inside cell two.

33:55 From a production view, it belongs to WorkCenter 140. For one product family, it performs the second root operation. For another, it acts as an approved alternate later in the root. From a controls view, it reports through a PLC that also controls a nearby conveyor and inspection station. So which parent should this machine have? If you put it under the cell, the physical layout looks right, but the work center and routing context become awkward attachments. If you put it under the work center, the production view looks right while the actual location becomes secondary. If you put it under a PLC or gateway because that's how the data arrives, then the model starts following cable paths instead of operating work. None of those views should win by default. Give the machine its own stable twin, then model each structure as its own set of relationships.

34:37 The machine is located in cell two, assigned to WorkCenter 140, performs operations under defined conditions and is controlled by a PLC or connected through an edge gateway. Each relationship means exactly one thing, which keeps the model readable. It also lets relationships change without pretending the machine became something else. A resource moves to a different cell after a layout project, update the located in link. A new route adds the resource as an alternate, add a performance link, a control upgrade, changes the device path, update the controlled by link. Those changes affect separate links each with its own dates and ownership, rather than forcing someone to rebuild the entire tree every time operations change. This really matters when the plant has shared resources.

35:19 A heat treatment oven might sit in one physical area but serve work from multiple lines. A quality lab belongs to one department but releases material for many routes and a two room supplies fixtures across the whole plant. A single hierarchy can't represent that clearly because those aren't parent child relationships. They're service, dependency, assignment and flow relationships. So use the structure that fits the question. When someone asks where an asset sits, follow location and containment links. When they ask which production work it can perform, follow capability and route links. When they ask how data reaches the cloud, follow control and connection links. The twin graph should let each domain describe its own view without overwriting the others. Value stream mapping is a huge help here because it starts with how work and material actually move, not how the asset register happens to be organized.

36:04 Get process engineers, planners, operators and maintenance into the same room and map where work waits, where material changes hands, where inspection releases or blocks flow and where a shared resource creates a delay. Those aren't just workshop notes. They point directly to the relationships your model needs. A value stream map might show work sitting in a buffer before inspection, then waiting for release before packing starts, while the physical hierarchy puts all three under one line but doesn't explain the dependency. The process map does. You don't need to turn every box on a value stream map into a twin. Just use it to spot where a change in one entity changes the state or decision around another entity. That's the relationship worth modeling. Now test this against one real production scenario. A certain production order is often the better twin.

36:46 Here's a shift in thinking most people skip. Instead of starting with the equipment, start from the order. A production order gives you a solid anchor point. It connects demand to the work that actually has to happen. Think about it this way. The order ID, product quantity, due date, route, material needs and resources. That's where a local shop floor signal starts to gain real business context. A machine tells you it stopped, but the order tells you who might feel that stop. Picture an order due for shipment that day. ERP shows it released with a due date and customer demand, while MES shows it's an execution. Two operations done, now sitting at operation three on a specific resource. And that resource reports a fault. None of those facts alone answers the question, but together they get you close.

37:27 The order twin doesn't replace the ERP order record. ERP still owns the commercial side, and it doesn't replace mess as the record of execution. MES still holds the shop floor trace, confirmations, quality steps, and completion details operators rely on. What the twin does is connect the facts that need to be assessed together. Now here's how this works in practice. You model an order with links to its demand, planned route, material requirements, current operation, assigned resources, due date, and actual progress. When a resource falls, you follow the active work link and see which order depends on it. When an order looks late, you go the other way. Inspect the operation, resource, and material context around that delay. This is more useful than a machine-only model because a machine by itself doesn't tell you the schedule impact.

38:08 A stop machine could affect no live work if it's between jobs, or it could affect a low priority order with schedule room, or it could stop an order at its last operation before dispatch. Same fault code, three different actions needed, and the order is where that difference becomes visible. Now here's a practical reality. ERP order status and MES execution status often don't line up, and they shouldn't have to. ERP shows release because production was authorized while MES shows operation one not started because material isn't at the line yet. Both are correct for their own context. Neither system needs to be declared wrong. They're describing different points in the process. The problem comes when a dashboard smashes them into one vague field called status, and people spend their shift arguing over which color is right.

38:49 Just keep the fact separate with clear source labels. You might have a planned order state from ERP, an execution state from MES, and an observed operating signal tied to the resource. A planner can then see that ERP expects the order to run. MES hasn't confirmed progress, and the assigned resource has shown a fault since the last valid update. That isn't a contradiction to hide. It's the context needed to decide whether someone investigates, reschedules, or waits for confirmation. This is where the active operation relationship becomes practical. An order doesn't just connect to a route abstractly. At any moment, it links to a specific operation that could be active, waiting, complete, blocked, or ready. That operation then links to the resource doing it, or the set of resources that could do it under the right conditions.

39:32 So you might have an order linked to operation 30, and operation 30 linked to resource B12. That relationship carries the plan start, actual start sequence position, and execution status. When B12 faults, your query doesn't have to search every order. It follows the active assignment, and returns exactly the work that's exposed. That also gives planning a better starting point for recovery. APS gives you the planning context around the order, alternate resources, capacity limits, calendar rules, plan sequence, and the result of a schedule run under known constraints. Those facts matter when someone asks whether work can move. But APS still describes a plan. It shouldn't override MES execution truth or floor conditions. The schedule says run on C14 at 2 p.m. But MES says it never started, and the resource shows a fault that makes the plan unworkable.

40:15 The twin model keeps all three views in their proper place and exposes the gap that needs resolving. That is a much more honest design than treating a future schedule as proof of current production. So once orders connect demand to execution, the next layer is unavoidable. You need to know what material move through that work, which batch entered the operation, and where traceability starts to affect the decision. Material, batch, and genealogy relationships. So once orders connect demand to execution, you need to know what material actually moved. But this is where teams often build a graph way larger than the question needs. You don't need a twin for every palette, carton, or fastener moving through the plant, especially if the only reason is basic stock counting that ERP already handles. So save the material lot or batch twins for where traceability, quality, containment, or allocation actually change a decision.

41:00 Think about a batch of resin going into a molding process. If a quality issue appears later, you may need to know which finished batches used that resin, where any remaining material sits, and which active orders still depend on it. That is a connected operating question, and a material lot with identity and relationships earns its place in the model. Name the relationships plainly. An operation consumes a material lot, produces an output batch. A batch is stored at a location, reserved for an order, or quarantined by a quality hold. Those links turn a lot number into something you can reason across. Say quality places a raw material lot on hold after a supplier issue. If the lot only lives in a spreadsheet or a stock table, someone may need to export data, search transaction history, call the warehouse, and then ask production which work already used it.

41:43 It can work, but it relies on people doing detective work while the clock runs. With genealogy relationships, you can begin at the quality hold and follow the material path. Which batches consume this lot? Which output batches came from those operations? Where are those batches now? And has any batch moved into a later operation, shipments staging, or another product through a rework path? That is why material context belongs beside the quality result. A quality test result doesn't help much as a detached row with a batch ID that only one system can decode. So connect the test result, hold, disposition, or inspection status to the batch or lot it describes, then connect that batch to the work that consumed, produced, moved, or transformed it. The model doesn't have to claim one test result explains everything.

42:24 It just needs to preserve the path from the result to the work that may need a response. Genealogy gets messy fast because production doesn't move in a straight line. A batch can split. One parent batch may feed several smaller batches, each moving to a different process or customer order. Later, several inputs may merge into one output batch. Rework can send material backward through a route, sometimes with a new quality decision before it can move again. Scrap removes material from the usable path, but the record may still matter when someone traces yield or investigates an issue. Substitution adds another case. An order may reserve material.a, but a shortage or approved change causes the operation to consume material.b instead, the planned relationship and the actual relationship should not blur together. One tells you what production intended, the other tells you what entered the process.

43:08 Keep both when the decision needs both. That distinction can prevent a very ordinary but costly mistake. A planner sees material reserved for an order and assumes the constraint is covered, but production has already used a substitute lot, or the reserved lot sits on hold, or part of it went to a different priority job. The system may contain each fact somewhere. The twin model connects the facts that need to be assessed together. You also need life cycle rules for these material twins. A raw material lot might remain in the graph through receipt, testing, storage, consumption, and traceability retention, while a short-lived work and process batch may only need active context until production completes, unless quality, regulation, or root cause work requires it to remain queryable longer.

43:50 A pallet that only carries material from one staging point to another may never need a twin at all. Don't model physical detail just because it exists. Model it when its identity condition or relationship changes what someone has to decide. If a screw only matters as a quantity in a bin, a bin balance may answer the question, but if a lot can contaminate a batch, block a release, or force containment across several orders, then the lot needs a connected history. And material isn't the only thing that can block work. A job can have enough stock, a healthy machine, and still stop because the required fixture sits on another line. The gauge is overdue for calibration or the person qualified to run the operation isn't available. Resources aren't only machines. Here's the problem most manufacturing models miss.

44:31 You can have a machine ready, material staged, and the order priority set, and the job still sits idle because the fixture it needs is on the other side of the plant. That's how factories actually run, and your digital twin model has to account for that. Tooling, fixtures, molds, gauges, operators, and maintenance crews. Any one of these can become a real bottleneck, especially when a single resource supports multiple machines or product families. A mold might only fit one product range, a gauge needs to be in calibration before you can inspect with it, and a fixture that travels between cells carries a setup status that decides whether the next job can even start. So don't treat these as notes attached to equipment records, give them their own identity in your model. You need their condition, location, assignment, and history because all of those change the operation.

45:12 For a tool twin, you'd hold its type, location, service, state, remaining approved use count, and setup condition. A gauge twin would keep calibration status, expiry date, measurement range, and the operations it supports. A fixture can link to several machines with each link recording fit and product variant support. Now here's how I keep it straight. Separate capability, availability, and qualification. Capability is about whether a resource can do the work at all. Can this press make the part? Can this fixture hold the variant? Can this gauge measure the tolerance? Those facts are mostly stable, but engineering changes can shift them. Availability is about whether the resource can do the work right now. The press might be capable, but down, the fixture might fit, but is assigned to another order, the gauge might be correct, but someone is using it across the plant.

45:55 Qualification is about whether the required person or process approval exists. An operator may know the machine, but not be approved for a well-process. A technician may be on maintenance, but lack the certification for a controlled intervention. A resource can look available on paper and still fail the check. Three separate facts. Don't bury them in one field called ready. Take two forming machines that can both run a high tolerance part, sharing one fixture that needs a documented inspection after a set number of cycles. One machine starts a rush order and uses up the remaining approved cycles. The second machine still shows available capacity, but it can't start its scheduled work until that fixture passes inspection or another approved one arrives. That's not just a scheduling problem. It becomes a quality risk if people bypass the control because the graph only showed machine availability.

46:39 A proper model connects the fixture to the operations it supports, the machines it fits, its current assignment, and its inspection condition. The planar sees why that apparent capacity isn't usable, quality sees whether the control still applies, and maintenance sees what work depends on getting the fixture back. People follow the same pattern, but they need tighter boundaries. You need to model an operator's current work area assignment and their qualification link to an operation. For example, an operator can be qualified for a process step with an approval date, expiry, and a scope like a product family or equipment class. They can also be assigned to a work area for the shift. You need to know whether this operation can start safely and by the approved process with the people on this shift. You don't need a full profile or personal details that don't affect the decision.

47:21 The graph should hold the minimum human context needed for planning, quality, and safe task assignment, while HR and identity systems keep the rest. Maintenance crews work the same way. A crew or role can connect to a work area, skill group or response responsibility without exposing private details. If a fault needs electrical approval, the model can find the qualified response path without turning into a staff directory. This is where a twin graph earns its keep. An operation may need a capable machine, an available fixture, a valid gauge, approved material, and a qualified operator. Each condition lives with its own entity and the relationships let you test whether the whole setup exists. A plan that only checks the machine will look fine until the shift finds out it's not. So now you need a modeling language that can express all this without turning every factory into one giant unreadable JSON file.

48:06 DTDL defines what the business can ask. DTDL is the language that turns your whiteboard sketch into something systems can actually read. Full name is digital twins definition language, but think of it as the vocabulary your software uses to describe the plant. That contract spells out what a twin type can contain. Properties, telemetry, components, commands and relationships. And DTDL doesn't find meaning in data. Your team puts the meaning in. Take a machine model. It defines properties like operating mode, current condition, asset class, and last valid source time. Telemetry definitions letter connected system report things like power draw or cycle count, but you decide how much of that lives in the graph. And relationships like located in performs requires tool or monitored by are part of the model too.

48:50 The names matter because they become part of the shared language. An operation model needs different terms, process status, plant duration, actual start and finish, maybe a work instruction reference, and its relationships can point to an order, resource, batch or quality check. A batch model needs its own terms too. A batch isn't just a small machine with a different ID. Then you have models for orders, tools, locations, everything that participates in work. And each model describes the facts that belong to that entity, not a copy of whichever source table showed up first. That sounds obvious until someone proposes one generic model called asset. The generic asset usually starts with good intentions. Someone wants flexibility, so they add optional fields for equipment, then orders need a few more, then batches, tools, locations, devices, and before you know it, you have one model with hundreds of optional properties and nobody knows which fields apply to what.

49:40 You have created flexibility. You've removed meaning. A planner shouldn't have to pick through 30 empty properties to find an order status, and a maintenance engineer shouldn't see customer due dates on a motor model. Separate models let the contract express the natural shape of what you're describing. That doesn't mean every model starts from zero. DTDL interfaces let you reuse common definitions. For example, you can define an interface for traceable material and use it across material or batch types, or an interface for maintainable equipment with common service status and references, and apply it to machines or tools where it fits. Use reuse where the business meaning truly repeats. Don't build a deep inheritance tree where a model inherits from another that inherits from another. Nobody will be able to explain why a property exists.

50:21 The people who maintain the graph later need to read a model and understand it without tracing a family tree through six files. A good model is straightforward. It uses terms people recognize, puts facts next to the entities they belong to, and makes relationships clear, so a query writer doesn't need a translator. There's another boundary to hold. Stable domain language versus vendor specific signals. A PLC tag might call machine mode mch04 run CMD, while another controller calls it auto cycle active. Those tags belong in the integration mapping, not in the operating model, unless you want every app to inherit the naming habits of one controller. The domain model uses operating mode or is running clearly defined, while the mapping layer translates source tags, MES codes and device messages into that domain term.

51:03 When the line controller changes, the model stays stable while the mapping changes. That separation saves pain later. Lines change, a new sensor appears, an old machine gets a control retrofit, an operation gains an inspection step, a tool type becomes relevant after a product change, so you need a way to evolve models without rebuilding everything every time. Ask whether the new fact belongs to the domain or just to one data source. A new vibration sensor might need a mapping update and a processing rule, but not a new property on every machine model. A new inspection requirement might justify a new relationship or property because it changes how production work is understood. Version models deliberately keep older twins readable while moving to a new version and document why the change happened.

51:44 If you change a property's meaning, don't reuse its old name quietly. That creates a data argument that outlasts the project. DTDL gives you a controlled vocabulary, not a finished factory model. The way you design it shapes the questions your systems can ask down the road. And the next decision is about those limits. Model boundaries decide whether the graph stays usable. Model boundaries and the right level of detail. Here's something I see a lot. People add twin types without ever asking whether the boundary actually matches the work people do. So before you add another one, stop and think about who's making the decision, who the user is, how often things update, and who's responsible for keeping the data right. Take a maintenance lead standing in front of a production machine. They just need to know if it's available under service or needs review, and that's it.

52:26 For that decision, one asset level twin is normally enough. Even though the machine contains drives, motors, bearings, sensors, valves, and all the internal detail, nobody wants to see during a shift. The machine is the operating unit, plain and simple. Now here's where it gets interesting. Sometimes you need a tighter boundary. And if your team replaces motors as tracked assets, keeps service records by motor serial number and compares condition data across motor life cycles, then that motor deserves its own identity. It connects to the machine it belongs to right now, but keeps its own service and condition history when it moves or gets swapped. That's not modeling for fun. It supports an actual operating record, same thing for gearboxes. If a gearbox only shows up as a replaceable part inside a machine work order, model it as a component of that machine and keep it state inside the machine twin.

53:09 Don't create a separate node that nobody will ever query. But if your gearbox has its own inspection cycle, serial number, oil analysis record, and a history that survives machine rebuilds, treat it as an entity in its own right. The boundary follows its life, not its shape. Senses cause the most confusion because IoT architecture makes them feel important by default. A vibration sensor sends data continuously, but that alone doesn't mean it needs a twin. It's just a data source tied to a component and the processing path can link its readings to the machine or motor condition. Only create a sensor twin when the sensor itself creates work. Maybe it moves between machines, needs calibration, has a known failure state, or supports more than one process decision. If nobody needs to ask where the sensor is, whether its readings are trustworthy, or what it monitors, a source reference will do the job, and you don't gain anything by turning every physical object into a node.

53:58 In practical terms, use asset-level twins for the unit's operators, planners, and maintenance teams recognize as things they run. Add component-level twins only when the component has a separate identity, a separate life cycle, or a separate set of relationships that changes the decision. That keeps the graph at a level people can actually read. Consider a packaging cell with conveyors, sensors, actuators, safety devices, a filler, and a labeler. An operator needs one cell-level view. Whether product can flow through, which machine is blocking it, and whether they can accept the next order, the internal equipment still matters, but it aggregates into a meaningful unit, rather than forcing every user to trace 30 small nodes before they understand the condition. Aggregation doesn't mean hiding detail forever. It means placing detail behind the boundary where it belongs.

54:40 A cell-twin can show an overall operating condition derived from its equipment, while individual machine twins explain which part causes the condition. A machine twin can expose a maintenance condition derived from component data, while the motor or gearbox twin holds the deeper record for people who need it. Each layer answers a different question without asking every consumer to work at the lowest level. Update rate matters here, too. A component whose condition changes only after an inspection can work well as a twin property or a separate twin. A device producing several readings per second needs a controlled path into the model, not a graph update for every pulse. The more often the fact changes, the more you need to ask whether the graph needs the individual update or just the current operating result.

55:20 Ownership draws another practical line. If the maintenance team owns a motor record, they need a defined process for updates. If automation owns the sensor mapping, the data path needs a named owner. And if nobody can explain who corrects a stale component status or retires an old asset record, that extra detail will decay long before it supports a useful query. Short-lived entities need their own rules, too. A temporary setup, a shift assignment, or a live equipment to job assignment, may exist only while production runs. Keep it while it carries current context, then retain its history where traceability rules require it, rather than leaving inactive nodes in the graph forever. Long-lived twins also need a clear retirement process. Machines get replaced, tools leave service, and locations change names or disappear after a layout project.

56:05 That history might still matter, but active queries should not keep treating retired entities as available production resources. So before you add a motor, sensor, component, or temporary process object, pause and apply a plain test. Ask whether someone can name it, own it, keep it current, and use its state or relationships to make a different decision. If the answer is no, keep it out of the graph. But it's the five questions before creating a twin. Before you add any entity to the graph, run it through five questions. I'm not saying a checklist fixes bad architecture, but these questions expose whether you're modeling an operating fact, or just copying data from another system into a new place. First question, identity. You need to be able to name this thing in a way that still means something next year. A twin needs more than a display name, like press four or batch 117.

56:49 You need to know that same name refers to the same entity after a layout change, a rebuild or a source system migration. If the identifier changes every time an operator selects a new job, then you're dealing with a state or assignment, not a separate twin. Ask yourself what you would use to trace it through its life. For a machine, use an internal asset ID tied to a serial number and maintenance record. For an order, use the production order number, plus the source system that owns it. For a batch, use the batch ID that needs to survive transfers and later quality review. If nobody can name it consistently, stop there. Second question, action. The second question is action. You need to identify who does something differently when this entity changes. This shifts the conversation from, we have data for it, to, someone needs this to run the plant.

57:32 A current condition only earns space in the model when it can change a decision for an operator, planner, maintenance lead, quality person, or someone with a defined role. Say someone proposes a twin for each air pressure regulator on a line. That might be right. If a regulator condition can stop production, trigger maintenance work, or explain a quality risk, then it state affects real action. But if its data only shows up in a periodic engineering review and nobody needs its current condition for an operating decision, it belongs in equipment records and historical analysis instead. Just because data exists doesn't mean it needs a twin. Third question, whether relationships change the answer. An entity becomes more useful when you know what it connects to. A standalone object can often stay in the source system that already manages it, but the graph earns its place when context changes what someone concludes.

58:17 A tool linked to an active operation tells a different story than a tool listed in inventory. A batch linked to a quality hold, production work, and a storage location creates a chain someone can follow during containment. This is a good test because it cuts out a lot of decorative modeling. If you can't name the relationships you need or if following them won't change the question, then that node might not add real value. You're just creating another place to store a row of data. Fourth question, state. Decide whether the current condition matters separately from the history. Some facts only matter when you look back, like a monthly energy total, a completed downtime record or a closed maintenance cost. They support reporting and analysis, but nobody needs to see their live state. Those records can stay where history and reporting already work well.

58:59 Other facts expire quickly. Whether this resource is ready now, whether this batch has been released, whether the work is still waiting on a missing approval. Those conditions affect the next decision, not just the next report. A twin should hold a current fact when people need to reason from it while the situation is still unfolding. Fifth question, and this is the one teams tend to leave until much later. Who keeps it correct and how does the update reach it? Every property needs an owner and a path. A machine mode might come from a defined automation rule and order due date from ERP and a quality disposition from the quality process. If two systems can update the same fact, you need a rule for which one takes precedence, what happens when they disagree and who resolves the gap. Without that, the graph becomes a museum of confident but aging records.

59:41 Ownership also means life cycle ownership. Someone needs to create the twin when the entity enters use, updated when the operating fact changes and retire or archive it when it no longer belongs in active work. A model with no owner will look complete on launch day and slowly drift away from the plant after that. So use the five questions together. Ask whether it can be identified, whether a change drives action, whether relationships alter the answer, whether current state matters and whether a named source and update path keeps it correct. You don't need five perfect yes answers for every possible use case but weak answers tell you where to reduce scope, keep the data in another system or define the operating question before building anything. And that leads to a useful boundary. A dashboard can answer plenty of questions without a graph so the real task is knowing when a report is enough and when the connected model earns the extra work.

1:00:28 When a dashboard is enough, a dashboard works fine when the question stays inside a fixed set of measures over a known time range and the person using it doesn't need to trace live dependencies across several systems in real time. That covers a lot of useful work, not every manufacturing data problem needs a graph model, a catalog of entities, event processing and a new architecture layer. Sometimes you just need a good report built on clean source data with agreed definitions and a clear owner and honestly that's already harder than most projects admit. Take OE reporting as an example. You need availability, performance and quality rates by line, shift, product or work center. MES execution data, machine counts and planned production time can supply that view. Power BI gives production leads a way to compare shifts, spot recurring loss categories and see whether a line actually improved after a process change.

1:01:14 No graph traversal needed there, the same logic applies to downtime Pareto analysis. If maintenance wants to know which fault class is consumed the most loss production time over the last month, you need reliable downtime events, reason codes, durations and maybe machine or line context. A time series store or MES history can hold that data well and power BI can group it, filter it and make the pattern visible without any twin model behind it. Energy reporting follows the same pattern. You can trend power use against shift, product run, weather conditions or production volume and compare energy per unit across lines to look for drift over time. Those are analytical questions that depend on history, measures and a repeatable semantic model more than live relationships between current entities.

1:01:54 Shift reports work the same way. A supervisor might need completed quantity, scrap, downtime, open quality issues and planned versus actual output for the hand over meeting. That report should be fast, trusted and tied to the systems that record the work. If it answers the shift hand over question, don't turn it into a twin project just because someone wants a more modern architecture diagram on their slide. Dashboards can do real work, but the problem starts when people expect a report to answer a question it was never built to answer. Picture a planner staring at a late order on one page, a machine fault on another, a batch hold in a quality system and a tool start is in a maintenance record. Each page might be correct, but the planner still has to connect the dots between IT and OT under time pressure.

1:02:34 That's where dashboard only designs starts to strain. A report can show that an order is late, that a machine is down and that a material is unhauled. But if the person needs to ask right now, which released orders depend on this failed resource, whether they haven't approved alternate and whether the required fixture is free, they need more than a fixed set of report joins. They need connected operating context. You can keep adding data sets, calculated fields, drill through pages and special purpose report logic. I've seen plenty of teams do exactly that. Eventually each new question needs another report change, another data join and another debate about which system owns the status on the page. That doesn't mean Power BI failed. It means Power BI is doing what a view layer does. Power BI can present a twin model very well, but it can also present MES data, ERP data, historian data and manually entered data without any twin model behind it.

1:03:21 A polished dashboard doesn't prove that you have a digital twin any more than a clean chart proves the source data agrees. The visual layer comes last. Here's where it gets practical. A project starts with a 3D factory scene, a rendered line with machines changing color, which looks convincing in a steering meeting. A red machine catches attention, a rotating model on a big screen gets people talking, but none of that tells you whether the model can explain production impact, material exposure or the next decision a planner needs to make. A 3D scene can help when physical location changes the response. Maintenance may need to see where an asset sits near a safety zone, or a facility team may need spatial context for access routes or nearby equipment. That uses real, but animation isn't architecture. Before funding a twin model to drive a 3D view, ask a simple question.

1:04:04 If the 3D scene disappeared tomorrow, would the connected model still help someone act faster or make a better decision? If the answer is no, you might be building a visual demo with a data feed attached. Use dashboards where dashboards fit, put effort into source quality, agreed measures and reports that people actually use during the shift. Then reserve a twin model for questions where current state, cross-system context and changing dependencies need to travel together. That brings us to the cases where a twin graph earns its cost. When a twin model adds architectural value, you need a twin model when the question crosses boundaries that your source systems manage separately. That usually means many to many relationships between IT records and OT conditions, where a simple report join starts to fall apart every time the plant changes.

1:04:46 Think about it, a resource can support several operations. One operation can run on several eligible resources. A batch can pass through several process steps, while one quality hold can affect more than one batch through actual material use. A maintenance condition can change the plan for work that ERP knows about, but the PLC will never see. That is the shape of the problem. Picture a planner dealing with a resource fault during a busy shift. The MES knows which operation reports is active. ERP knows which orders carry due dates and priorities. The maintenance system knows whether the resource has an open work request. The automation layer knows the current machine condition and an APS tool may know which alternate resources fit the root under the current plan. None of those systems should surrender ownership just because you want one answer.

1:05:29 The twin model gives those facts a shared operating context. It can hold the relationships between the order, operation, resource, material, tooling, and current condition, while each source system continues to own the facts it creates. The graph doesn't become a replacement ERP, MES, or historian. It becomes the place where their facts can connect without losing their meaning, that only matters if someone needs to act while the situation unfolds. A monthly report can tell you that a machine caused late orders last quarter, but a twin model can support a live question like which released orders are exposed by this resource fault, which roots now like usable capacity, which batches sit in the affected flow path, and which alternate resources remain possible once you account for the required tool and current condition.

1:06:11 Those are not four separate dashboard filters. They are connected questions. You might begin with a resource in a fault state, follow its current assignments to active work, then inspect root relationships for approved alternatives. From there, you can check whether those alternatives carry the needed capability and whether a shared fixture or held material removes them from the real candidate list. The answer can still be no workable alternative exists, and that is useful because it replaces guesswork with a clear constraint that planning, maintenance, and production can discuss from the same facts. Event response adds the time element. When a fault, quality hold, or material shortage changes the graph, you may need a planning review, and alert, or a work Q item. The point isn't to automate every response.

1:06:52 Most plant decisions need a person who understands the current run, customer commitments, safety limits, and the things no system has captured cleanly. But the event can arrive with context attached. Instead of sending a planner and alert that says, machine B12 faulted, the response can identify the current work, the next constrained operation, the affected batches, and the resource options that failed or passed the first screening. That gives the person a starting point. It doesn't pretend a notification equals a decision. This also changes how you manage change over time. Without a domain model, the same operational rule often gets copied into dashboards, workflow apps, data pipelines, and point integrations. Then a routing rule changes, a resource gains a new capability, or a line starts sharing tooling with another area, and each consumer needs an update, with each update risking leaving one old rule behind.

1:07:39 Anyone who has maintained a long running plant integration knows how that ends. One screen uses the new definition, another screen, quietly uses the old one, and the meeting becomes about reconciling software instead of running production. A twin model gives you a shared set of domain contracts where an operation resource batch and requires two relationships can mean the same thing for a planning app, an alert process, and an analytics view. The source mappings can change and consumer applications can evolve, but the operating language stays controlled. That doesn't mean every application queries the graph directly, some will use events, some will receive prepared views, some will pull data into an analytical model. The point is that they build from the same definitions rather than each inventing a local version of the plant.

1:08:19 Engineering can define resource capability in terms that reflect the process, operations can define which states affect production flow, maintenance can define service and condition terms, and IT can define source ownership, interfaces, security boundaries, and the update path. Those groups won't agree on every detail, but the model gives them one place to resolve the meaning before it spreads into code. This is architecture that actually scales. It doesn't scale because one giant table holds every field from every system. That approach looks simple until a new product root, device type or quality rule arrives, and then every empty column begins to look like an old decision nobody can explain. It scales because each domain has clear model types, defined relationships, named ownership, and contracts that downstream systems can depend on.

1:09:01 You can add a new tool type or process step without turning a machine model into a dumping ground for every fact in the factory. Azure can provide the graph service, event paths, APIs and data connections around this work, but it cannot decide what an operation means in your plant, which resource relationship drives a planning decision, or which source should win when systems disagree. Those are domain decisions. The platform only gives you building blocks. Azure Digital Twins is the context layer. So where does Azure Digital Twins fit in this architecture? It's the context layer. Not a dumping ground for every record. It holds a live graph of the entities and relationships that let your applications ask operating questions across those systems. That distinction is what keeps the whole design from turning into a mess.

1:09:42 Inside Azure Digital Twins, DTDL defines the model types your graph can use. You define models for the entities you care about, create twin instances from them, and connect those instances through the relationships the models allow. The service holds the current property values, model identities and the links between them so a client app can query the graph directly. You can ask for a resource matching a condition, then follow relationships to see the work, location, material or equipment tied to it. The query API lets you filter on properties, model types and even properties on the relationships themselves. You're not stuck reading one record at a time and reconstructing context from scratch in every application. That matters because the graph stays a shared context service. A planning app might need a view of affected work, a maintenance app might need the assets tied to an alarm condition and an analytics process might need a current operating snapshot before blending it with historical data.

1:10:31 They don't need the same UI or the same query, but they do need a shared vocabulary, the same terms. You can also push graph changes out through event routes. When a property changes, a relationship changes or another model event occurs, route that to downstream services using event grid, event hubs or service bus. The route you pick depends on what needs to happen after the change, not on which service happens to look best on an architecture diagram. A downstream workflow might need a discrete notification, a stream processor might need a continuous flow and another app might need a reliable message. It can queue up later. Different needs deserve different choices. Now the graph itself should focus on current operating context. Don't treat it like a historian for every raw reading from the shop floor. A machine can emit thousands of values that matter for trend analysis, condition analysis or later root cause work, but that doesn't mean every value belongs as a continuously changing twin property.

1:11:20 Think of it this way. The graph needs current facts that support the decision in front of someone right now. Historical data belongs in stores built for history. The graph can point to that history and analytics can combine them, but forcing everything into one context layer creates cost and noise. A twin state tells a consumer the current condition and event route announces the change and a historical store preserves the detailed sequence. Three separate jobs and Azure works better when you let each part do its job. Here's the part many teams miss. Azure Digital Twins doesn't interpret a PLC signal on its own. It stores models, twins, graph state and relationships and it can emit events when the graph changes, but it doesn't know whether a raw tag value of one means running or blocked or a controller fault that left an old bit stuck high.

1:12:01 That meaning comes from your domain rules. External compute handles that translation. You might use a function stream processor, edge logic or another service that receives incoming data, validates its source in time, maps it to a known entity, then applies the rule to update the twin state. That processing layer decides whether a signal means the machine changed mode, whether the update is stale or whether the data quality is too poor to change the current fact. It doesn't need to become another shadow MES. Its job is narrower. Translate raw messages into the domain state your model has defined, then update the graph through controlled interfaces. That gives client apps a cleaner contract. Instead of every dashboard and custom app decoding PLC tags differently, they get an operating model with known properties and relationships.

1:12:43 Some consumers query through the API, others receive events and build a local work queue, and analytics tools may receive graph updates or read prepared data from another layer. Keep the interface clear about what it provides. A graph query answers current context and event announces a state change and a historical data set explains patterns over time. When an app needs more than one of those, connect them deliberately, rather than assuming one service does every job. This also changes how you choose as your services. Start with the decision in the data behavior. Do you need device management and secure IoT ingestion? Do you need event delivery with retry and decoupled consumers? Do you need long term time series analysis? Do you need a connected context model that apps can query as the plant changes?

1:13:23 Choose the service that fits the need. Don't start with a product diagram and work backward until a factory problem happens to fit it. As your digital twins is useful when relationships and current context need to remain first class parts of the architecture. If that need doesn't exist, another service fits better and that's fine. Now let's follow one shop flow signal through this architecture because the path from a PLC tag to an operating fact is where the model either stays trustworthy or starts to drift. From PLC signal to operating state, take a typical machine with a legacy PLC, it exposes a run bit, a fault word, a cycle count, a speed set point, a few interlocks, and maybe a heartbeat signal that tells you the controller still talks to the network. Those signals don't arrive with business meaning attached.

1:14:04 A value of one on a tag might mean automatic mode on one controller or a permissive condition on another. A fault code might identify an actuator issue or it might just tell you the controller saw a general alarm and expect someone to inspect the local HMI. The source can sit in the PLC, an industrial PC, an IoT edge gateway, or a connector that reads from an existing historian. That choice affects how data arrives but it doesn't change the modeling question. Before you update a twin, you need to know what signal came in, where it came from, when the source observed it and whether the source considered it good data, capture that metadata early. A useful incoming message carries more than a tag name and a value. It needs a source identifier. The observed timestamp, the ingestion timestamp, a quality status if one exists, and enough rooting information to connect it to a known machine or component.

1:14:49 Without those fields, a clean looking update can hide a delayed message, an old replay, or a source that went quiet an hour ago. Time matters because shop floor data doesn't always arrive in order. A gateway can lose its network path, buffer messages locally, then reconnect and send old values after newer values have already reached the cloud. If your processing path accepts each message in arrival order, an old running signal can overwrite a newer, faulted condition and the graph looks current while describing the past. That's how people lose trust in a model. So the ingestion path should preserve source time separately from cloud receipt time. The system can use the source time when it decides whether an update still applies, while the receipt time helps you diagnose, delay, buffering, or connectivity problems.

1:15:31 If the source timestamp isn't reliable, it says so in the data contract rather than treating it as precise by default. Next comes the translation rule. Suppose a machine emits a run command, a cycle active signal, a fault code, and a safety interlock state. None of those on their own should automatically become the operating mode on the machine twin. You need a defined rule that combines the signals the same way people on the plant floor already understand the machine. For example, a non-zero fault code with a valid source quality may set the condition to fault it. A healthy controller with the safety chain open may set it to blocked, not stopped. A run command without cycle activity for a defined period may indicate starved, blocked, or waiting, depending on the process and the signals available. The rule belongs in code or edge logic that people can inspect and change with control and operations input.

1:16:15 It shouldn't sit inside a report formula where no one expects to find operating logic six months later. Cycle conditions need the same care. A rising edge on a counter may mean one completed unit, but only if the counter itself remains valid and the product mode is known. Account increase during setup may need a different interpretation from account increase during scheduled production. If the system can't tell the difference, keep the condition uncertain instead of inventing a clean production fact. Uncertainty is still useful. Once the rule produces a trusted operating fact, update the twin tied to the known asset identity. Don't search by a display label like filler two because labels change and local naming often differs between MES maintenance and automation. The integration path should resolve the source device or tag group to the stable twin ID before it sends an update.

1:16:59 Write the source time with the update where your API and models supported. Keep the processing result clear too. Observed machine mode, derived fault category or calculated cycle condition. That makes it easier for a user to see whether the twin reports a direct source fact or an interpretation built from several signals. Now consider the difference between a changed property and an event worth acting on. A machine can receive many updates while it runs, but you don't need to create a workflow every time a value changes. Emit an event when a state transition or business threshold changes the next decision. A move from running to faulted may trigger a maintenance response. A machine blocked beyond a defined period may prompt production review and a cycle count reaching a service threshold may call for planned action.

1:17:41 The event should name the condition and include enough context for the consumer to decide what comes next. It can point to the affected twin, source time, rule version and the reason the event fired. Keep the raw signal detail available for diagnosis but don't force every workflow consumer to decode a controller fault word. Guard rails keep this path honest. Reject or quarantine updates that don't map to a known identity. Mark bad quality readings as bad quality readings instead of letting them quietly change the operating state. Ignore late messages when a new valid source time already exists unless you have a correction path that can safely revise the state. Connection loss needs an explicit rule as well. A silent PLC doesn't prove a machine stopped. It proves you no longer have current evidence from that source. After a defined period, the model should show the data as stale or unknown with the last valid time still visible.

1:18:27 That gives people an accurate problem to solve. Restore data confidence before treating the machine condition as fact. Once that signal path works, you can bring ERP and MS context into the same picture. ERP, MES and APS. Each own different facts. So here's the real issue with asking which platform should be the single source of truth for everything. It sounds clean in a meeting, but a production floor never works that way. ERP owns the business record around demand. Customer orders, product master data, production orders, plant inventory moves, purchasing cost, and the financial record that has to stay clean after the shift ends. ERP knows why work exists and what the business expects from it. Useful scope, right? But it tells you nothing about whether that press online three finished its last cycle 10 seconds ago.

1:19:11 MES owns execution. It records which operation started, who ran it, what quantity got completed, what got scrapped, which quality checks passed, and where the work sits as it moves through the route. MES carries the shop floor trace that turns a production order from a plan into a real record with timestamps and operator IDs. Now, a PLC sees something entirely different, machine state, account, an alarm, an interlock, or a sensor that stopped sending usable data. That signal can arrive before MES has a formal confirmation from the operator. It can also directly disagree with an MES status because the operator hasn't finished the transaction yet. Neither of you should override the other. There are different facts about the same thing. APS owns the forward-looking constraint picture.

1:19:53 It evaluates calendars, capacity, routing options, sequence rules, resource capability, and known material limits. The result is a schedule that could work under the assumptions available when it last ran. That's planning context, not proof that the plan survived contact with a real shift. Anyone who's run third shift knows that difference. Think about what each system actually answers. ERP answers, what work must we fulfill, and what does it mean commercially? MES answers, what work did we actually execute, and where did it reach in the process? APS answers, given the current assumptions, what sequence and resource assignment looks feasible? And automation answers, what does the equipment appear to be doing right now? Those facts overlap around the same order number, but they don't mean the same thing.

1:20:35 A twin graph can connect them without flattening everything into one status field. The order twin links to ERP demand and due date, MES execution records and active operations, APS plan assignments, and the resource condition coming from the floor. Each fact keeps its source and its meaning, and that gives you a much more useful view when an exception hits. Let's walk through a real scenario. APS plans operation 40 for order 871 on press P17 at 1330. Looks fine on paper. P17 has the capability and enough capacity. ERP shows the order released material allocated with a due date that leaves almost no room for delay. Then the shift starts and here's where reality catches up. The PLC reports a fault condition on P17. The last valid machine evidence shows the press never entered a normal run state after the scheduled start.

1:21:21 Meanwhile, MES still shows the operation is ready because nobody has started it or confirmed a failure against it yet. A single status field cannot explain that situation. If you overwrite the planned assignment with the PLC fault, you lose the fact that APS intended P17 to run that operation. If you overwrite MES with the machine evidence, you turn a machine signal into an execution transaction, which it isn't. If you keep only the plan, the screen lies politely and says the job should be running, so keep all three facts visible. The plan can state operation 40 is scheduled on P17. The execution record can state operation 40 remains ready, not started in MES. The observed condition can state P17 reports a fault, with the source time and the last moment the signal path looked healthy.

1:22:03 Now the gap is clear. A planner can assess another resource. Maintenance can assess the fault. Production can confirm whether work started locally, whether the job moved or whether MES needs an update. Nobody has to pretend one source tells the whole story. And this is the real reason the word status causes so much trouble. It can mean commercial release, schedule readiness, execution progress, physical machine mode, quality release or maintenance availability, put all of that behind one label, and every meeting becomes a debate about language, rather than a decision about production. Name the facts by what they describe. Use plan start and plan resource for the schedule, use execution state and actual quantity for MES. Use observed machine condition and source time for the automation path. When an application needs a simplest status for a user, derive it from those named facts and show the reasoning behind it.

1:22:47 That leaves one design problem you can't avoid. The graph needs rules for source trust and time. Source of truth is a per-property decision. The phrase "single source of truth" sounds clean in a meeting. In an actual plant, it usually creates the wrong argument because no single system owns every fact that describes the same order, resource, batch or process step. You don't need one master for the whole graph, what you need is clear ownership for each fact that people rely on. A machine's observed operating condition may come from automation, a production order due date may come from ERP. The actual quantity confirmed at an operation may come from MES, a predicted completion time may come from APS, or from a calculation that combines current execution with the plan. All those facts can sit around the same operating question and they are not competing versions of one property.

1:23:31 The trouble starts when teams use one vague field, like starters, and let several systems write to it. Automation updates it when the PLCC default, MES updates it when an operator starts work. ERP updates it when an order changes release state. Pretty soon the field contains whichever message arrived last, which is a very poor definition of truth. So split the facts by meaning. For a production operation, keep planned, start and planned resource from APS. Keep execution state, actual start and confirmed quantity from MES, keep observed resource condition from the machine or the rule that interprets its signals. A calculated property can describe the current operating assessment, but it should retain a clear rule and source basis that gives people something they can actually inspect and trust.

1:24:11 I usually separate values into four types. Observed values come from a direct measurement or equipment signal. Reported values come from a business transaction like an operator confirmation or quality disposition. Calculated values come from defined logic. Planned values describe an intended future state from ERP, APS or another planning process. Those categories sound simple, but they prevent a lot of arguments later. Suppose an order appears late. The planned finish says it should complete before the shift ends. MES reports that the current operation hasn't started, the connected press reports of fault condition. A calculated risk flag may show that the order needs review. Each fact answers a different question and none should quietly replace the others. That calculated risk flag also needs discipline. Don't let a workflow treat it as though an operator confirmed it.

1:24:54 Name it clearly, retain the rule version, where practical, and show the source facts behind it. If the plan changes or the fault clears, the calculation may change. The reported execution record does not change merely because an algorithm reached a new view. Time belongs beside the value. When a meaningful update enters the model, preserve the source time, the time your platform received it, the source reference, and a quality indicator where the source can provide one. A number without time can look current long after it stop describing the plant. A status without a source can turn into an argument nobody can settle. Quality needs the same treatment. A controller may mark a reading as bad quality. A gateway may detect a stale connection. MES may accept a manual confirmation that later needs review. ERP may publish a planned date before a scheduler finishes recalculating the route.

1:25:37 The model should carry enough context to show what people can trust and what still needs checking. Unknown is often the correct state. Teams sometimes resist that because an unknown value looks incomplete on a dashboard. But marking uncertain data as certain just makes the screen look better, until someone acts on it. A planner can work with machine-conditioned unknown last valid signal at this time. They cannot work safely with a green status that came from a dead connection. You also need a reconciliation path for the cases where systems disagree. Don't hide the disagreement by selecting a winner without context. First, decide whether the values actually describe the same fact. An MES operation marked ready and a machine marked faulted are compatible. One describes execution state, the other describes equipment condition.

1:26:18 When two sources claim the same fact, define the precedence rule before the incident. Perhaps automation owns observed mode, while MES owns confirmed execution status. Perhaps a quality disposition only becomes final after control approval. Perhaps ERP owns the due date, while APS owns the current plant sequence. Then define who resolves exceptions. A mismatch should create a visible work item, review state or reconciliation process for the team that owns the business decision. Automation engineers shouldn't quietly repair MES execution records. Planners shouldn't override a machine signal just because it makes the schedule easier to read. Each team needs a path to correct the fact it owns with the graph showing the current state of that disagreement. That is a more honest form of truth. Not one database claiming to know everything, but a model where every meaningful property has a source, a time, a quality state and a rule for conflict.

1:27:05 Current context needs that discipline. History needs a different home. Current graph event history and time series history. Here's a mistake I see all the time. Once you've settled on which source owns each current fact, don't try to cram every kind of history into the twin graph. People see a live model and immediately assume it should become the full archive for every signal, update, transaction and production event that ever happened. But that's not what it's built for. The current graph answers a narrow but useful question. What appears true now, based on the latest trusted information, a machine links to its active work, a batch links to its current location and quality disposition, and an order links to the operation in progress plus the resources that can affect it.

1:27:45 That's the working context you need to keep a shift running. You don't need anything else to make that call. The graph doesn't need to replay every state change from the last six months just to tell a planner whether a released order depends on a resource that's down. It needs the latest usable state, the relationships around that state, and enough timing information for someone to judge whether it's still current. Think of the graph as the operating map you have opened during the shift. It shows where work sits, what it depends on, and what condition those dependencies report right now. Events answer a different question entirely. What changed, when did it change, and what business occurrence did that change represent? A machine fault triggers an event, a quality hold on a batch triggers one, and so does a work order release, a material substitution or a completed inspection.

1:28:27 Each one needs a name, a source time, a source reference, and enough context to trace it later. That event record becomes part of the operational trail you may need for audit work, traceability, incident review, or just figuring out why a plan changed mid-shift. Here's the key distinction. The graph may now show the batch as quarantined, but the event history tells you when the hold went into effect, what caused it, and which system or process recorded it. Keep events as named facts rather than a vague stream of changed fields. When a machine property changes from running to faulted, the state update tells the graph where things stand now, but the fault event tells the rest of the architecture that a defined occurrence happened, and it can carry a fault category, source time event ID, and a link back to the machine and effected work.