UMDA Applied

Patterns, Not Projects

This paper is a pattern catalog of seven concrete applications of the Unified Manufacturing Data Architecture, each engineered on the same foundation and presented in the same shape. It is deliberately not a collection of case studies. A case study tells you what happened to someone else; a pattern tells you what to build, what it stands on, where it goes wrong, and what it returns, in a form you can apply to your own plant.

Every pattern is presented through the same six-part template. It opens with the business problem, stated in outcome terms, and a one-paragraph summary of what gets built. The data path then walks from signal to decision through the architecture's layers, and it is always told in the same order, so that by the third pattern the structure is familiar and by the fifth a reader could sketch a new pattern unaided, which is the skill this paper is actually trying to teach. Three shorter sections close each pattern: what it stands on gives the honest prerequisites, where teams go wrong names the pattern-specific failure modes, and what it returns states the value in operational terms, including a line most business cases omit, the reuse dividend: the assets each pattern leaves behind for the next one to inherit.

The seven patterns are grouped into three tiers by what they ask of the plant. The See patterns make the plant legible: cross-site performance, genealogy, and energy. The Predict patterns anticipate: maintenance and batch quality. The Act patterns are where the architecture starts doing: grounded copilots and closed-loop operations. The tiers are a real sequence, not a taxonomy. Each stands on the one before it, for a reason that can be said in one sentence: you cannot predict what you cannot see, and you should not automate what you cannot predict.

Read the whole paper, or read the front matter and the two patterns nearest your pain; the template is built for both. Either way, start with the next section, because it contains the economic argument the individual patterns quietly assume.

One Foundation, Many Payoffs

The most important fact about these seven patterns is not in any of them. It is between them: they run on the same six layers. The edge hubs that contextualize OEE events are the ones that run vibration models. The shared vocabulary that makes cross-site numbers comparable is the one the copilot answers in. The graph that traces a recall is the one batch quality correlates against. Seven business cases run on one shared substrate.

For readers meeting the architecture here for the first time, the six layers, bottom to top, are the Edge Intelligence Hub (EIH), where data is validated and contextualized at the source; the Common Data Models (CDM), the shared language of entities, units, and relationships; the Unified Namespace (UNS), the real-time backbone every producer publishes into once; the Unified Data Layer (UDL), the governed enterprise memory and knowledge graph; the Feedback Data Layer (FDL), which records what the intelligence claimed, what people decided, and what happened; and AI Routing & Agents (AI R&A), where the architecture detects, decides, and acts. Each layer has its own companion deep dive; this paper needs only their names and their jobs.

The matrix is worth a minute of study. No pattern skips a layer entirely, and no two patterns weight the layers the same way. The See tier leans on the model and the data layer; the Predict tier lights up the feedback loop; the Act tier leans on everything at once. This is what it means, concretely, for intelligence to be the return on the data work rather than a bolt-on beside it.

The economics follow directly. In a use-case-led world, each of these seven would be its own project, and each project would rebuild its own version of the same plumbing: its own tag mappings, its own extracts, its own definitions, its own pipelines. The result is seven patterns, seven foundations, and an integration debt that compounds quietly underneath all of them. Foundation-led delivery inverts the curve: the first pattern carries the cost of the shared layers, the second borrows most of them, and by the third the marginal pattern costs a fraction of its standalone price.

The economics. The first pattern pays for the foundation. Every pattern after it borrows the foundation at marginal cost, and leaves behind assets the next pattern inherits. The portfolio, not the pilot, is the unit of return, and evaluating any single pattern against its full standalone cost is the arithmetic that keeps foundations from being built.

One practical implication before the patterns begin: the first pattern should be chosen partly for its own value and partly for what it leaves behind. The closing section of this paper gives that decision its own treatment. The tiers themselves, though, already encode the broad answer: start by seeing.

Tier One: See

The See patterns make the plant legible: to its own people first, then to the enterprise, and eventually to the models and agents of the later tiers. They are the least glamorous tier and the most dependable one. Their technology risk is low, their prerequisites are the shallowest, and their failures are almost always organizational rather than technical, which means they are also where an organization learns to do this work: to agree on definitions, to contextualize at the source, to publish once and subscribe everywhere.

They are also, quietly, the tier that determines whether the later tiers are possible. Every Predict pattern is a model trained on what the See tier made visible; every Act pattern acts within vocabulary and visibility the See tier established. A plant that skips ahead, and many try, ends up rebuilding Tier One inside a Tier Two project under a worse name and a tighter deadline.

Pattern One: Cross-Site OEE and Performance Visibility

The business problem

Every multi-site manufacturer runs a version of the same monthly meeting. Each plant reports its OEE, the numbers are impressive and mutually incomparable, and the first twenty minutes are spent arguing about definitions: whose availability excludes planned maintenance, whose quality counts rework, whose performance uses which ideal rate. The numbers arrive by spreadsheet, weeks after the losses they describe, assembled by people whose time was meant for improvement. And the real cost is not the meeting. It is that improvement capital is allocated on noise: the network cannot tell its best line from its best storyteller, so investment follows the confident site rather than the constrained one, and the losses that matter most stay wherever nobody is measuring them consistently.

