Your Machine Data Never Becomes a Decision. Here's the Missing Pipeline.

0:00 did Y/X/L still sits between the alarm and the action. This is exactly why X/L still shows up right in the middle of a modern factory architecture. A planner gets a message that Line 3 stopped. They open the MES to confirm the active order. Then they check ERP for demand, material and due dates. They call the supervisor to find out whether the line can restart soon. They may call maintenance as well because an alarm code without a repair estimate doesn't tell planning much. Then the planner opens a spreadsheet. That spreadsheet might hold the current sequence. Local capacity assumptions, alternate machines, tool restrictions, known customer priorities and notes from the morning meeting. None of that means the planner distrusts the enterprise systems. Usually it means the planner needs one place to think through a decision while the factory keeps moving.

0:41 Excel is faster that you can add a note. You can try an alternate sequence. You can put two orders next to each other and ask, "If I move this one, what breaks?" You can capture something nobody has modeled properly yet. A tool that is technically available but takes half a shift to change. Or an operator who knows a difficult setup. That local context is often real. It just isn't connected to the event that triggered the work. I think it's a mistake to treat Excel as proof that operations are careless or behind the times. In many factories, the spreadsheet survives because it does a job the formal systems don't do well enough. It bridges gaps between planning and execution. It stores experience. It deals with exceptions that the master data never captured. The problem starts when the spreadsheet becomes the only place where the decision exists.

1:22 A planner receives an alarm at 11.10. Builds a revised sequence in Excel and sends it by email or chat. The supervisor acts on it. The MES update follows later if it follows at all. The formal schedule may still show the old sequence for hours. By the next day, nobody can easily reconstruct which facts drove the decision. That creates risk not because a spreadsheet is bad, but because the decision path becomes hidden. Someone may assume an alternate machine can run the job, but the tool hasn't arrived. Another person may change the customer priority after the file was sent. A maintenance estimate may change from 20 minutes to most of a shift. The spreadsheet doesn't automatically know any of that. And when the next disruption appears, people repeat the whole investigation. There is also an audit problem.

2:03 If a customer asks why in order missed its date, you want more than a vague answer that the line stopped and the team did their best. You want to know which event triggered the review what the production state looked like at that time, which alternatives were considered, who approved the response and what action followed. That is not bureaucracy for its own sake. It is how you learn from disruption. A good decision process lets you compare the expected impact with the result. Maybe moving the order protected the customer commitment. Maybe it pushed another urgent order into trouble. Maybe the team always chooses the same work around because a certain machine keeps creating the same constraint. Without a record of decisions and outcomes, those patents stay trapped in individual memory. So the goal is not in ExcelBand. If you walk into a plant and announce that all spreadsheets must disappear, someone will quietly show you the file that keeps production running every Friday afternoon.

2:49 They will probably be right. The better question is, which part of the spreadsheet is useful reasoning and which part only exists because systems fail to exchange context? Keep the useful reasoning close to the person who owns the decision. Bring the source facts into the same decision flow. Record assumptions. Make the approval clear. Then write the chosen action back into the systems that need to carry it out. That approach changes the role of Excel. It can remain a personal analysis tool where it helps. It no longer needs to act as the unofficial integration layer between an alarm, a planner, maintenance, and the production schedule because that is a fragile job for any spreadsheet, even a very well loved one. The practical replacement isn't one giant platform that claims to know everything. It is a path that captures the event, adds the right context, supports the decision, and sends the approved result into real work.

3:34 The missing pipeline, from signal to changed plan. So if the spreadsheet is filling gaps between systems, what should sit there instead? I use a simple model. Capture, interpret, decide, and act. Not because every process fits neatly into four boxes, but because it makes you ask where an event stops moving and where a person starts doing manual detective work. Capture starts close to the machine, where a controller, sensor, or supervisory system detects a change and produces an event. That event needs enough detail to be traced later, including its source and the time it occurred, and it also needs to arrive reliably, even when a network connection has a bad day, which factories tend to have at the least convenient time. Interpret comes next, and this is where the machine signal becomes an operational event.

4:14 The system identifies the asset, checks what production was doing at that moment, and links the event to the relevant order, operation, line, and shift, while also testing whether the data is trustworthy enough to use. Without interpretation, you have a stream of facts, but with it, you can ask a useful question. For line three, the question is simple. Does the stop threaten the current production plan? That takes more than fault code data. You need the active operation, the quantity already complete, the work left, the planned sequence, the downstream buffer, and maybe the current maintenance state. The goal isn't to load every system record into one place. It's to bring together only the facts that change the response. Then comes the decision layer, which applies the rules that people already use, even when those rules live in someone's head.

4:54 It can assess whether the stop needs immediate maintenance escalation, whether the planner should review an alternate resource, or whether the disruption stays inside an acceptable buffer and needs no schedule change yet. That layer might be rule based, it could call a planning engine, or it could produce a ranked set of options for a human to review. The right approach depends on the decision, the risk, and the quality of your source data. What it shouldn't do is quietly act as if a fault event equals a production instruction. The person who owns a plan change needs to see the consequence and the assumptions behind it, so if the system suggests moving work to another machine, it should state why that machine qualifies, what capacity it consumes, and which other order may move as a result. A recommendation without its reasoning is just a polite looking guess.

5:35 After approval comes action, and that means something changes in the working process. A maintenance task may be created, a supervisor may receive a structure escalation, a planner may approve a revised sequence, the MES may receive a dispatch update, where the interface, governance, and plan process supported, and ERP may receive a controlled update when the production change affects a formal commitment. This is where many otherwise good data projects stop short. They produce a notification and call it closed loop, but a notification only opens work, while a closed loop records what someone chose, sends that choice to the place where work happens, and captures the result so the next decision can improve. The pipeline also needs different speeds for different decisions, safety and machine control operate in a local fast time window, and those decisions belong close to the equipment under the controls and safeguards already approved for that process.

6:23 Nobody should send an emergency stop through a cloud analytics pass just because a dashboard looked concerned. Operations awareness may need seconds. If a line remains stopped, the supervisor needs to know quickly, with enough context to assign ownership. Planning coordination may run on minutes, because the team needs to assess repair time, buffer alternate capacity, and order priority. A wider reschedule may take longer still, especially when it changes customer commitments or supplier actions. All of those can relate to the same machine event, but they don't need the same architecture or the same response time. That distinction prevents a lot of bad conversations about real time, because real time isn't a bad you attach to a platform. It's the amount of time you have before a decision loses its use.

7:03 Microsoft fabric real-time intelligence can play a strong role in the middle of this pipeline, where event data needs to be brought in, shaped, queried, connected to operational context, and used to trigger work. It does not replace the controller at the machine, it does not become your MES, and it does not calculate a feasible production schedule simply because it can receive a stream. It provides a shared place for the information paths between those systems. And to build that path properly, we need to start where the data begins, not where people eventually view it. Start at the edge, not in the dashboard. The decision pipeline starts near the machine, because that is where the first, trustworthy fact appears, and not every machine signal should leave the plant. A high-speed controller can produce more data than a planning decision will ever need, and sending every tag-change upstream doesn't create better production awareness.

7:47 It usually creates noise, cost, and a much harder job for the people trying to find the events that matter. The edge has a practical role here, it collects machine data close to the source, filters it, normalizes it, and buffers it when the network link isn't available. That work belongs near the shop floor because the shop floor has its own limits, its own network zones and equipment that may outlive several cloud strategies. A controller from the 1990s doesn't become less useful just because somebody wants a modern data platform. It still runs a physical process. It may communicate through an older protocol, it may sit on a protected network, and it may need to keep working during a network outage, which is a fairly reasonable demand from a machine that produces parts for living. So don't start with a dashboard requirement. Start by asking which signals help identify a decision-relevant event.

8:31 For line three, that might include the machine state, the fault code, the active mode, and perhaps a small set of process values that help maintenance assess the condition along with a production count or batch state from a nearby source. The answer depends on the use case, but it should remain tied to the decision window. The edge can also improve the basic quality of what moves upstream by applying a consistent timestamp, mapping local tag names to approved asset identities, rejecting impossible values, flagging poor signal quality, and storing data locally until a connection returns. That doesn't mean the edge decides whether a customer order should move. It just gives the rest of the architecture a reliable starting point. OPC UA and MQTT often appear in this part of the design.

9:12 They matter, but they don't solve the business problem on their own. OPC UA, open platform communications unified architecture, is widely used to expose industrial data in a structured way, helping a gateway, or edge service read data from controllers, machines, and industrial systems while preserving useful metadata. MQTT message queuing telemetry transport is a lightweight publishing subscribe pattern that works well when many devices or applications need to exchange messages. Both can move information, but neither knows whether line of threes current stop, threatens a delivery date. That distinction keeps the architecture clean. Protocols handle communication. The event model gives a signal, a consistent form. Production systems supply execution facts and planning logic tests options.

9:54 Trying to force MQTT topics or OPC UA tags to become a complete business model tends to create a very technical version of master data chaos. For Microsoft's centric plans, Azure IoT operations is one option for the edge layer. It runs through Azure Arc enable deployment patterns and supports industrial connectivity, local data processing, and data flows between the edge and cloud services, fitting well where you want to manage the approach across several sites, especially when you already use Azure and need a consistent way to operate edge workloads. But it is an option, not a requirement. You may already have an industrial gateway, a historian connector, a vendor platform, or a local MQTT broker that does part of this job well, and replacing working shop floor infrastructure just to produce a cleaner architecture slide is rarely a good first move.

10:40 The question is whether the existing edge layer can publish reliable governed events into the wider decision flow without weakening planned security or interfering with production. Keep control local, a machine safety response, an interlock or a fast control loop belongs in the controller and the approved local automation design, while a cloud connected analytics platform can support awareness, analysis, and coordinated business response. It should not become part of a safety path just because it can receive a message. That boundary also helps when connectivity fails. The machine continues under its local control logic, the edge stores or forwards the data when it can, and when the link returns, the wider platform can reconcile the missing event history rather than pretending the factory stopped existing because the cloud could not see it.

11:23 Once the edge has collected and cleaned the source data, the next job is more subtle. A raw tag change still isn't something a planner can use. It needs to become a named industrial event with a clear meaning, a source, and enough information to follow through the rest of the pipeline. Turn tags into meaningful events. Here's the problem most manufacturers don't talk about. A tag change is just a technical observation. It might tell you that a bit moved from zero to one, that a motor current rose, or that a machine state changed, and the controller understands that signal perfectly because it lives inside the control logic. But nobody else should need to reverse engineer that during a production issue. A meaningful event gives that signal a name that operations can actually use. Instead of passing along a tag called DB42, stop status, you create an event that says, line three press entered an unplanned stopped state.

12:08 Now the event still retains the source tag and source value. Maintenance may need them later, but it also carries a meaning that makes sense outside the control program. Think of the event as a contract between the shop floor and the rest of the business. That contract needs an asset identifier that every connected system can recognize. It needs the time the event happened, ideally both the time at the source and the time the platform received it. It also needs the state itself. The reason where one is known, the data quality and the source system that sent it. A correlation identifier helps too, especially when several records belong to the same incident. A fault might produce a stop event, then an operator acknowledgement, a maintenance response, and a restart event. Without a shared way to connect those records, you end up counting one disruption several times.

12:50 And that's a surprisingly easy way to make an OE report look busier than the factory actually felt. The event must also state how certain it is. A controller may report a stop, which is a strong machine state, but the reason for that stop may be less certain. Maybe the alarm could point to a drive fault, maybe the operator later records that material jammed upstream. The event model should allow both facts to exist without forcing an early conclusion, and that matters for quality as well as maintenance. Take a reject spike, for example. You need more than a count. You want the asset, the product, or recipe context if it's available at the source, the relevant quality signal, the time window, and a way to relate the spike to the production run. A recipe deviation needs the expected setting, the observed setting, the permitted range, and the source that reported it otherwise.

13:34 The central platform just receives a number with no operational meaning. Normalization happens before the event starts traveling widely. Local units need a known form, timestamps need an agreed format and time basis. Acid identifiers need mapping rules, and state codes need a control vocabulary, so one source doesn't report fault while another reports error and a third reports stop when all three describe the same operating state. Now, that doesn't mean every plant needs to force every vendor system into one huge naming standard overnight. You can map a local language into a shared event schema while keeping the original data intact. The original tag name, raw value, controller timestamp, and protocol metadata should stay available for diagnosis. When a maintenance engineer asks, why an event classified as stop in a certain way, the system needs evidence.

14:19 Not a cleaned up story with no trail back to the machine. This becomes especially useful when data quality goes wrong. A missing timestamp and impossible value, a stale connection, or an unknown asset mapping, should become an explicit condition in the pipeline. Don't quietly drop it and hope nobody asks. A bad event can be more dangerous than no event when it feeds a production decision with false confidence. So give the event a status, valid, incomplete, rejected, or pending mapping. So people can see where the information chain needs repair. That prevents a vague source problem from becoming a false production fact. For this use case, you might define a small set of event types that connect to real work. An unplanned stoppage, a sustained speed loss, a sharp rise in rejects, a recipe setting outside an approved limit.

15:00 A maintenance condition that needs review, those names should come from the decisions you need to support, not from a list of every tag the PLC can expose. There's a discipline here, keep raw telemetry for engineering analysis, fault diagnosis, and later model work, but promote a smaller set of events into the operational flow. Events that have an owner, a meaning, and a possible consequence. That gives the planner and supervisor something they can understand without reading a PLC program. Once those events exist, the next problem is getting them to the right consumers reliably, without building a separate direct connection from every machine system to every business tool. Event transport, reliable movement, clear boundaries. Once an event has a clear name and a usable structure, it needs to move through the factory architecture without creating a new mess of direct links.

15:40 This is where a streaming backbone comes in. Its job is simple. A producer publishes an event once and the systems that need it consume it independently. The edge source doesn't need a separate connection to maintenance, planning, reporting, and every future analytics project. That separation matters. If every shop floor source talks directly to every business application, the architecture becomes hard to change, add a new consumer, and somebody needs to modify an existing integration. Replace a maintenance system and suddenly machine connectivity becomes part of that project. A line upgrade turns into a chain of side effects across systems that shouldn't need to know about each other. A stream creates a boundary. The edge or gateway publishes a normalized event into the transport layer. Maintenance can consume it. A real-time analytics service can consume it.

16:21 A service that checks data quality can consume it too. Each consumer has its own purpose, its own pace, and its own failure handling, and the event source stays focused on producing trustworthy events. Azure EventHubs can play this role in an Azure-based architecture. It's a managed event streaming service built for high volume data ingestion, and it also exposes an Apache Kafka endpoint. That matters when an existing gateway application or industrial data service already uses the Kafka protocol. Now that doesn't mean event hubs turns into a Kafka cluster in every respect. It means Kafka compatible clients can connect through that protocol endpoint often with configuration changes rather than a full rewrite. For an architect, that can reduce friction when you inherit a mixed estate with existing Kafka producers or consumers.

17:03 But don't choose a transport layer because the protocol name sounds familiar. Choose it based on the event flow you need. How many events arrive? How long must you retain them? Which systems need independent access? And what happens when one consumer falls behind? How do you secure the connection from the plant boundary into the cloud? Those are operational questions, not just platform questions. There's another point that gets missed in early designs. Event delivery is rarely exactly once from source to every consumer. Networks retry, gateways reconnect, producers can send again after an uncertain acknowledgement. A consumer may restart and read an event again. Duplicates are normal, so your downstream logic needs to handle them. That's why the event contract should include a stable event identifier, a source sequence number where available, and enough time and asset context to detect repeated records.

17:44 If Lena3 sends the same stopped state event twice, you don't want two maintenance cases or two separate planning assessments. You want one incident with a traceable event history. Replay matters for the same reason. When you fix a transformation rule, change a data quality check or introduce a new consumer, you may need to read past events again. A retained stream lets you do that without asking the machine to recreate last Tuesday's fault. That's useful for testing, diagnosis, and learning. And it also means consumers should treat the stream as a record of events, not as a one-time notification that vanishes after somebody reads it. Partitioning needs care as well. A stream usually distributes events across partitions so it can handle volume, yet events related to one asset or one production line may need to remain in a meaningful order.

18:26 A stop event should not arrive after a restart event for the same machine. At least not from the perspective of the consumer trying to calculate duration. So choose a partitioning approach that reflects the decision context. For some cases, the asset identifier makes sense. For others, the line identifier fits better because the analysis depends on the sequence across equipment in that line. There isn't one universal answer. The choice should follow the relationships your consumer needs to preserve. Ordering also has limits. You can preserve order within a partition but you should not assume a single perfect time sequence across an entire factory. Controllers have different clocks, networks, introduced delay. One side reconnects after an outage while another keeps sending live data, keep both source time and arrival time, then let the analysis decide which one matters for the question being asked.

19:09 Retention, replay ordering duplicates and consumer groups may sound like plumbing. In a factory, they decide whether the pipeline can survive normal operational mess without inventing false events or losing the history needed to explain a decision. The transport layer should move events reliably and keep producers separate from consumers. It should not decide what an event means, change a production schedule, or become another place where master data quietly drifts. That comes next when the stream enters Microsoft Fabric Real-Time Intelligence and starts connecting data movement to analysis and action, where Fabric Real-Time Intelligence fits. Think of it this way. Microsoft Fabric Real-Time Intelligence sits between the moment and event enters a reliable stream and the second someone needs to turn that event into actual operational work.

19:50 It gives you a common data and analytics plane for data in motion, ingestion, shaping events while they move, storing them for fast analysis, querying, presenting results, and triggering defined actions. For a manufacturing team, that removes a lot of custom glue between machine events, operational data and the people who need to respond. But here's the thing. I'd be careful with the word "platform". Fabric Real-Time Intelligence doesn't replace the MES and it won't become the system that controls a production operation. Holds detailed genealogy or confirms every shop floor transaction. It also won't replace an advanced planning and scheduling system, or APS, where you need to test a revised sequence against real capacity, routing, tooling, material, and labor limits.

20:32 Fabric sits between those systems as a place where their data can meet around a live event. Take line three again. The event stream carries a meaningful stop event from the edge. Fabric can receive that event, rooted to the right destinations, and make it available for fast analysis alongside other live events. It can also connect that stream with trusted operational context from MES, ERP, maintenance, or planning data. Now, a question becomes possible that no raw tag can answer. Is this stop simply a maintenance issue or does it now need a production decision? Fabric Real-Time Intelligence includes a few parts that matter in this flow, each with a distinct job. The Real-Time Hub gives teams a place to discover, manage, and work with streaming data sources.

21:12 That sounds administrative, but it matters when different teams build separate pipelines without knowing another team already publishes the same machine state or line event. You don't want maintenance, quality, and operations each creating their own slightly different version of machine stopped. That's how plants end up debating the dashboard instead of the disruption. Event stream handles the movement and basic shaping of data in motion. It takes data from streaming sources, applies simple transformations and routing, then sends the stream to destinations that needed. In practical terms, event stream helps you separate one incoming event source from the several parts that may follow. A line three stop can feed Real-Time Analysis, flow into retained history, support a downstream data product for reporting or trigger a workflow for escalation, or without asking the edge gateway to know every consumer in advance.