The pattern in brief

Availability, performance, and quality events are captured and contextualized at the source on every line, mapped to one shared loss taxonomy, and computed against one OEE definition held in one place. The result is a near-real-time, cross-site performance picture in which any number can be compared with any other, drilled from network to site to line to loss reason, and trusted without a reconciliation exercise.

The data path

At each line, machine states, counts, and rates flow into the Edge Intelligence Hub, which attaches what the moment knows: equipment identity, running order, product, shift, and, critically, the loss reason mapped from local codes to the shared taxonomy defined in the Production Common Data Model. This mapping at the source is the pattern's load-bearing move: each site keeps its local codes on the floor, and every event leaves the site already speaking the shared language. The events publish into the Unified Namespace under their site and line topics, where line dashboards consume them live.

The Unified Data Layer ingests the same stream by subscription; its semantic layer holds the single OEE definition, its KPI warehouse computes hourly across all sites, and its loss Pareto tables answer the question OEE exists to point at: where is the time going. The Feedback Data Layer and AI layer play light roles here, an anomaly flag when a line's pattern shifts, but this pattern is deliberately winnable without them.

What it stands on

The technical prerequisites are modest: edge context tagging at each participating line, the Production model's entities, the namespace, and the data layer's semantic and KPI machinery. The genuine prerequisite is political, and this pattern is where the organization pays it: the loss taxonomy and the OEE definition must be agreed once, centrally, with the fight had in a conference room rather than relitigated in every month's data. A single site can run this pattern alone without the cross-site agreement, and that is a fine start, but the comparison prize, the thing the business problem is actually about, is purchased with the shared taxonomy and nothing else. Partial deployments should be honest about which prize they have bought.

Where teams go wrong

Relitigating the definition per site. Harmonization by negotiation with each plant separately produces seven bilateral compromises and no comparability. The workable move is one governed definition with local codes mapped to it, so no site renames its floor vocabulary on day one and every site's events arrive comparable anyway. Mapping is cheap; renegotiation is forever.

Dashboard-first delivery. Buying the visualization layer while each site still computes its own number underneath produces harmonization theater: one polished screen presenting seven different meanings. If the numbers do not share a definition in the semantic layer, the dashboard is a faster way to look at the old argument.

Reporting the index and burying the losses. OEE is a pointer, not a prize. A program that reports the percentage without the loss Pareto behind it teaches sites to manage the number, and the number is very manageable. The deliverable is the drill-down; the index is just its summary.

What it returns

The argument ends: with one number and one definition, the meeting reaches the interesting part twenty minutes sooner. Loss response moves from month-scale to hour-scale, because the Pareto updates while the loss is still happening. Capital allocation gets honest, because the constrained line and the well-narrated line are finally distinguishable. And the reuse dividend is the largest in Tier One: the harmonized Production model, the loss taxonomy, and the per-line contextualized event streams become the substrate that predictive maintenance trains on, that scheduling reasons over, and that the copilot speaks. The plant that finishes this pattern has not just measured itself; it has taught itself a language.

Pattern Two: Genealogy, Track and Trace, and Recall Readiness

The business problem

When a supplier calls about a suspect lot, or a customer complaint points backward at a batch, the question is always the same shape: what did this touch? Which batches consumed that material, which products came from those batches, which shipments carry those products, and in the other direction, what went into the unit in the customer's hand. In most plants, answering it is an expedition: the MES knows part of the story, the ERP another part, the LIMS a third, and the connecting tissue lives in spreadsheets and the memories of two people who set up the integrations. Recall scope takes days to determine, so it is determined conservatively, which turns a two-pallet problem into a two-warehouse recall, and every day of determination is a day of exposure with product in the field.

The pattern in brief

Material consumption and production events are captured with lot and batch identity at the moment they happen, linked in the data layer's knowledge graph as consumes and produces relationships, and joined to shipment records. Forward and backward traceability becomes a graph traversal: from any lot, batch, product, or shipment to everything it touched, in either direction, in minutes, with lineage attached.

The data path

On the floor, consumption and production events, scans, weigh-ups, MES transactions, reach the Edge Intelligence Hub, which attaches lot, batch, and order identity per the Material and Production models and validates that the identifiers are well-formed before anything travels. The events publish into the Unified Namespace and land in the Unified Data Layer twice over: as digital-thread rows joining process data to batch records, and as edges in the knowledge graph, this lot consumed by this batch, this batch producing this product lot. ERP master data binds supplier and customer identity, and shipment transactions extend the graph to the field.

A trace is then a traversal: start anywhere, walk consumes and produces edges in either direction, and the scope question answers itself with the records that prove it. The Feedback and AI layers are light here, though the copilot pattern in Tier Three will make this graph conversational: which customers received product from lots supplied in March is a sentence, and the graph is its answer.

What it stands on

Technically, the pattern stands on the Material and Production models with master data binding, edge capture at consumption and production points, and the data layer's graph. Operationally, and this is the pattern's honest center, it stands on capture discipline on the floor. The graph is only as true as the scans, and every unscanned substitution, every backflushed guess, every drum swapped without a transaction is a hole in the chain that an investigation will eventually find. The pattern's hardest work is making accurate capture the easy path at every consumption point. Partial deployment is natural: within-plant genealogy first, then extended across sites and to CMOs and co-packers by mapping their systems to the same models, which is a mapping exercise rather than a new architecture.