21:57 Event House and its KQL database sit on the analysis side of the flow. KQL means "Custal query language" built for "queering event, log, and time series data" at speed. In manufacturing terms, this is where you ask questions across many events. When did this stop begin? How long has it lasted? What faults occurred before it? Which other assets show the same pattern? And how often did this condition happen during a given product run or shift? That supports investigation while the event still matters. A Real-Time dashboard can present the operational facts in a former supervisor or maintenance lead can use. But the dashboard is just one consumer of the pipeline, not the pipeline itself, and certainly not the decision process. Fabric can also support action through activator, which watches defined conditions and triggers a response such as an alert or a workflow.

22:41 Used carefully, that helps move from passive monitoring toward assigned work. Used badly, it creates another flood of messages everyone learns to ignore. We'll get into that later, because condition design deserves more attention than it usually gets. The wider fabric environment matters too, because machine events rarely live alone. Historical production data, master data, quality data, and business data may already sit in one lake or arrive through other fabric workloads. That gives you a route to connect live events with slower moving context without building a fresh point-to-point link for every question. Still, keep the boundaries clear. Fabric provides the shared data plane, streaming analysis, and activation paths. Your manufacturing systems provide the execution facts and business rules they already own.

23:22 Your organization defines what a stop means, who can approve a plan change, and which actions are safe to automate. No Microsoft service can decide those things for you. So let's follow the line three event as it enters this fabric flow, because that's where the architecture becomes less abstract. The line three event enters the stream. Stay with the same stop on line three, but now follow the event after it leaves the edge layer. The event arrives in the stream with a fault code and asset ID, a state change, and a source timestamp. It may also carry the controller name, the gateway that forwarded it, and a source sequence number. Those details can field boring until you need to explain why the system treated one stop is real and ignored another. At this stage, the pipeline should check the event before it drives any analysis.

24:03 Does it match the agreed event schema? Is the asset ID known? Does the timestamp make sense? Is the state transition possible? A machine should not appear to restart before it stops unless the source clock or message order needs attention. That kind of check protects the rest of the flow from bad assumptions. You also need to handle duplicates early. A gateway can resend a message after a network interruption, or a producer may not know whether the first send succeeded and sends the event again normal behavior in distributed systems. The pipeline should identify that both records describe the same source event, retain one operational event, and keep enough trace data to prove what arrived. Don't just delete duplicates without a record. If an operations team later asks why the downtime duration changed, you need to show the source messages, the rule that detected the duplicate and the event the system kept.

24:47 Trust in a real-time process depends on that traceability. People don't need every technical detail every day, but they need to know the data can be challenged. Once the event passes validation, it can be enriched with identity and hierarchy. The source may send an ID like M03, the central model can then attach the approved machine name, its line, its plant, and perhaps its work center. In this case, M03 becomes the specific line-3 resource that planning, maintenance, and production systems recognize that enrichment should not invent production context yet. It simply makes the machine identifiable in a shared form. You want the event to state clearly which physical asset change state, where it sits in the plant structure and which source reported it. This gives consumers a stable starting point. A maintenance application may care about the fault code and machine identity.

25:31 An operations team may care about the line hierarchy and whether the stop remains active. A reporting model may need the plant and work center for consistent aggregation. Each can use the same event without asking the source system to produce separate versions. Then the stream branches. One part supports immediate event analysis keeping the line-3 stop available for queries that need to know whether the machine remains down, whether similar events are appearing, or whether the stop has crossed a time threshold that requires attention. Another path retains the event history that matters when someone investigates a recurring fault, checks how long a condition lasted, or rebuilds the sequence after a network problem. The current event tells you what needs attention now. The retained history helps you explain how the situation developed.

26:14 A further path can feed downstream data products, where live events become part of wider operations, maintenance, quality, or production data. Those consumers may work at a slower pace and that's fine, they should not block the immediate path just because a reporting refresh or a batch process takes longer. This separation keeps the stream useful under pressure. The line-3 event should not wait for every downstream system to be ready before it becomes visible to the people who need to assess it. At the same time, the event should not disappear after an alert fires, both requirements matter, and they need separate paths. There's one more condition worth treating seriously, bad data. Suppose the event arrives with an unknown asset ID or the source timestamps sits far outside the expected range or the gateway reports poor signal quality.

26:55 Don't bury that record in a technical error log and carry on as though the production picture remains complete. Treat it as an operational condition. The system can flag that line-3 may have sent an event that could not be linked to the shared asset model, root that issue to the data owner, and preserve the raw record for diagnosis. The planning process may decide not to use that event until the link is confirmed. That's better than attaching a machine stop to the wrong resource and producing a confident but false assessment. A stream with visible data quality issues can improve. A stream that hides them slowly becomes fiction. By this point, the line-3 stop exists as a validated, traceable event with a shared machine identity, a clear place in the line hierarchy, and paths for immediate use and retained history that gives Fabric a strong event record.

27:36 But time series storage alone still can't answer whether production should change. It tells us what line-3 did and when. The next step is asking questions across the moving event data without pretending that a query result is already a production decision. Event House and KQL ask questions while the data is moving. So at this point, the line-3 stop has a clean event record. We know which machine reported it, when the state changed, and which source produced the data. Now we need to ask better questions while the event still affects production. That's where Event House and a KQL database fit. Event House is the real-time intelligence environment built for event and time series data. A KQL database stores that data in a form designed for fast investigation across large event volumes. KQL means "Cousto Query Language".

28:16 Think of it as a query language built around event sequences, timestamps, filters, and how records relate to each other. Instead of waiting for a nightly load and then asking what happened yesterday, you can examine what's happening right now and compare it with prior events. For the line-3 stop, the first question sounds basic. How long has the machine actually been stopped? But that isn't always the same as the time since the first alarm. A fault can appear clear and reappear. The machine can move through states that look stopped from one source, but actually represent a planned condition in another. With a properly defined event stream, KQL can group those state changes into a time window and calculate the active stop duration. That gives operations a more useful fact than a flashing alarm. You can also ask whether this fault has shown up before, not just on line-3, but on the same machine during a similar product run or unrelated machines with the same drive type.

29:02 You can search for the same alarm code, look at the events before it, and compare the time between fault, maintenance response, and restart. That doesn't prove root cause, but it gives you evidence for an investigation. And there's a big difference. A repeated pattern can point maintenance towards a likely area, but it doesn't confirm that a bearing, cable, recipe, or operator action caused the fault. The system should describe what the data supports, not turn a correlation into a repair instruction. Time windows need care too. Let's say line-3 reports are stopped just before a shift handover. One operator acknowledges the event, another adds a reason code later, and the machine restarts after the handover. If you group events using only clock time, you can split one physical incident into two reports. Product changeovers create a similar issue.

29:44 A speed drop during a plan setup means something different than a speed drop during stable production. Plan stops, cleaning cycles, maintenance windows, and quality checks all affect how you read the same machine state. KQL gives you the tools to filter, group, join, and inspect those sequences, but the hard part remains defining the business rules correctly. For example, you might query all unplanned stops that lasted longer than the normal short-pause threshold during active production, then group them by line, product family, shift, or fault code. That can expose recurring loss patterns that disappear when every alarm sits alone in a technical log. You might also ask a more immediate question, which assets near line-3 showed related conditions in the minutes before the stop, maybe an upstream conveyor reported blocked flow or a shared utility system changed state or several machines reported communication problems at the same time.

30:33 That suggests a network issue rather than several independent mechanical failures. Again, that's investigation support. A good query gives the team a focused set of facts in a clear time sequence. It doesn't pretend it solved the problem just because it found two events close together. This is also where a KQL database becomes useful beyond a live dashboard. A dashboard might show line-3 is down, but a query can examine the lead-up, compare prior incidents, measure duration, and test whether the same condition is spreading across related assets. That changes the conversation from what color is the alarm, to what pattern are we dealing with, and how much time do we have? Still, all of these questions remain mostly about the event history. They tell us about the machine, its state, and its past behavior.

31:14 They don't yet tell us which work order is affected, how much work remains or whether another resource can take over. For that, the live event data needs to meet production context. The context join machine, order, product, and constraint. The event history can tell you that line-3 stopped at a certain time and that the fault remains active. But to decide whether production needs to change, you need to know what line-3 was supposed to produce when it stopped. That information usually comes from the MES or from an operational store that receives MES updates. The join needs to find the active work order, the operation in progress, the quantity completed, the quantity still waiting, and the execution status at the time of the stop. Timing matters here. If the stop occurred during a setup, the affected work order may not yet be running. If it occurred just after an operator completed a batch, the machine might already be waiting for the next order.

31:59 A system that simply picks the last order assigned to the machine can produce a neat answer that has nothing to do with the physical state of production. So the context join needs effective time, not just a current record. Think about the question in plain terms. When the machine stopped, what job did that stop interrupt? The answer might come from an MES dispatch record, a machine interface, an operator confirmation or a combination of those sources. Where the answer remains uncertain, the system should state that uncertainty and root the assessment for review. Once you know the work order, the product and routing become relevant. The rooting tells you which operation line-3 performs and where that operation sits in the wider production process it may tell you whether the product can move to another qualified resource, whether the next operation can begin without this one and whether a change creates a problem elsewhere in the root.

32:44 A work order alone isn't enough. Two orders can use the same machine but face completely different constraints. One may run a standard product with several approved alternatives, the other may need a specific process capability, a customer approved root, or a validated setup that limits where it can run. The stop duration may be identical while the planning options are completely different. This is where master data and an APS model, if you have one, enter the picture. They can describe which resources qualify for the operation, which tools each resource needs, which setup rules apply, and whether the alternate resource has capacity during the relevant window. But the word relevant does a lot of work here. A machine that looks free tomorrow afternoon doesn't help if the order needs to ship tomorrow morning.