Where teams go wrong

Genealogy from the ERP alone. Backflushed transactional data records what the recipe says was consumed, not what the floor actually consumed, and the difference is exactly the substitutions and exceptions an investigation cares about most. A graph built on backflush inherits the fiction with better tooling. The chain has to be anchored in floor-level capture.

Building the trace for audits only. A genealogy exercised once a year for the auditor decays, because nobody notices the holes until the drill. The countermeasure is operational use: supplier-quality blast radius, FIFO verification, expiry management, run on the same graph weekly. A trace that earns its keep in normal operations is trustworthy in the crisis; one that exists for the crisis usually is not.

Discovering rework at investigation time. Splits, merges, rework loops, and partial returns are where naive genealogy models break, and the worst time to learn that is mid-recall. Model them in the CDM from the start; they are edge cases on the whiteboard and main cases in real material flow.

What it returns

Recall scope determination collapses from days to minutes, and, just as valuably, from conservative guesswork to demonstrated precision: the two-pallet problem stays two pallets, with the traversal as evidence for the regulator. Supplier quality events get an immediate blast radius. Audits stop being archaeology. And the reuse dividend is the graph itself: the lot-batch-product backbone becomes the correlation spine for predictive batch quality, the context the copilot traverses, and the structure that turned a vibration alert into a materials investigation in this framework's running examples. Genealogy is the pattern that makes the plant's history navigable, and navigable history is an asset every later pattern spends.

Pattern Three: Energy and Utilities Visibility

The business problem

Energy is typically a top-three controllable cost, and it is managed with almost no visibility. The bill arrives monthly, at site level, weeks after the consumption it describes, so nobody can say what a unit of product costs in kilowatt-hours, which line runs efficiently, or what the plant burns at two in the morning producing nothing. Compressed-air leaks hiss for months because no number moves when they start. Sustainability reporting, meanwhile, is assembled by hand each quarter from the same blind bills, satisfying the report while changing nothing on the floor.

The pattern in brief

Meters for power, air, steam, and water are brought onto the same architecture as production data, their readings contextualized to the line, product, and order running at the time. Energy stops being a monthly site-level bill and becomes an operational signal: intensity per unit by product and line, idle-load baselines, and anomalies surfaced while they are still cheap. This is deliberately the tier's quick win: the lowest prerequisite bar of the seven patterns, often the first to pay back, and a natural first exercise for the fleet and the practices every other pattern needs.

The data path

Most meters are already digital, or cheaply made so, and speak simple protocols; the Edge Intelligence Hub ingests them alongside everything else and does the move that creates all the value: it stamps each reading with what was running, which line, which order, which product, from the same context it already attaches to production events. The readings publish into the Unified Namespace's Utilities subtree, where the energy picture is live and browsable like everything else. The Unified Data Layer joins consumption to output, and intensity falls out: kilowatt-hours per unit, by product, by line, by shift. Simple rules at the edge or light models flag the cheap wins, idle loads that persist through the weekend, compressor cycling that drifts from baseline. The Feedback and AI layers stay light by design; this pattern's power is in the join, not the model.

What it stands on

The prerequisites are the shallowest in the article: edge ingestion, a modest Utilities domain added to the Common Data Models, the namespace, and basic joins in the data layer. Even the production context is partially optional at the start: a plant with no order context yet can still baseline idle loads and catch the weekend waste, then deepen the join as the other patterns mature the context. That shallowness is strategic. This pattern is how a plant learns the whole method, contextualize at the source, publish once, join in the governed layer, on a domain where the politics are gentle and the payback is quick, before spending that competence on the harder tiers.

Where teams go wrong

Energy as a separate system. The reflex is to buy a standalone energy-management platform, which faithfully recreates the silo problem this architecture exists to end: energy in one system, production in another, and the intensity question, energy per unit, falling into the gap between them. The entire value of the pattern is that the meters live in the same namespace as the lines they power.

Metering everything before using anything. A full submetering campaign as phase one delays payback by a year and produces data nobody has learned to act on. Start with the largest loads and the main feeds, act on what they show, and let the findings justify the next meters. The pattern funds its own expansion if it is allowed to.

Reporting as the only driver. If sustainability reporting is the sole sponsor, the pattern is built to the report's granularity, quarterly, site-level, and the operational value evaporates. Build for the shift-level loop, energy anomalies surfaced to the people who can act within hours, and the report becomes a byproduct that assembles itself.

What it returns

Energy intensity by product and line, which reprices products and reshapes scheduling more often than anyone expects. Idle-load elimination, typically the fastest payback found in the first weeks of baseline data. Demand-charge management from seeing peaks form in real time. Sustainability reporting as an automated byproduct rather than a quarterly project. And a reuse dividend that punches above the pattern's weight: the meter fleet and the contextualization habit, plus one quiet gift to Tier Two, energy signatures, motor current above all, are among the earliest and cheapest indicators of mechanical degradation, which means the energy pattern has already begun collecting the predictive maintenance pattern's data before that pattern officially starts.

Tier Two: Predict

The Predict patterns change the plant's relationship with time: from describing what happened to anticipating what is about to. Technically, the change is that models move to the center of the pattern, and with them the Feedback Data Layer lights up, because a prediction is a claim, and claims need judging. Culturally, the change is larger: the See tier asked people to trust numbers; this tier asks them to trust anticipations, and that trust has to be manufactured the only way it can be, with a record of claims meeting outcomes.

One reframe governs both patterns in this tier, and it is the quiet reason they belong here rather than in a machine learning text. The models are the commodity. The scarce inputs are labels: the failure history that lives in work orders, the quality outcomes that live in the lab system, joined cleanly to the condition and process data that preceded them. Organizations that stall in this tier almost never stall on algorithms.

The prerequisite. Prediction programs stall on labels, not algorithms. The failure history lives in the CMMS, the quality outcomes live in the LIMS, and a model's ceiling is set by whether those joins exist. The Predict tier is won in the data layer before it is won in the model.

Pattern Four: Predictive Maintenance

The business problem

Unplanned downtime is the most expensive way to learn an asset's condition. The failure itself is only the opening cost; behind it queue the lost production, the expedited parts, the collateral damage a failing component inflicts on its neighbors, and the safety exposure of machines that break instead of being taken down. The standing alternative, calendar-based preventive maintenance, buys predictability at the price of a different waste: healthy assets opened on schedule while the one genuinely degrading fails between visits. Planners schedule without condition information, so parts inventory carries the uncertainty as working capital, and the maintenance organization oscillates between over-maintaining the fleet and being ambushed by it.

The pattern in brief

Condition signals, vibration, motor current, temperature, are scored continuously, with fast signatures evaluated at the edge and deeper models predicting remaining useful life per asset. Recommendations arrive as prioritized work orders in the CMMS, every prediction is judged against what the inspection actually found, and the models retrain on their own judged history. The pattern is honestly a ladder, and should be sold as one: condition monitoring first (thresholds and signatures, no learning required), failure prediction second, prescriptive scheduling third. Each rung pays for itself, and skipping rungs is how programs end up demonstrating a remaining-useful-life model to a plant that does not yet trust its vibration alarms.

The data path

This is the one pattern in that leans heavily on all six layers, and its path is the architecture's full round trip. Condition sensors feed the Edge Intelligence Hub, which scores fast signatures locally, milliseconds matter for some failure modes, and publishes both raw streams and alerts into the Unified Namespace. Note what is already flowing before this pattern begins: the energy pattern's motor-current streams are early-degradation indicators, and the equipment context comes from the See tier's model.

The Unified Data Layer does the pattern's heaviest lifting: point-in-time features per asset, and the join that creates labels, work order history and failure codes connected to the condition data that preceded each event, plus fleet-level views that let one site's failures teach another site's identical assets. The AI layer runs the remaining-useful-life models and routes deep diagnostics to heavier models when a signature is ambiguous; its recommendations land in the CMMS as prioritized work orders, where a human planner owns the schedule.

And the Feedback Data Layer closes the loop that makes the whole thing improvable: the prediction registered as a claim, the technician's accept or override with reasons, the inspection finding joined as the outcome, and the retraining builder turning judged claims into the next model, which deploys back to the edge, signed and versioned.

What it stands on

From the See tier, the pattern inherits contextualized condition streams, the shared equipment model, and, ideally, the energy pattern's current signatures already flowing. From the systems estate, it needs a CMMS integration treated as a first-class part of the pattern, because the CMMS is both the action channel and the label source, and its failure coding discipline sets the ceiling on everything. A plant whose work orders close with free-text notes and a generic code has no labels, whatever its sensor budget; the failure-code taxonomy belongs in the Common Data Models with the same governance as the loss taxonomy.

From the architecture, it needs a working Feedback Data Layer, without which this is condition monitoring with extra steps. The honest partial deployment is the ladder's first rung: signature-based monitoring delivers real value with no ML at all, and it generates exactly the judged-alert history the higher rungs will train on.

Where teams go wrong

Training on failures the plant does not have. Well-run plants have mercifully few catastrophic failures per asset class, which starves supervised models exactly where the stakes are highest. The workable sequence is anomaly detection first, models of normal, flagging departures, which needs only healthy data the plant has in abundance, then pooling failure history across the fleet through the shared equipment model, so every site's rare events teach every site's models.

The alert flood. A detection layer tuned for sensitivity and wired to email produces hundreds of alerts, a week of enthusiasm, and then a filter rule. Alerts belong in the CMMS triage flow with an owner, and every accept and override belongs in the feedback record, because the overrides are the tuning data: the technician who dismisses the Filler alert with a reason is training the system, if the system is listening.

Prediction without the work order. Programs that treat CMMS integration as a phase-two nicety deliver recommendations someone must retype, which means they are admired and ignored, and they leave the failure history unencoded, which means the models never get labels. The unglamorous CMMS work is not adjacent to the pattern; it is half of it.

What it returns