33:24 Material also needs a place in the decision. ERP may show that the required material exists on paper but the context join needs to ask a more practical question. Is the material released? Is it in the right location? Can it reach the alternate resource in time? Has the batch passed incoming inspection or does a quality hold prevent use? Production planners know this problem well. Inventory on a report and material ready at the machine are related, but they aren't the same fact. Tooling creates the same issue. An alternate machine may technically run the product, but only after a die change, a fixed-jermove, a cleaning cycle, or a lengthy setup. The resource capability record may say yes, but the physical plant may say not yet. That difference belongs in the context model. Maintenance context can change the answer too.

34:05 Let's say line three has stopped, and the obvious response is to move work to line two. But line two has a planned maintenance window later that shift, or its technician has already identified a condition that makes extra loading unwise. A schedule that ignores maintenance work may look feasible until it meets the real factory. Labor needs the same respect. An alternate resource may need a qualified operator, a specific inspector, or a setup technician who isn't available until the next shift. That doesn't mean every staffing detail must sit in the first version of the pipeline. It means you should include labor facts when they alter the decision you want the system to support. Then there's time context, which ties all of this together. The pipeline needs the current production schedule, the shift calendar, the delivery commitment, and the state of the downstream buffer.

34:46 If the next process has enough work to continue for several hours, the line three stop may not create an urgent flow problem yet. But if that downstream buffer is nearly empty, the same fault may need an immediate response even before the repair estimate is clear. Due date risk is also more than a due date field. You need to know how much time remains, what work remains after line three, whether transport or customer cutoff times apply, and whether another order has a higher priority. That's why planners don't solve disruptions by sorting one spreadsheet column. A due date is part of a constrained picture, not the whole picture. When these facts come together, the stop event becomes linked to an active order, a product, a process step, available resources, material status, tool limits, labor, maintenance state, and the clock that production is working against.

35:29 That doesn't yet calculate the right response, but it gives the decision process something much better than an isolated alarm, a connected set of facts that can be checked against the relationships in the factory. Why a shared data model comes before AI? Here's the issue that shows up, as soon as you connect machine events to production context. The same machine may have four names. The PLC calls it press 0-3, the MES calls it WC-3-10, and ERP sees it as a cost center. Meanwhile, the planners spreadsheet uses the name, everyone on the shop floor actually prefers, because that name survived three system migrations. If those names don't resolve to a single approved asset identity, any AI system will get four partial stories about one physical machine. That's not an AI problem, it's a data model problem, and it doesn't stop at machines.

36:12 It applies to products, operations, fault reasons, shifts, and even the word down. Maintenance calls a machine down when it needs repair. Production calls it down when it can't produce. Finance calculates downtime only during planned production hours. Each view makes sense inside its own function, but when the factory wants a single decision process, those meanings need a shared definition. You don't have to force every system into exactly the same data structure that would create a massive migration project before anyone solves a real production issue. What you actually need is a shared model at the points where systems exchange information. For a machine event, define the canonical asset ID, who owns that ID, how a local source maps to it, and what happens when the mapping fails. Then do the same for the production order, operation material batch, and reason code the decision process needs.

36:54 It sounds basic because it is basic. And it's also the work team's skip when they want to move quickly into AI. They connect a co-pilot or a model to several data sources, ask it why line three stopped, and discover the source systems, don't agree on which line three they mean. The model can produce a fluent answer, but fluent isn't the same as correct. A shared data model needs ownership as well as naming. Maintenance should own the meaning of fault codes and maintenance status. Production should own execution status, and the rules for capturing reasons. Planning should own priority rules, approved routes, and the logic that decides which commitment takes precedence when capacity runs short. The data team can build the pipelines and controls, but it shouldn't quietly decide what priority customer means during a production disruption.

37:36 Now data quality rules become part of operations, not just a technical cleanup task. If a stop event has no valid asset mapping, it should fail the decision path clearly. If in order lacks an approved routing, the system should say that an alternate resource can't be assessed. If a quality hold hasn't reached the shared model, the plan recommendation shouldn't act as if released material exists. A missing fact needs a visible consequence, or the pipeline fills gaps with assumptions. And assumptions tend to become facts after they appear in a dashboard for long enough. There's a real difference between a semantic model for reporting and an operational context model for decisions. A reporting model helps people calculate and compare measures consistently, and that matters. You want OEE, scrap, output, and downtime to mean the same thing across reports, but a decision model goes further.

38:20 It needs to carry the current relationships and constraints that shape and action, that a machine belongs to align, that an operation needs a qualified resource, that a tool may be unavailable, and that a work order can't move until a quality release occurs. Reporting can tolerate data that arrives later, a production decision often can't, so treat the interfaces between OT, MES, ERP, APS, and Fabric as data contracts. A data contract states what each producer sends, what the fields mean, which values are allowed, how late data is handled, and who answers when the contract breaks. It gives each team a clear responsibility instead of leaving meaning to reverse engineering after an incident. This also helps when systems change.

39:00 A new machine gateway, MES upgrade, or planning tool, doesn't need to break every consumer if it still meets the agreed contract. The internal implementation can change, but the shared meaning stays stable. That gives AI something it can actually work with. AI can help people search event history, summarize maintenance notes, explain approved procedures, or surface patterns worth checking. But it needs trusted IDs, agreed definitions, source lineage, and stated limits before it earns a place in a production decision. Without that foundation, AI doesn't connect the dots between IT and OT. It just makes the confusion easier to ask questions about. A digital twin and knowledge graph, context that can be traversed. Once the shared model exists, you can start modeling relationships in a way that supports real decisions.

39:42 This is where people bring up digital twins and knowledge graphs. Both terms get used loosely, so let's keep them practical. A digital twin is an operational representation of a physical thing and its current state. In a factory that might be a machine, a line, a utility system, or a tool. It gives the wider architecture a way to refer to a real asset its properties and the state that changes over time. Four line three, the twin might hold the approved asset identity, the line it belongs to, its current production state, its known capability, and links to the systems that report on it. Live event data updates the state while engineering and master data provide the slower changing facts around it. That's useful, but it still leaves a broader question. What depends on line three? A knowledge graph helps with that, because it models connections between things.

40:24 Not just machines, but machines, products, routing steps, work orders, tools, people, maintenance tasks, and production rules. It lets the system follow a relationship instead of treating every record as an isolated row in a table, think through the line three event. The machine enters an unplanned stop. The model follows the link from that machine to the operation it can perform. From that operation it finds the active work order. From the work order it finds the product and remaining quantity. Then it follows the approved routing to other resources that may perform the same operation. That gives the decision processor path. It can ask whether another machine has the required capability. Check if that resource belongs to the same plant area, needs a different tool, or already has worker signed, and identify which later process depends on output from line three.

41:08 None of those questions require magic. They require relationships, somebody has modeled and kept current. The difference is easy to miss. A database table can tell you that machine M03 has status stopped. Another table can tell you work order 8472 is active. A graph lets you traverse the relationship between them, then continue through the process route, resource options, and the constraints attached to each option. That's how context becomes usable under time pressure. You don't need to build a complete virtual copy of the factory before this becomes useful. In fact, that ambition can stop the project before it starts. A perfect factory model is a nice idea for a conference slide. Production teams need help with a specific disruption next Tuesday, so start with the relationships needed for one decision. For an unplanned stop on a constrained resource, you may need only a limited model.

41:48 Acid to line, acid to operation, operation to product route, operation to qualified alternate resource, work order to current operation, and resource to tool requirement. That's enough to ask whether a disruption can move somewhere else without guessing. Add more relationships when they change the decision. If operator qualification changes, whether an alternate machine can run the job, model it. If a quality release blocks a material batch, link that condition to the work order. If a maintenance window rules out a resource, include it, but don't model every sensor, document, and engineering object just because the graph can store them, the model should earn its complexity. There's also a timing issue. A machine state can change every few seconds. Arruiting may change occasionally. A machine capability record might remain stable for months.

42:30 A good design keeps these types of information separate, then connects them when the decision needs both. Life state belongs in the event and operational data flow. Slow effects belong in managed master and engineering data. The relationship model gives you a way to bring them together without copying everything into one giant record that becomes stale almost immediately. That separation matters when someone challenges a recommendation. If the system points to an alternate resource, the planner should be able to trace the path. This machine stopped, which interrupted this operation, this routing permits these resources, this option needs this tool and this constraint prevents another option. The decision can then be reviewed by people who know the plant, rather than accepted because an algorithm produced a confident sentence.

43:10 A digital twin and knowledge graph don't replace the MS, ERP or APS. They give those systems a shared relationship layer where the factory can be understood as connected work, not disconnected records. And once you can traverse that context, downtime stops being only a duration on a machine. It becomes something you can relate to the work that production may now lose. From downtime to production impact. Here's a distinction a lot of manufacturers overlook. A machine stop has a duration and production impact has a consequence. They're connected, but they're not the same thing. Picture two identical faults on line three each lasting one hour during the first stop. The line is ahead of schedule. And the next process has enough semi-finished stock to keep running. In the second case, the line is already late. The downstream buffer is almost empty and the order still needs further processing before a fixed shipment cut off.

43:56 Same downtime, but the production problem is completely different. That's why alarm severity alone isn't enough to decide who needs to act. A severe alarm on an idle machine may need a maintenance response, but not the planner. While a moderate fault on the one resource that can complete a late priority order can become a planning issue very quickly. The system needs to calculate exposure. Start with the job in progress. How much did line three complete before the stop? How much remains? What rate could the resource normally achieve for that product under the current setup? Those facts let you estimate the output at risk if the machine stays unavailable. And that estimate should stay honest. It's not a promise. If the repair time remains unknown, the system can model a range. In the best case, line three returns within a short window and the current schedule absorbs the loss.