Unplanned downtime falls, and falls most on the failure modes with condition signatures, which are many of the expensive ones. Preventive labor redirects from calendar to condition, so the fleet stops being opened on schedule. Parts inventory rationalizes against forecastable demand. And the pattern mints an asset no earlier pattern could: a judged accuracy record, claims against outcomes, per model, per asset class, which is precisely the evidence the Act tier will spend when the question becomes what this system may do without asking. The reuse dividend runs forward on every track: asset-health features enrich batch quality's context, the CMMS discipline and label pipeline serve every later model, and the trust manufactured here, prediction by judged prediction, is the currency the autonomous patterns are purchased with.

Pattern Five: Predictive Batch Quality

The business problem

In batch manufacturing, quality is discovered at the end: the batch finishes, samples travel to the lab, and days later a result arrives for a batch that can no longer be helped. A failing result means scrap or rework and a deviation investigation reconstructing, after the fact, what three veterans could feel going wrong at the time. That intuition is the clue that matters. Experienced operators know a batch is running hot, or slow, or wrong hours before any specification is breached, which means the information exists in the process data; the plant just has no systematic way to read it while it still matters. In regulated environments the same blindness has a paperwork twin: continued process verification assembled manually, batch by batch, from the same data nobody could read in real time.

The pattern in brief

The pattern learns the multivariate signature of known-good batches, per product and per phase, as envelopes around the trajectories that history says end well, then monitors every live batch against them. When a trajectory drifts, the system flags it mid-run, while the batch is still savable, with attribution: which parameters, which phase, and what similar batches did. Operators decide; outcomes close the loop; envelopes sharpen with every judged batch. This is the golden-batch idea made operational, and, properly built, it is also veteran intuition made explicit and durable: the thing the retiring expert could feel, expressed as an envelope anyone can see.

The data path

Everything begins with phase context, and this is the pattern's non-negotiable: in-process signals reach the Edge Intelligence Hub already stamped with batch and phase identity per the ISA-88 structures in the Common Data Models, because envelopes are meaningless across phase boundaries; a temperature that is perfect in HeatUp is a deviation in Hold.

Contextualized trajectories flow through the Unified Namespace, and the Unified Data Layer assembles the pattern's real substance: batch records joined to lab results, which are the labels that define good, and to the genealogy graph, which brings materials into the picture, because lot-to-lot variation is a cause the process data alone will misattribute. Per-product, per-phase envelopes live in the feature store, computed from the labeled history.

The AI layer scores live trajectories against them, attributes drift to contributing parameters, and raises its recommendation to the operator through the MES or andon, advisory, with evidence attached. The Feedback Data Layer records the claim, the operator's response, and, when the lab result lands, the outcome, closing each batch into a labeled example. The regulated-environment dividend falls out of the same records: continued process verification reporting assembles itself from data the pattern was keeping anyway.

What it stands on

The pattern stands on phase-contextualized data above all, which means the ISA-88 portions of the Common Data Models doing real work at the edge; on a LIMS join, because without lab outcomes there is no definition of good; on the genealogy pattern's graph, for material context; and on a working Feedback Data Layer.

It also stands on something no architecture can conjure: enough history per product. High-volume products support envelopes quickly; a high-mix plant with four runs a year of each variant needs pooling across related products or should begin honestly with the pattern's retrospective mode, explaining finished batches, before promising live intervention. That mode is not a consolation prize: mid-run monitoring on the top products and fast, attributed retrospectives on the long tail is a strong steady state, and the retrospectives generate the history the envelopes eventually need.

Where teams go wrong

Envelopes without phase alignment. Modeling whole-batch trajectories without ISA-88 phase context averages the signal away: every batch spends different minutes in each phase, and unaligned comparison blames timing for chemistry. Phase alignment is not a refinement of this pattern; it is the pattern, and it is why the CDM prerequisite is listed first.

Blaming the process for the material. Models trained only on process signals will attribute supplier variation to equipment and operators, with perfect confidence, because the true cause is not among their inputs. The genealogy join is what lets the analysis say the drift entered with the lot, which is frequently the actual story, and always the cheapest one to have missed.

Black-box interventions in a regulated process. A drift flag with no attribution asks an operator to act on faith and a quality unit to approve magic; neither should. Every recommendation carries its evidence, the parameters, the phase, the comparable batches, and the pattern stays advisory until the Act tier's disciplines, bounded authority and judged history, justify anything more. In a validated process, the path from advice to action runs through change control, and the pattern should be designed knowing it.

What it returns

Batches saved mid-run instead of scrapped at the lab, which is the headline, and right-first-time climbing as drift gets caught at the phase where it entered. Investigations that start from attribution instead of archaeology. Continued process verification as a byproduct rather than a quarterly project. The veteran's feel for a good batch, captured as envelopes that outlast the veteran. And a reuse dividend that reaches directly into the final tier: the envelopes are not just monitors, they are boundaries, the empirically grounded definition of where this process may safely be, and when the closed-loop pattern arrives asking what limits an autonomous adjustment must respect, the envelopes are the answer this pattern already built.

Tier Three: Act

The Act patterns are where the architecture stops handing its conclusions to a person and starts doing something with them: answering the question directly, adjusting the setpoint, dispatching the work order. The tier's two patterns are deliberately sequenced. The grounded copilot acts only on attention, it changes what people know, not what the plant does, which makes it the safest possible rehearsal for the second pattern, where actions touch the physical world and the stakes change in kind, not just in degree.