44:38 In the worst case, the repair runs longer, the queue grows, downstream work waits, and a delivery risk becomes more likely. The purpose is to give people a usable view of consequence while facts are still incomplete. Now follow the work through the process. A stopped machine can starve the next operation, but only when the downstream buffer can't cover the interruption. In some plants, a buffer carries several hours of work, while in others, a tightly coupled line can feel a disruption almost at once. You need the actual buffer state. Not the buffer that appears in a process document written before the last layout change. Upstream conditions matter too. If material continues to arrive at line three while the machine is down, the queue may reach a physical limit forcing an upstream line to slow down or stop. The original event happened on one asset, yet the impact can move through the value stream in both directions.

45:23 This is where the relationship model earns its place. It gives you a way to trace which operation supply line three, which consumes its output and which work orders compete for the same constrained resource. Without that context, downtime stays a local maintenance measure. With it, you can see the production exposure. OEE, overall equipment, effectiveness, adds another useful distinction. A stop only affects availability when it occurs during planned production time. If line three is deliberately off for a scheduled break, planned maintenance, or a change over that belongs in the plan, counting that as an unplanned availability loss distorts the number. The reason code and production calendar both matter, even then, OEE explains only part of the situation. A line can lose availability and still protect customer delivery because there is buffer or spare capacity.

46:09 While another line can show a modest availability loss and create a serious delivery risk because it sits at the bottleneck. OEE helps you measure equipment loss. Production impact tells you what that loss does to the work, keep those measures separate, then connect them. The line may also run behind plan before anything fails. In that case, the same downtime carries more risk because there's no recovery margin left, while on the other hand, production may be ahead or the order may have a later due date, giving the team room to repair before changing the schedule. This is why escalation should follow consequence, not just alarm class. A useful assessment might say, line three remains stopped during active production. The current order has work remaining and the downstream buffer covers the next process for a limited period.

46:50 Based on the present schedule, the disruption may affect the delivery window unless recovery begins within a defined time. That is a very different message from machine alarm active. That kind of message gives maintenance a reason to state a repair estimate, the supervisor a view of flow risk, and the planner a defined point where a schedule review becomes justified. And it keeps the response proportional. Not every fault needs an emergency meeting, a revised plan and 15 notifications. But when the event changes the consequence for production, the next question becomes clear, what sort of decision should this trigger? Decision types, alert, guidance, plan change, or control. Once you know the likely production impact, don't treat every response the same way. A machine event can trigger an alert.

47:32 It can provide guidance, it can start a plan review. In a narrow set of cases, it can support a local control action. Those are different decisions with different owners, time limits, and risks. An alert is the simplest form. It tells a named person that a defined condition exists. But a useful alert also states why that person owns it and what they need to check first. For line three, a maintenance alert might tell the technician that the machine entered an unplanned stop-state during active production, that the stop remains open, and that the current order may face a delivery risk if the condition continues. The technician still diagnoses the fault. The system hasn't diagnosed a failed component just because it received an alarm code. Ownership matters. If the alert reaches everyone, it reaches nobody.

48:14 A maintenance fault should go first to the people responsible for recovery. A production escalation should reach the supervisor when flow risk crosses an agreed threshold. The planar needs involvement only when the disruption threatens the current plan or requires a decision about competing orders. Guidance is the next level. Guidance helps a person assess the situation using approved knowledge and current context. It might present the relevant fault procedure, show prior incidents with the same fault code, or list the standard checks that maintenance should perform before restarting the resource. For a production supervisor, Guidance may point out that the downstream buffer will run out before the next scheduled break based on current execution data. That doesn't come under response. It gives the supervisor facts that support a response. The source of that guidance needs to remain clear.

48:56 If it comes from an approved maintenance procedure, state that if it comes from event history, say it's a pattern, not a confirmed cause. If the system lacks a current repair estimate, it should say so. A vague recommendation with no source is hard to trust when people are standing beside a stopped machine. A plan change is different again. At this point, the event has moved beyond local recovery. The question becomes whether production should re-root work, re-sequence orders, add capacity, protect a priority commitment, or accept a change delivery date. That decision affects more than line three. It can shift pressure onto another line, consume a shared tool, or delay another order that also matters. That needs a planning process. The pipeline can trigger that process when defined conditions occur.

49:36 For example, line three remains unavailable beyond the recovery margin for the active order, or maintenance estimates that repair will run into the next shift, or the downstream buffer reaches a level where the next operation will soon stop. Those conditions should be agreed in advance. Nobody wants a planning escalation every time a sensor loses contact for a few seconds. The planner then needs options, not just a warning. What work can move, which resource can perform it? What does the move display? What material, tooling, and labor limits apply? What happens to delivery dates if no alternate path exists? That's where a plan change earns a human approval step. A production planner may approve a re-sequence order, a customer service or commercial owner may need to approve a changed promise date. A supervisor may approve over time within local rules.

50:17 The pipeline can prepare the context and track the decision, but authority should stay with the people accountable for the consequence. Control action sits in a separate category. A local automation response can make sense where the response is already approved, safe, deterministic, and owned by the control system. A machine might stop feeding material when a downstream sensor confirms a blockage. A system might place a process into a safe state when a measured condition exceeds its approved limit. Those actions belong close to the process. They should not depend on a remote analytic service, a dashboard refresh, or an AI-generated instruction. Physical control has safety, validation, and availability requirements that differ from production coordination. The controller and the approved local logic remain responsible. Fabric can still support the wider response.

50:59 It can record the event, inform the right people, connect the event to production context and start the workflow that follows. But it shouldn't become a remote hand on the machine. So think about the decision path in layers. First, notify the person who can assess the immediate condition, then provide guidance grounded in approved information, escalate to planning when the production consequence needs a plan change. Keep automatic control local, bounded, and independently safe. That separation keeps automation useful without handing it authority it hasn't earned. It also exposes a question that comes up quickly once teams add co-pilot to the discussion. Can generative AI help explain the disruption and can it decide the revised production schedule? Those are very different jobs. Co-pilot can explain, but it should not invent a schedule. Let's separate two things that get mixed up way too often.

51:42 Generative AI and actual production optimization. A co-pilot can help people understand a disruption by answering questions in plain language, summarizing the event sequence, pulling together approved maintenance instructions and drafting a useful handover note for the next shift. That saves time when the facts already exist across several systems, but it doesn't turn a language model into a production scheduler. Imagine the planner asks what the line three stop effects. A well-connected co-pilot could retrieve the active order describe the current machine state, identify the downstream operation and point to approved alternate routes from trusted source data while also flagging where information is missing like an unconfirmed repair estimate or an unavailable tool status. That's useful support for a human decision.

52:23 It can also help during a handover by preparing a short account of the incident instead of someone scrolling through alarm logs, MES notes, emails and a maintenance case. It can say when the stop began, which checks maintenance recorded, what order remained in process, and which questions still need a planner or supervisor to answer? The wording sounds simple, but the information chain behind it isn't. Co-pilot needs controlled access to trusted context. It needs to know which source owns the event, which record represents the current work order, which routing version is approved, and whether a maintenance note is a confirmed finding or an early observation. It also needs source lineage, so the user can trace an answer back to the records that support it. In practical terms, that means you have to govern what co-pilot can see and how it connects data.

53:05 Without that, it can produce a smooth explanation from incomplete or conflicting data. On a factory floor, smooth language creates a false sense of certainty. A system that says, "Move the order to line two sounds helpful." But it may not know that line two lacks the required fixture, that material hasn't cleared quality release, or that moving the order delays a higher priority job. The sentence is easy, but the consequence isn't. Production scheduling depends on constraints, and some of those are hard rules. An operation can only run on approved resources. A product may require a qualified operator. A tool may only exist once in the plant, and a maintenance window can remove capacity. Material must exist, be released, and reach the right resource, other constraints involve policy and judgment, which customer order should get the remaining capacity.

53:49 Is overtime okay? Can a delivery promise change? Would a supervisor accept a less efficient sequence to protect a more urgent order? A generative AI model doesn't calculate a feasible plan just by describing those constraints well. A planning engine, a constraint solver, or defined business rules can test possible schedules against explicit limits. It can reject an option because the resource isn't qualified, the setup sequence violates a rule, or the material arrives too late. That kind of logic needs deterministic inputs and repeatable rules. Generative AI has a different role. It can help people ask the right questions and translate a planning result into plain language. It can explain why an option failed when the optimization system returns the stated constraint, retrieve the procedure for a permitted workaround and prepare a decision record for review.

54:31 But it should not invent a schedule from a prompt. Even a good optimization result needs a human who understands the current plan conditions because data can lag. An operator may know that a machine is technically available but not ready for a difficult product. And a planner may know a customer commitment that hasn't reached the system yet. Those facts don't make systems useless. They show why decision authority needs clear boundaries. The more physical the consequence, the more careful the architecture needs to be. A wrong summary can waste a few minutes, but a wrong schedule can create scrap, disrupt a setup, consume scarce capacity, and damage customer trust? That's why I would give co-pilot access through governed data products and specific tools rather than broad access to every planned record it can find. Let it explain the situation, retrieve approved knowledge, and help people document and challenge a recommendation.

55:14 Then send the actual rescheduling problem to the system, build to test, what the factory can really do. APS, where a machine event becomes a feasible alternative. This is where an advanced planning and scheduling system, APS for short, earns its place. An APS system takes the disruption and tests possible production responses against the constraints that apply right now. It doesn't just tell you that line three stopped. It asks what work can still be completed on which resource in what sequence with which trade-offs. That's a different job from ERP. ERP knows demand, orders, inventory, planned dates, and the commercial record-around production. It records what the business intends to make and what transactions have taken place, but an ERP production plan often doesn't test every live shop floor constraint after a disruption.

55:56 APS is built to test feasibility. Take the line three stop. The event to decision pipeline passes the planning system a disruption with enough context to be useful. The affected resource, the operation underway, the work remaining, the current schedule position, and maybe an initial repair estimate. The APS engine then evaluates the production model, can the active operation move to another approved resource? If it can, does that resource have open capacity before the due date, what setup would the move require? Would using that capacity delay another order? Is the needed tool already committed somewhere else? Does the material arrive at the new resource in time? A planner may know many of these answers from experience, but the value of APS isn't that it replaces that experience. It lets the planner test the consequences across the full schedule without doing the whole calculation manually while the production clock keeps moving.

56:42 Suppose there are two alternatives. The first option moves the interrupted order to line two. That protects the due date for the current order, but pushes a lower priority order into the next shift. The second option keeps the order on line three. Assumes a repair within a given window and rearranges the sequence around it, creating less setup work, but leaving less margin if the repair takes longer than expected. Neither option is simply right. The APS system can return both options with the assumptions behind them, showing which orders move, which resources take extra load, which constraints bind, and where delivery risk remains. The planner then reviews the result against facts the model may not yet know, such as a customer conversation, an operator concern, or a temporary issue, on another line? That's planning support with accountability still in the right place.

57:25 Over time can enter the same assessment and so can subcontracting if the product, quality rules, and commercial process permitted. A planner may decide to protect one customer order by delaying another, but that decision should be visible as a choice with a stated consequence, not as an accidental result of someone changing a date in the spreadsheet. The system should also show when there is no feasible alternative. That answer can be more useful than a weak recommendation. If every approved resource lacks capacity, the required tooling is unavailable, and the due date can't hold under the stated repair window, the pipeline should say so clearly. It gives the team a reason to escalate early, rather than discovering the problem after the promise has already failed. Keep the inputs honest. An APS result can only test the data and rules it receives.

58:06 If resource capability data is out of date, actual production status lags behind the shop floor, or material availability only exists in a planning record, the result may look feasible without being executable. The system should expose those assumptions for the planner to check. That's why the result needs more than a proposed date. It should return the recommended alternative, the constraints considered, the assumptions still open, and the expected effect on the affected orders. The planner can then accept it, reject it, or ask for another scenario. In practical terms, APS turns a machine event into a set of tested options, instead of a rush of phone calls and best guesses. Once a planner approves an option, the job changes again, because the decision now needs to reach the systems and people that run the work, with a record of why that change happened.

58:46 A machine stops mid-production order. The PLC flags a fault, and alarm pops, and the machine state flips from running to stopped. That event lands in your data platform with a timestamp, an asset name, and maybe an alarm code. Meanwhile, production time keeps slipping away. The MES might now show the machine is unavailable. The ERP plan still expects the order to finish on schedule. The planner may not even know yet, or they know, but can't tell if it changes anything beyond that one machine. That's the gap right there. But we talk about real-time data like receiving a signal equals acting on it. It doesn't. A live alarm only says something happened. It won't tell you which production promise is now at risk, whether another resource can pick up the work, or if maintenance should act before planning reshuffles the sequence. So the factory has real-time data but no real-time decision.

59:28 And that happens more than most people want to admit. Teams build an IoT pipeline, stream-tag data to the cloud, create a clean power BI report, and then wait for someone to notice it. Apparently the last step in too many industrial architectures is still, can someone call the planner? This episode follows the missing path between that machine event and a changed production decision. Not the data platform by itself, not a dashboard, the whole path, from a fault at the machine to a response that actually changes what the factory does next. Let's make that concrete. A factory scenario. Line three stops. Picture a plant with several production lines feeding a shared downstream process. Line three has a machine that nobody calls a bottleneck in the morning meeting. Mostly because everyone already knows it is one, it performs a process that only two machines in the plant can handle.

1:00:11 And the second one has its own schedule. Line three is running an active production order. Material is already at the line. The operator has started the batch. Downstream another area expects parts from that order later in the shift than the machine stops. The control system raises a fault code. Maybe it's a drive issue. Maybe a sensor reports a condition outside its normal range. At this point nobody should pretend they know the cause. The only confirmed fact is simple. The machine changed state and the order can't continue on that resource right now. For the operator, the question is immediate. Can I clear the fault safely and restart? For maintenance, the question shifts. Is this a quick reset and known recurring fault or something that needs inspection before anyone runs the machine again? For the production supervisor, the question is about flow.

1:00:52 How long can the downstream process keep going before it runs out of work? And for the planner, the question is wider and usually arrives too late. Which customer order is sitting on line three? How much is left to produce and can the remaining work move without causing a bigger problem somewhere else? Those aren't the same question. A machine clock starts the second line three stops. It measures lost runtime, alarm duration, and maybe the time until an operator acknowledges the fault that clock matters. Especially for maintenance and OEE. The planning runs on a different clock. Planning cares about the point where a machine stop starts affecting the sequence of work, available capacity, promised shipments, material use, labor cover, and the work waiting behind that order.

1:01:32 A 10-minute stop might have no planning impact if the line is ahead in this buffer downstream. The same 10-minute stop can create a serious problem if the machine was already behind. The order has a fixed shipment date and the alternate machine needs a different tool. That's why alarm severity alone doesn't tell you what to do. Let's stay with line three. The fault happens at 10 past 11. The MS knows which work order is active and how many units the line completed. The ERP knows the customer demand, the due date, and the material position. A maintenance system may know the machine has an open work request from last week. A scheduling tool, if one exists and holds trusted data, may know which alternative resource can run the same routing step yet each system sees only part of the situation. The operator sees a stopped line, maintenance sees a fault and an asset, the planner sees an order and a schedule.

1:02:15 Customer service may see a promised date, none of them on their own sees the consequence chain. The line stopped. That affects the active operation. The operation belongs to a work order that work order supports a customer commitment. Moving it may consume capacity on another machine that may delay a different order which may create a new issue somewhere else. This is where people often reach for a dashboard. A dashboard can show that line three stopped. It can show the alarm code, duration, and current output. Those are useful facts, but the planner still needs an answer. Can the order move to line five? Does line five have the approved tooling? Is the material available at line five or does it sit at line three? Does the alternate route require a qualified operator? We're moving the order interrupt a higher priority job already in progress.

1:02:56 If nobody can answer those questions fast, the machine event becomes another manual investigation. And the investigation happens under pressure. A supervisor calls maintenance. Maintenance checks the machine. The planner opens the planning board then exports something to excel because the planning board doesn't show the latest execution status. Someone checks material in ERP. Another person asks whether the downstream area can switch to another product. By the time the team has formed a view, the fault may already be cleared, or the missed decision window may be gone. That doesn't mean people are doing poor work. It means the systems haven't connected the event to the decision. Now think about a slightly different outcome. The line three event reaches a process that can identify the active order, read current production state, check the affected routing step, and assess alternate capacity under the rules your plant already uses.

1:03:40 The system doesn't automatically rewrite the production plan. It gives the responsible person a clear time bound choice with the facts behind it. That is a very different use of machine data. The fault still needs maintenance attention. The operator still owns a safe restart. The planner still owns the production decision. But nobody starts from a blank page while the clock is running. And that brings us to a key distinction. An alert can detect a problem, but detection alone can't answer an operational question. An event is a fact, not a decision. A machine event is a fact recorded at a single point in time. It might carry a timestamp, a tag name, a measured value, an alarm code, and an asset ID. If the source is clean, you also get the controller that sent it, signal quality, and a sequence number.

1:04:21 That data tells you a state change. For example, a line went from running to stop at 11.10, a drive fault appeared, and the controller reported an alarm. That is useful. It gives maintenance a starting point and operations a reliable record of when the disruption began. But it does not contain a decision. A decision means choosing a response while working inside real factory limits. Limited machine time, approved routes, tools, people, materials, quality rules, maintenance work, and customer commitments. Sometimes the best response is to wait, sometimes to move work, sometimes to protect a higher priority order and accept that another order slips. The event can't choose between those options by itself. This sounds obvious, but a lot of industrial data projects blur the two.

1:05:01 The system detects a problem, sends a notification, and everyone calls it decision intelligence. That is usually just faster awareness. Awareness helps, but it isn't the finish line. Here's the chain is five different jobs. First, you detect that something changed. Then you explain what that change means in the current production situation. After that, you recommend possible responses, a person with the right authority approves one of them. Finally, the factory executes that approved response. Through a schedule update, a maintenance task, or a controlled local action. Each job needs different information. Detection needs a trustworthy signal, explanation needs operational context, recommendation depends on rules and constraints, approval needs ownership and accountability, and execution needs an integration path into the system that controls the work.

1:05:43 If you skip the middle steps, you end up with the usual pattern, a red alarm, a team's message, and a person still trying to piece together the situation from three systems and an old spreadsheet. That is not a failure of the people receiving the alert. They are doing the reasoning, the architecture never captured. Dashboards can make this problem look better than it is. You build a live view of machine states, downtime speed loss and alarms, refresh it every few seconds, and the report looks convincing in a meeting room. Then somebody asks a simple production question, what should we change now? If the answer requires a call to planning, a check with maintenance, a search through ERP, and a manual comparison of capacity, the dashboard delivered visibility without changing the work. There is an important difference between seeing a fact and acting on its consequence.