What governs this tier is a distinction the first two tiers were quietly preparing. Capability is what a system could do, and by this point the capability is largely assumed. Authority is what it may do, and authority is a design decision: bounded explicitly, enforced in the architecture rather than requested in a prompt, and sized to evidence rather than enthusiasm. The See tier built the visibility that makes supervision possible; the Predict tier built the judged record that makes trust rational. This tier spends both. The discipline for sizing that authority, five levels, risk ceilings, and the graduation path, is the subject of Earning Autonomy, and this tier assumes it.

The rule. In the Act tier the constraint is never capability; it is authority. What a system may do is a design decision made from risk, enforced in the architecture, and paid for with evidence, and the first two tiers are where the evidence came from.

Pattern Six: The Grounded Copilot

The business problem

Every plant runs on a small number of people who can find things out. The answer to why line five ran slow last night, whether this deviation has happened before, or which work orders touched the filler in March exists, distributed across the MES, the historian, the LIMS, the CMMS, and several heads, but extracting it requires knowing five systems, three query tools, and who to call. So the questions queue behind the few people who can navigate, the night shift waits until morning, the new engineer waits years, and an unknown number of good questions are simply never asked because asking is too expensive. Many plants have already tried the obvious fix, a chatbot over a document folder, and abandoned it for the predictable reason: fluent, confident, and wrong, which is worse than no answer at all.

The pattern in brief

A conversational interface to the plant, grounded exclusively in the governed layers: live state from the namespace, history and relationships from the data layer and its graph, vocabulary from the shared models. Every answer carries its evidence, records cited, traversals shown, and questions the system cannot answer confidently are escalated to people rather than improvised. The pattern is read-only by design: it acts on attention, not on equipment, which is precisely why it belongs first in this tier. It is where the organization learns to supervise machine judgment while the cost of a miss is a correction, not a batch.

The data path

A question arrives in plain language and meets the AI router, which treats it like any other task: simple lookups go to small, fast models, cross-domain investigations to the enterprise tier.

Before any model is prompted, context injection does the work that separates this pattern from the abandoned chatbot: the Common Data Models resolve the asker's words to governed entities, the filler becomes an equipment identity with a place in the hierarchy, and the router assembles the grounding, current state by subscription from the Unified Namespace, history and digital-thread joins from the Unified Data Layer, and graph traversals where the question is really a relationship question, which investigative questions usually are.

The answer returns with its citations attached, so a skeptic can walk every claim back to the record behind it. Permissions are inherited, not invented: the copilot queries through the same topic ACLs and row-level access the human holds, so it cannot tell anyone what they could not have queried themselves. And the Feedback Data Layer logs the exchange, question, grounding, answer, and the asker's verdict, which is how answer quality becomes a measured, improving thing rather than an impression.

What it stands on

The copilot stands on the shared vocabulary above all, because entity resolution is what makes the conversation mean anything: a copilot that cannot bind the filler to an identity is matching words rather than meaning. It stands on the data layer with its graph, because the difference between this pattern and retrieval over documents is the difference between traversing governed relationships and searching prose. And it stands on the permissions model, inherited end to end, and on the Feedback Data Layer, without which quality is anecdote.

The honest version of the prerequisite argument deserves stating plainly: a copilot over a swamp is a faster way to distribute confidently wrong answers, and groundedness cannot be prompted into a system whose sources are ungoverned; it is inherited from the layers or it is absent. The natural partial deployment is one domain deep rather than all domains shallow: maintenance history question-and-answer, say, where the joins are strongest, expanded domain by domain as the foundation under each is ready.

Where teams go wrong

Grading on fluency instead of groundedness. The demo selects for how good the answers sound; the plant needs how often they are right and shown to be right. The evaluation that matters is mechanical: citation rate, answer-from-records rate, and a standing test set of questions with known answers, run on every change. A copilot that cannot show its work has not earned the 2 a.m. shift.

The ungoverned side channel. Under pressure to be more helpful, someone wires the copilot to a folder of exports and documents beside the governed path, and the pattern quietly dies: lineage breaks, permissions are bypassed, and the abandoned-chatbot failure returns under the architecture's name. Everything the copilot knows should arrive through the governed APIs, and an exception to that rule is an incident, not a feature.

Answering when it should escalate. A system with no confidence threshold and no escalation path will improvise precisely when improvisation is most dangerous, on the strange question, at night, from the person least equipped to catch the error. Low confidence routes to a person, with the context assembled and the handoff logged, and the escalation rate is a health metric, not an embarrassment.

What it returns

Answers in seconds at two in the morning, for everyone, which redistributes a scarce competence that used to be three people's calendars. Onboarding compresses, because the questions that took years to learn to ask, and longer to learn to answer, are now askable on day one. Investigations start from assembled evidence instead of a week of collection.

And the pattern pays the whole foundation a visibility dividend: the copilot is the interface through which operators, engineers, and managers finally experience what the graph, the semantic layer, and the shared vocabulary were for, which converts foundation skeptics with every good answer. The reuse dividend runs two ways: the question log is a demand signal, a ranked list of what the organization wants to know, which is a roadmap for the next dashboards and patterns; and the supervision habits built here, reading grounded claims, checking citations, judging escalations, are exactly the habits the next pattern requires before it can be trusted to act.

Pattern Seven: Closed-Loop Optimization and Autonomous Dispatch

The business problem

By this point, the plant detects in seconds and decides in minutes, and then the loop waits: for the planner to return from a meeting, for the morning shift, for someone to notice the queue. The latency between detection and action is now the longest delay in the system, and it is made of human attention, the scarcest resource on the site, spent largely on decisions that do not need it: the routine work-order dispatch, the schedule nudge inside agreed limits, the setpoint correction back toward the validated center. Meanwhile nights and weekends run thin, the same situation gets different responses depending on who is on shift, and the experts whose judgment the hard exceptions genuinely need spend their days approving the obvious.

The pattern in brief

Bounded autonomous action: within limits that are written down, validated, and enforced in the architecture, the system acts, resequencing non-critical orders inside agreed windows, dispatching and prioritizing routine maintenance work, correcting setpoints within validated ranges, with humans supervising through oversight queues, intervening at will, and owning everything outside the bounds. This is emphatically not lights-out manufacturing. It is the disciplined endpoint of everything that has been built: autonomy sized to evidence, expanded only as the judged record justifies, contracted the moment it does not, and always operating inside boundaries the earlier patterns defined, including the most elegant of them, the batch quality envelopes, which turn out to be exactly the empirical definition of where this process may safely be.

The data path

Detection arrives from anywhere the earlier patterns run: an edge signature, a drift flag, a dispatch trigger. The AI layer forms a proposed action and meets the pattern's defining checkpoint: the authority check, enforced at the permission layer, not requested in the prompt, which verifies the action is inside this agent's written bounds, this action class, this magnitude, this asset, these conditions, and inside the operating boundaries the feature store holds, the envelopes and validated ranges.

What passes executes through the systems of record: the schedule change through the scheduling system, the work order through the CMMS, the setpoint through the MES within its validated range, and never through direct writes to the control layer, whose own validated interfaces and interlocks remain exactly as they were.

The action publishes to oversight topics on the Unified Namespace, where the supervision queue is a live view humans watch and can override. What fails the authority check escalates to a person with the context already assembled. And every action, override, and outcome lands in the Feedback Data Layer, which is both the audit trail and the ratchet: sustained good judgment is the case for wider bounds, and the demotion triggers, a quality event, an error-profile drift, an unwatched queue, contract authority automatically, pending review, without anyone needing to win an argument first.

What it stands on

Everything, and that is the honest answer: this pattern draws on every asset that's been built. It needs the See tier's visibility, because supervision requires a live, trustworthy picture of what the system is doing. It needs the Predict tier's judged record, because authority is purchased with evidence and there is no other legitimate currency. It needs the envelopes and validated ranges as machine-readable boundaries, and it needs the permissions infrastructure, because bounds that live in prompts are requests, and bounds that live in the platform are constraints.

And an organizational design taken as seriously as the technical one: named queue owners per shift, a practiced intervention path, and a standing review that reads the feedback record and moves the bounds, in both directions. The right partial deployment is not a smaller version of everything but full discipline on the smallest thing: one action class, maximally reversible and lowest-consequence, routine work-order dispatch is the classic, started at act-with-approval and graduated on its record, with the second action class onboarding through the path the first one proved.

Where teams go wrong

Bounds in the prompt instead of the platform. Telling the system its limits and enforcing its limits are different engineering disciplines, and only one of them holds under pressure, edge cases, or a sufficiently creative request. If an auditor cannot find the bound in the permission layer, the bound does not exist; the prompt states the rules, the platform enforces them.

Autonomy as a launch instead of a graduation. The big-bang go-live, shadow mode skipped, approval phase compressed, bounds set by ambition, collects its incident within the quarter and sets the program back years, because trust lost to a preventable miss is repaid with heavy interest. The graduation path is not ceremony; it is how the evidence gets made, and demotion has to be as real as promotion or the ratchet only turns one way, which is how organizations end up unable to respond to what their own records are telling them.

Automating the exception instead of the routine. The temptation is to point autonomy at the hard, rare, high-stakes decision, because that is where the value looks biggest. It is exactly backwards: the frequent, reversible, boring decisions are where autonomy is safe, valuable, and provable, and the rare hard ones are where human judgment earns its keep. Automate the routine, escalate the exception, and let the experts spend their attention where the pattern deliberately refuses to.

What it returns

Detection-to-action latency collapses for the routine classes, which is where most of the accumulated delay lived. Nights and weekends get the same response quality as Tuesday morning, and the same situation gets the same answer regardless of who is on shift. Expert attention reallocates to exceptions, which is both the economic point and the retention point, because the work that remains human is the work worth a human.

And the pattern compounds by construction: every autonomous action and its outcome enriches the feedback record, which sharpens the Predict tier's models, which improves the next action, while the bounds expand exactly as fast as the evidence justifies and no faster. The reuse dividend of the final pattern is the operating model itself: a plant that has taken one action class through shadow, approval, bounded autonomy, and honest review now owns a repeatable path that every future action class walks at a fraction of the cost, which is to say the plant has stopped buying automation projects and learned to grow autonomy.