1:06:26 This also changes how I think about the value of telemetry. A temperature reading, a fault code, or a machine stop does not create value just because it entered a cloud platform. It creates value when it changes a named decision in time for that decision to matter. Maybe the decision is small. A maintenance lead receives a fault with the right asset, current state, and a clear owner shortening the time to find the problem. Maybe it is larger. A planner gets a disruption assessment showing which order is affected, how long the current buffer will last, and which approved alternatives deserve review. Both are valid, just different decision types. And we should be careful not to force full automation where it does not belong. A fault signal might trigger a notification automatically, create a draft maintenance request, or start a structured assessment.

1:07:10 But changing a production sequence can affect delivery promises, material flow, quality release, and work already underway. In most plants, someone should own that call. The system should reduce the time and uncertainty around the call, not pretend that production planning is a chat response generated from a fault code. So when you design an event pipeline do not start with how do we stream every machine signal. Start with a harder question. Which decision should this event change, who owns it, and what information do they need before they connect? That question exposes the missing part of most events streams. The raw event does not know the work order, the route, the available alternatives, or the cost of choosing one response over another. It only knows that something changed. What the event does not know, take that line three stop event on its own, it tells you the asset identifier, the moment the state changed, and the fault code from the controller.

1:07:55 But it does not know which work order sits on that machine, unless another system links that work order to the event at that exact point in time. That link sounds simple, it rarely is. The MS may record the active order, but the operator might have started the physical setup before confirming the order in the MS. Or the machine completed one batch and waits for a release before the next one begins. A raw event cannot tell the difference. It only reports what the controller sees. The event also does not know the routing step, which product variant is running, whether that product can run on another machine, or whether the customer order has a priority that overrides the normal sequence. Those details live in master data, scheduling rules, and the people who understand the current state of production. Context changes the meaning of the same fault.

1:08:37 Imagine line three stops while running a standard product that can move to another qualified resource, that is one type of disruption. Now picture the same stop during a regulated product run, where the equipment setup, quality checks, and validated route limit every alternative. The alarm code might be identical, but the production consequence is not. There are other missing links as well. A machine event won't tell you whether the required tool is installed on an alternate resource, whether a skilled operator is available on the next shift, whether material has cleared quality inspection, or whether a maintenance technician already works on a higher risk failure nearby. Those are constraints that decide whether a proposed response can actually happen. This is where teams often hit a less visible problem, identity. The PLC may call the machine M03, the MES calls it Lion3Press 01.

1:09:23 ERP refers to the resource as WC340, and someone added Press line 3 to a spreadsheet because that is what people on the floor call it. All four names may refer to the same physical asset, but an automated join cannot rely on people knowing that. It needs an agreed identity. Without that, the stream can contain perfect data and still connect to the wrong order, the wrong maintenance record, or no record at all. That is not a streaming problem. It is a data ownership problem, the stream exposes very quickly. Even the word stopped needs more care than most models give it. A stopped state might mean a confirmed equipment fault, planned cleaning between batches, the machine blocked because the downstream conveyor cannot accept parts or the operator paused for a quality check. From the controller's point of view, all of those look like zero production.

1:10:06 A maintenance team needs different responses for each one. A planner sees very different time risk, and finance should not treat them all as the same downtime loss. So the event needs a business meaning, not just a technical label. That meaning can come from a reason code, a production state from MES and operator input, or a rule combining signals over time. You do not need to invent certainty where the plant has none. A good event can state that the reason remains unknown while still marking the disruption as needing review. That is far safer than quietly classifying every stop as a fault, because the data model only has one field. Before you automate a response, you need a shared model of what the event refers to and what it means. Not a huge enterprise model describing every bold document and conversation.

1:10:48 Start with the links required for the decision you are trying to improve. For line three, that may mean a clear relationship between the asset, its production line, the current operation, the active work order, the product, the approved alternate resources, and the current schedule. Add tool status, material release, or maintenance state only, where those facts change the available response. That creates a usable chain from the physical signal to the operational question, and it keeps each system honest. The controller knows what happened at the machine. The MES knows what production is executing ERP knows demand and commitments. Planning tools know what capacity might remain. Trying to force one system to pretend it knows everything usually creates a very expensive version of confusion. So before we connect more data, we need to separate the jobs these systems already do.

1:11:30 ERP, MES, and the shop floor, different jobs. People get confused when they expect one system to answer every question in the factory. It doesn't work that way. ERP handles the business side of production. Demand, sales orders, purchase orders, inventory records, costing, and commercial commitments live there. The system knows a customer expects a shipment. It might hold a planned order with a due date. It records transactions that matter to the business. But ERP usually doesn't see a machine fault as it happens. That isn't a weakness. ERP was never meant to act like a control system. If you force it into that role, you end up with a slow, brittle version of shop floor visibility. Then you wonder why planners keep using their own tools. The manufacturing execution system, MES, sits much closer to the work.

1:12:13 It tracks what production is doing right now, or at least what production has confirmed through scans, terminals, machine links, and operator input. The MES can hold the active operation, produced quantity, scrap, batch genealogy, quality status, and job progress. For that line three scenario, the MES should be one of the first places you ask. What work is actually underway? That word actually matters. The ERP plan states what should run? The MES should tell you what production is executing. Those records can differ for perfectly normal reasons. An operator starts late. A sequence changes because material didn't arrive. A quality hold stops the next batch. The physical factory moves faster than a plan can stay perfectly current. Then you have the OT layer, operational technology.

1:12:53 This includes the controls, programmable logic controllers, drives, sensors, supervisory systems, and the networks that support them. OT knows physical state, it sees a motor trip, it sees speed drop, it sees a safety interlock, a temperature value, a cycle count, or a conveyor blocked signal. And it can control real equipment, that last point sets a hard boundary. The controller must keep its local job even if a cloud link disappears, a business system runs slowly, or somebody changes a report definition. Production doesn't pause because an analytics platform needs maintenance. Safety certainly doesn't wait for a round trip through the cloud. A planning system has another job entirely. Advanced planning and scheduling, often called APS, evaluates capacity, sequence, constraints, and alternatives.

1:13:34 Depending on its setup, it can test whether another machine can run an operation, whether moving work creates a clash, or whether a different sequence protects a higher priority order. It takes the planned world and asks what remains feasible when conditions change. That doesn't mean every manufacturer needs an APS tool for every scheduling decision. Some plants schedule well through experience, planners, rules, and local knowledge. But when the decision involves many linked constraints, a planning engine can assess alternatives faster, and more consistently, than a person trying to rebuild the whole situation in their head. Each system owns a different kind of truth. ERP owns commercial demand and the formal business record, MES owns production, execution, and traceability. OT owns machine signals and local control.

1:14:16 APS owns the calculation of feasible plan changes if it exists, and if its data is current enough to trust. The trouble starts when the handoffs between those truths get vague. A planner assumes an MES completion means the order is ready for the next operation, but quality still holds the batch. Maintenance sees an asset as available because the fault cleared, while the supervisor hasn't released it for production. ERP shows material on hand, although it sits in a location that can't feed the alternate line in time. None of those systems is necessarily wrong. They answer different questions at different levels, with different timing and ownership, the architecture needs to preserve those differences, then connect them where a decision requires more than one view. Trying to flatten everything into one giant table usually removes the detail that operations need most.

1:14:58 So who owns the decision when line three stops? Usually nobody owns all of it. The operator owns safe local response, maintenance, owns technical assessment, and repair. The supervisor owns the immediate flow decision. Planning owns changes that affect the wider schedule, customer service may need to own the conversation if a delivery promise changes. That is why a machine event cannot simply flow into one system and come back as a universal answer. You need a decision path with clear roles. The system can gather facts from ERP, MES, OT, and planning. It can put those facts in front of the person who has the right authority. But the authority still belongs to the business process, not to the event stream, and because those roles cross-system boundaries, people still build their own handoffs between them. Or close the loop without pretending it is fully automatic.

1:15:40 So the planner approves a new production option. That decision now has to leave the planning view and become actual work that people and systems can carry out. Sounds obvious, but this is exactly where most real-time projects stall out. The system detects the event, assesses the impact, generates a recommendation, maybe even gets approval. Then what? Someone still sends an email, updates a spreadsheet, and calls the supervisor. The decision exists, but the factory hasn't changed. The first question is simple. What does approval actually create? For the line three disruption, approval could create a dispatch change for an alternate resource, generate a maintenance task with an agreed priority, send an escalation to a production manager if no feasible recovery plan exists, or kick off a controlled request to review a customer promised date.

1:16:22 Each outcome belongs in the system that owns that type of work, and that's where the integration design gets specific. If the approved choice changes the next job on a machine, your MES will need a revised dispatch instruction. But that doesn't mean fabric should directly rewrite the MES every time a streaming condition pops up. The write-back path needs clear rules, validation, and an agreed integration contract. For example, the MES may accept only a schedule revision that comes from an approved planning process. It may reject a change if the operation already started if material hasn't been issued, or if a required electronic record is open. Those checks protect execution. They aren't friction for the sake of friction. The same principle applies to ERP, an ERP system might need an updated planned date an exception record or a change material commitment.

1:17:03 But here's the catch. A delivery date affects commercial obligations. You really don't want a machine stop event quietly changing a promise to a customer because an automated workflow inferred that capacity looked tight. Someone with the right authority needs to own that step. This is where Power Platform can fit well, particularly for the work between systems and people. A workflow can send the right decision package to the planner, production lead, maintenance coordinator, or commercial owner. It can collect approvals, record comments, create tasks, and notify the people affected by the decision. And that matters because the disruption rarely stays inside one department. The planner approves a revised sequence. Maintenance confirms a repair estimate. The supervisor prepares an alternate resource. Customer service reviews the impact on a shipment. A tracked workflow gives those people one shared case rather than a chain of messages where nobody can tell which answer is current.

1:17:48 Keep the workflow focused on exceptions. You don't need to turn every normal MES transaction into a Power Automate Flow. The better use case is the disruption that crosses system and team boundaries, where the factory needs a visible decision, a named owner, and a record of what changed. That record matters more than teams first expect. For each material decision, you want to keep the source event that started the process, the context snapshot used during the assessment, the options considered, the chosen action, the approver, and the time when execution changed. That way, if the plan later fails, you can review what the system knew at that moment instead of judging the decision with facts that only appeared later. That's how you learn without blaming people for not predicting the future. A context snapshot is especially useful because production data moves constantly.

1:18:31 The active order can change. A machine can restart. Material can be released or put on hold. If you only keep the life current state, the evidence behind an earlier decision disappears, you need to preserve the decision time picture. You also need a response when the write-back fails. Maybe the MES rejects a dispatch change because the resource entered a locked state or the ERP update can't post because a planning version changed. The workflow shouldn't close the case and assume success just because it's sent a request. It needs confirmation from the receiving system. That confirmation can update the decision record, approved, sent, accepted, executed, or failed and returned for review. Those states sound administrative, but they tell you whether the pipeline actually changed work on the factory floor.

1:19:11 The goal isn't full automation. It's a controlled loop where the event starts a decision process. That decision reaches the write operational system and the outcome comes back as evidence. Fabric can connect the live data and the action path, but the people who own production, maintenance and commercial commitment still decide where authority belongs. Fabric activator, detect conditions and trigger the right work. At this point, the loop has an event, context, an approved path and a way to send that path into the systems that run production. Fabric activator fits earlier in that flow, where a defined condition needs to trigger the right piece of work. Activator watches event data and responds when a condition you define becomes true. It can watch a live stream, a real-time dashboard, or a KQL query result, then trigger a notification or start a connected action.

1:19:55 Sounds simple, but the condition design is where the real work sits. For line three, you might define a condition that only matters when an unplanned stop remains active beyond an agreed period during scheduled production. Then the condition checks whether the resource supports a live order and whether the stop has an impact level that needs attention. A raw fault code alone may not deserve an escalation. The same pattern works for repeated faults. One isolated alarm may lead to a normal technician response, but five similar stops in one shift may point to a recurring issue. In that case, activator can create a maintenance review or notify the responsible engineer with the fault history attached. Quality conditions follow the same approach. A single rejected part may fall within normal variation, but a rising reject pattern on one product and one resource may need a quality check before the next batch moves downstream.

1:20:41 The action should match the condition. Activator can notify a named owner, create a tracked workflow, or trigger a process in the wider Microsoft environment. That brings a person into the decision flow while the event still has operational meaning. It can also start a fabric item if that's the agreed technical response, but keep the boundary clear. Activator should not send uncontrolled commands to a machine just because a cloud side condition fired. A prolonged stop may justify a maintenance escalation and a temperature threshold may justify a call to the right person, but neither automatically gives a streaming platform authority to change a PLC program or restart a resource. The factory already has local control logic for a reason. A useful condition also needs protection against noise. Industrial data can fluctuate, networks can reconnect and replay messages, and a sensor can report a brief bad value.

1:21:26 If every single blip starts a workflow, people will learn to ignore it pretty quickly. That's alert fatigue, and it's surprisingly effective at turning a well-funded data project into background noise. Use debounce logic. In plain terms, require a condition to persist for a defined time before treating it as real. If line of three reports stopped for a few seconds and then returns to normal, the system records the event but avoids waking half the plant. Use suppression rules too. If an incident case already exists for the active stop, don't create another one every minute. Add new information to the existing case. And if plan maintenance has placed the machine into an approved maintenance state, suppress the production escalation that would normally follow from the stop signal. Priority needs context, not just aesthetic alarm grade.

1:22:08 A fault on a bottleneck resource during active work may deserve an urgent route, while the same fault on a resource without scheduled work may create a normal maintenance task. Activator can start different actions when the rules can see the production and time context around the event. Shift context changes the response to. During an overnight shift, the right action may notify the uncool maintenance role and log a case for the morning planner. During normal planning hours, the same condition may bring maintenance, production and planning into a shared workflow at once. The escalation path should reflect how the plant actually runs, not how an org chart looks on paper. Build those rules with the people who actually receive the work. Ask the technician which repeat fault pattern deserves escalation. Ask the supervisor which stop duration starts to threaten flow, ask the planner when a disruption needs a schedule review.

1:22:53 Then encode those agreed decisions as conditions that can be tested and changed with proper control. Fabric activator can turn real-time observation into a timely handoff, but it doesn't decide whether the handoff actually helped. That needs a closer look at the quality of the decision and the outcome that followed. Measure decision quality, not dashboard activity. Here's the part most people skip once activator fires off the right workflow. You have to ask an uncomfortable question. Did that workflow actually lead to a better production decision or did it just create more activity around the event? A busy dashboard won't answer that. Neither will a high count of alerts, cases, or completed workflows because you can generate hundreds of notifications and still leave planners waiting for the information they actually need. In fact, a rising alert count often means the system is getting worse at helping people focus not better.

1:23:37 Measure the path from event to action instead. Start with the time from the machine event to awareness. When did the condition actually occur and when did the right owner receive enough context to know they owned it? That's different from the time a raw message entered a stream. Data can arrive quickly while the useful alerts still reaches the wrong team or lacks the detail needed to act. Now measure assessment time. How long did it take to figure out whether the event affected active production, a current work order, or a delivery commitment? If this takes too long, look at the context join. Maybe the machine to order link is stale. Maybe the current EMEA status arrives late or maybe the planner still has to call the shop floor because the pipeline can't tell whether the order had actually started. That tells you exactly where the delay lives. Approval time comes next in the chain. A plan change might need a production planner, a supervisor, a maintenance lead, or someone responsible for a customer commitment.

1:24:22 If a decision sits for hours because nobody knows who can approve it, that's not a streaming problem. That's a decision ownership problem. Finally, measure execution time. A recommendation can be accepted while the factory continues with the old plan. Track when the approved action reached the receiving system, when that system accepted it and when the work actually changed on the floor. If the dispatch update fails or the alternate machine never starts the reassigned operation, the decision loop stays open. Those timestamps give you a more honest picture than any dashboard refresh rate. You should also compare predicted impact with the production outcome. Suppose the pipeline estimated that a line three stop would starve the next operation before the end of the shift. Did that happen? If not, why?

1:25:02 Maybe the buffer record was wrong or the machine recovered faster than expected, or the supervisor found a local workaround that the model never knew about. Each gap teaches you something. The assessment may be too cautious, too optimistic, or based on facts that arrive late. You don't fix that by forcing the model to sound more certain. You fix it by reviewing the assumptions and improving the facts, rules, or relationships that shape the assessment. People often want to measure avoided disruption. That can be useful, but it needs care. You can't simply claim that every alert prevented a late delivery or every workflow saved downtime. Production changes for many reasons. A repair may succeed quickly, demand may shift, or a downstream buffer may have covered the loss anyway. If you want to estimate a voided impact, define the baseline and state the assumptions clearly.

1:25:45 Otherwise, every alarm becomes a success story after the fact, which is a strangely popular reporting method. System health belongs in the same review, track false alerts, missed events, stale context, and failed integrations. A false alert sends people scrambling unnecessarily. A missed event can leave a real disruption without the support it needed. Stale context may produce a recommendation based on yesterday's schedule. A failed integration can leave an approved action trapped in the workflow. These aren't minor technical details. They affect trust, review decisions by loss category, and by the constraint that blocked recovery. You may find that repeated machine stops aren't the main cause of delayed decisions. The real issue could be missing tool status, poor reason codes, unclear priority rules, or a resource capability list.

1:26:25 Nobody has updated in years. That gives improvement work a target. The aim isn't to prove that fabric or any dashboard sees more data. It's to shorten the time between a meaningful event and a sound, traceable production response, while learning when the pipeline gave people the wrong picture. Trust, security, and data ownership. A decision pipeline only works when people trust both the data and the boundaries around it. In a factory, that starts with a simple rule. Safety and machine availability come before any cloud architecture choice. The OT environment controls physical equipment. It has its own safety logic, network zones, change process, and response times. A data platform can observe and coordinate around production, but it shouldn't become a hidden route into a controller or a shortcut around established plant controls.

1:27:07 Keep the paths separate. One path carries approved operational data out of the plant. Another path may carry approved business actions back into systems like MS or ERP. Neither path should give a reporting user, an AI assistant, or a workflow account brought access to machine control functions just because the system's sit in the same wider solution. Identity is part of that design. Microsoft Enter ID can help manage who or what accesses cloud resources, but the architecture still needs clear roles. A planter may read production impact and approve a schedule option, a maintenance coordinator may update repair status. A workflow service account may submit an approved request to MS. Those are different permissions, and they should stay different. Give people the least access they need for the job.

1:27:49 That applies to service accounts as much as users. A data pipeline that only reads machine events shouldn't also have permission to update ERP orders. A workflow that sends a notification doesn't need rights to change a routing. When one identity can read everything and change everything you haven't simplified integration, you've created a very efficient future incident report. Access also needs traceability. For a production decision, you should be able to answer who viewed the information, who approved the action, which system account performed the right back, and whether the receiving system accepted it. That record helps during an audit, but it also helps the plan team understand why a decision path behaved differently during a real disruption. Data governance has a role here, though the word can sound far removed from a stock machine. In practical terms, governance means people can find a data product, understand what it represents, see where it came from, and know who owns it.

1:28:36 Microsoft Perview can support cataloging, classification, lineage, and policy across a wider data estate, but it doesn't decide what a fault code means or which order should win when capacity is short. People still own those decisions. Maintenance owns the meaning and use of fault codes, production owns execution states and the rules around operator-reason capture, planning owns priority logic, routing assumptions, and escalation thresholds.