Choosing Your First Pattern

The most common question asked is where to start, and the honest answer is that it depends on where the pain is loudest, what the foundation can already support, and what the organization needs to believe next. The map below is the tool for that conversation: the seven patterns, the assets each hands forward, and what each tier's foundation requires. Locate your plant against the bands at the bottom, and what is reachable now versus next year reads off the map. The maturity self-assessment scores your plant against the same foundation.

A few situations come up often enough to answer directly.

If you are multi-site and the numbers do not compare, start with cross-site OEE. The political work of one taxonomy is the hardest single deliverable in the See tier, and it pays everywhere: every later pattern speaks the language this one forces the organization to agree on.

If recall exposure or audit findings keep leadership up at night, start with genealogy. The regulatory case funds it, the capture discipline it demands raises the floor for everything else, and the graph it builds is an asset half the later patterns will lean on.

If the foundation itself needs a proof, start with energy. It has the shallowest prerequisites, the gentlest politics, and payback measured in weeks, which makes it the right first exercise for a skeptical brownfield organization learning the method: contextualize at the source, publish once, join in the governed layer, act on what you see.

If unplanned downtime is the loudest pain, start predictive maintenance on its ladder, condition monitoring first, provided the CMMS is in decent shape, because the work-order integration and failure-code discipline are half the pattern. If the CMMS is not in decent shape, that is not a blocker; it is the actual first deliverable.

If scrap and right-first-time dominate the P&L, start batch quality in retrospective mode, explaining finished batches with attribution, and let the envelope history accumulate toward live monitoring on the top products. The phase-context prerequisite means this start doubles as the forcing function for the ISA-88 portions of the model.

If the bottleneck is answers, the copilot can lead, one domain deep where the joins are strongest, but check the inheritance rule first: a copilot is only as grounded as the layers under it, and leading with it on a weak foundation rebuilds the abandoned chatbot with better branding.

And one rule with no exceptions: nobody starts with Pattern Seven. Closed-loop autonomy is a destination, reached through the evidence and habits the other patterns manufacture, and any vendor or roadmap that offers it as an entry point is selling the last chapter as the first.

Whatever the entry, the practical shape of a good first year is two tracks run together: one pattern chosen for visible value, and the foundation increments that pattern honestly forces, built as shared assets rather than project plumbing. The implementation roadmap maps those increments phase by phase. The See tier is rarely the wrong answer, not because it is cautious but because it is where the compounding starts: its deliverables are the raw material of every pattern above it, which is the whole argument of the next and final section.

The Compounding Plant

To see the economics of the front matter become a schedule, walk a representative plant through two years. Picture a mid-sized, multi-site, brownfield manufacturer with respectable systems, incomparable numbers, a maintenance organization on the calendar, and a leadership team that has seen two pilots die. Nothing about it is exotic, which is the point.

In the first six months, the plant stands up energy visibility and single-site OEE, chosen for payback and for what they force into existence: the edge fleet, the Production and Utilities models, the namespace, and the data layer's first governed tables. The idle-load findings pay for the quarter, and something subtler happens: the organization has its first argument about a loss code taxonomy in a conference room instead of a monthly meeting, and wins it once.

In months six through twelve, cross-site OEE goes live on the taxonomy that fight settled, and the loss Pareto starts steering improvement weekly instead of monthly. Genealogy stands up within the lead plant, and the graph begins accumulating the consumes-and-produces edges that will matter later. Nothing in this half-year is glamorous, and by the end of it, the plant is legible.

In months twelve through eighteen, the Predict tier opens on assets the See tier already instrumented: condition monitoring begins on the top asset classes, with the energy pattern's current signatures contributing from day one, and the Feedback Data Layer stands up to judge the first alerts. Batch quality begins in retrospective mode, explaining finished batches while envelope history accumulates. The copilot arrives one domain deep, answering maintenance-history questions with citations, and quietly converts the foundation's skeptics one good answer at a time.

In months eighteen through twenty-four, the maintenance models climb to prediction on their judged record, live envelopes cover the top products, the copilot expands a domain at a time, and the first autonomous action class, routine work-order dispatch, enters shadow mode, then act-with-approval, walking the graduation path on evidence the year has quietly been accumulating. By the two-year mark, the plant is not finished; it is compounding, and the next action class, the next product's envelopes, and the next copilot domain each cost a fraction of what the first ones did, which is the cost curve from the front matter, realized in practice.

Look back down that schedule and count what was never built twice: one edge fleet, one vocabulary, one namespace, one governed memory, one feedback loop, one router. Seven business cases drew on them; none paid for them alone; and every quarter's deliverable made the next quarter's cheaper.

The patterns in these pages are not seven projects. They are one foundation viewed from seven angles, and the tiers are simply the order in which a plant learns: to see, then to anticipate, then, carefully and on evidence, to act. Organizations that buy the patterns one at a time, each on its own bespoke plumbing, will get some of them working and none of them compounding. Organizations that build the foundation once will find each pattern cheaper than the last, and will eventually notice the real product was never any single pattern; it was the plant that can keep adding them.