Every application in a plant keeps its own partial version of the factory, because it has to in order to do its job. Each one is correct about its piece. None of them holds the relationships between the pieces, so somebody rebuilds the picture by hand every time a decision needs more than one of them at once. What it takes to define those relationships once, and why a data lake doesn't do it for you.
A quality engineer gets a returned unit on a Monday afternoon. A serial number, a customer complaint, and a request for root cause by Friday. Finding out what happened to that one unit takes her the rest of the week. The build record sits in one system. The material lot that went into it sits in another. Which engineering revision was in effect the week it was built takes a conversation with the engineer who released the change, and he has to go look it up too. Whether the operator who ran final test was certified on that fixture at the time is a question nobody has a fast answer to, because the certification record and the production record were never connected to each other. Every piece of it exists somewhere in the plant. None of it is attached to the unit sitting on her desk. She gets there. She always does. But she spent four days assembling a picture of one product that the factory technically had the whole time.
None of This is New
The last post made the case that more information hasn't made manufacturing decisions any easier, because information was never really the thing that was missing. What's missing is the connective tissue between it. Context is not extra data. It is the relationships you already rely on. This post is about what that connective tissue actually consists of, and what it takes to build it deliberately.
Start with what experienced people do. When an operator reports that a unit finished assembly, nobody with real floor time stops at whether it finished. The useful questions come immediately after. Which product. Which customer order. Which engineering revision. Which materials were consumed, from which lot. Which equipment and tooling. Were the required inspections done, and done at the right point in the process. Is the next operation ready to take it. Does any of this change today's priorities.
Not one of those questions requires new information. Every answer already exists somewhere in the plant. What they require is a way to understand how the existing information relates to everything else happening at the same time.
This is also why the question rarely gets asked out loud. An experienced supervisor runs through most of it in a few seconds without narrating any of it, which makes the reasoning look like instinct rather than a series of lookups. It isn't instinct. It's a set of relationships someone learned over fifteen years and now carries around privately, and the reason a new hire takes so long to get useful is that none of it was ever written down anywhere they could find it.
That set of relationships is what people mean by manufacturing context, and it's worth being unglamorous about it, because none of it is new. Long before any of this was digital, products followed defined processes, operators worked from approved instructions, materials were consumed at specific operations, and an engineering change affected what got built next. The factory has always run on those connections. Software doesn't invent them. At best it makes them visible and usable. At worst it loses them somewhere between two applications.
Losing Them is the Normal Case
Each application ends up rebuilding the factory in miniature, scoped to whatever it needs to function. ERP knows a part number, a cost, and a purchase order. Execution knows a work order and an operation. Quality knows an inspection and a disposition. Planning knows capacity and a due date. Maintenance knows an asset and a work request. Each one is accurate about its own piece, and none of them holds the connections between the pieces, so each one reconstructs whatever partial picture it needs and moves on.
Consider something as ordinary as a part number. In ERP it identifies something purchased at a cost against a supplier agreement. In engineering it identifies a revision with a specific approved configuration. On the floor it identifies whatever is physically in the bin, which may or may not be the revision the current order calls for, depending on how a substitution got handled three weeks ago. All three are working correctly. All three are describing the same part. The trouble starts when a decision needs all three at once, which is most decisions worth making.
The same split shows up between what was designed and what was actually built. Engineering holds an approved configuration. The floor holds a serialized unit that may carry an approved deviation, a substitute material, a repair performed at station four, and a retest. Both records are legitimate. Neither is complete on its own. Reconciling them is somebody's job every time a customer asks a question about a specific unit, and that reconciliation happens over and over because nothing in the plant holds both halves together permanently.
The standard response has been integration, and integration was genuinely worth doing. Getting systems to exchange information quickly solved a real problem that used to consume people's days. Material movements get logged the moment they happen instead of at the end of a shift. Machines report status without anyone walking over to check a gauge. That is real progress and it shows up in fewer transcription errors and faster reporting.
But moving information between two systems that each hold a different partial picture doesn't produce a shared one. It produces faster disagreement. There's a compounding cost underneath it too. Every integration added is another place operational logic lives and has to be maintained. Add a system, add a translation. Change a process, and the rule now needs updating in six places, assuming somebody remembers all six. Change it again in eighteen months, after the person who built the original mapping has moved on, and the odds get worse. This is a large part of why digital investment in manufacturing so often feels like running in place. The number of systems keeps growing. So does the number of places the same truth has to be kept current.
The Data Lake Doesn't Solve this Either
This is worth saying plainly, because a lot of manufacturers have already spent real money on the assumption that it does. Moving everything into one storage location is not the same as preserving the relationships among the things stored. Copy five partial pictures of the factory into a single repository and what you have is five partial pictures in a single repository. The queries run faster. The reconciliation work doesn't disappear. It moves to whoever is writing the queries, and it now happens in a place where operations people can't see it.
The distinction matters because storage and structure get discussed as if they were the same investment. They aren't. One is about where information sits. The other is about whether the meaning survives the trip. A plant can be entirely successful at the first and no further along on the second than it was five years ago.
What a Shared Foundation Actually Has to Hold
It's easy to agree with the principle and still not know what you're building. So it's worth being specific about the layers, because they aren't abstract. Every one of them already exists in the plant today, usually in a different system.
It starts with the product definition. Engineering establishes what gets built: the structure, the revision, the manufacturing requirements, the compliance obligations, any customer-specific configuration. That definition should stay attached to every activity that follows rather than being handed off once and then sitting somewhere nobody downstream can reach it.
Then the process that turns that definition into work someone can actually perform. Routings, instructions, inspection requirements, machine programs, production rules. In most plants these live as documents maintained separately from the systems that use them, which is why a released engineering change so often fails to reach a work center that needed it.
Then the resources, which only mean anything in relation to the work they support. A machine performs specific operations. Materials are consumed by defined processes. Tooling is qualified for specific operations and carries its own service life. Operators perform work based on qualifications and certifications that are current as of a specific date, not in general. Strip those relationships out and you have an equipment list, a bill of materials, and a training roster, none of which tells you whether a particular unit was built correctly.
And then the events, which are what keep the whole thing honest. Every completed operation, material transaction, inspection, repair, and engineering change either extends the shared picture or gets recorded somewhere it can't be reached. This is the most easily underestimated part. A foundation isn't something built once and then consulted. It's something production continuously feeds, or it goes stale. Plenty of plants have watched exactly that happen to a reporting system that was accurate the day it went live.
Define the Relationships Once
The alternative to all this reconstruction is easy to state and harder to do. Define the relationships one time, in one place, and let every application and every person draw from them instead of building their own version.
Concretely, that means defining how a product relates to the process that builds it, how that process relates to the materials and equipment it consumes, how those resources relate to the people qualified to run them, how all of it relates to the quality requirements that govern it, and how the whole thing relates to the customer commitment sitting behind it. Define that once and a production event stops being a status message. It starts carrying its own meaning.
Take the same operation complete event from the last post. On a shared foundation, that single event identifies the serialized unit that was built, confirms the process that was followed, records the materials consumed and extends the genealogy record, verifies which engineering revision was in production, and signals that downstream work can begin, that available capacity has changed, and that a delivery commitment may need updating. Nothing new was collected. The event didn't change. What changed is how much of the operation someone can understand from it without making a phone call.
The research is starting to catch up to this. The Manufacturing Leadership Council found that companies with strong data contextualization and standardization practices are three times more likely to scale AI successfully across their operations than those without it.1 ARC Advisory Group has arrived at the same place from a different direction, concluding that for manufacturers pursuing industrial AI, advanced analytics, or digital twins, contextualized operational data isn't a nice to have. It's the precondition.2
Both findings are worth sitting with, because they reframe what looks like an architecture question into a sequencing question. Whatever a plant intends to do next with AI, planning, or simulation, what determines whether it works is whether the relationships underneath it already exist. Building those relationships after the fact, one project at a time, is how pilots stall at the pilot stage.
What this Changes on a Monday Afternoon
Back to the returned unit. When the relationships are already in place, the serial number carries its own history. The process it followed, the revision in effect, the material lots consumed, the inspections performed, the operator qualifications at the time, the equipment that ran it. Four days of assembly becomes an afternoon of analysis, and the analysis is the part that was actually worth her time in the first place.
The wider effect matters more than any single case. Engineering can verify the correct definition was built. Production can focus on output. Quality can investigate the defect. Planning can balance capacity. Maintenance can watch equipment behavior across similar assets. Each function looks at the same operational activity through its own responsibilities, and none of them has to first negotiate whose version of events is correct before doing their actual job.
An afternoon spent reconciling three accounts of the same production event is an afternoon not spent improving anything. Multiply it across every plant, every week, and it becomes a substantial amount of effort spent getting everyone onto the same page before the work of getting better can start. It never appears as a line item. It appears as a plant that always seems a little busier than its output would suggest, and nobody can point to the reason.
This is Not an Argument for Replacing What You Already Have
Nobody is ripping out ERP, and the point here isn't consolidating every system into one. ERP should keep doing what ERP is good at. Engineering systems should keep managing engineering data. What changes is that the operational relationships between products, processes, materials, equipment, people, and commitments stop being something each application invents privately for its own use, and start living somewhere every application can draw from.
It's also worth separating this from the phrase most often used for it. A single source of truth usually describes where a record is stored and which copy wins when two disagree. That's a useful thing to settle, but it's a different problem. Two systems can agree completely on a value and still interpret it differently, because agreement on a number isn't the same as agreement on what the number means in context. Storage settles the first. Only defined relationships settle the second.
And this isn't a project with a completion date, which is probably the least convenient thing about it. A foundation only stays accurate if production keeps feeding it. A foundation that stops getting fed goes stale exactly the way an unmaintained simulation goes stale, and people stop trusting it for exactly the same reason. The upside is that the reverse compounds. Every production run, every inspection, every engineering change leaves the picture slightly more complete than it was, which means the next decision starts from better ground than the last one did.
Which raises the practical question. If the relationships live in one place and every production event keeps extending them, what does that actually change about the work happening on the floor right now, on this shift, on this order? That's where the next post picks up.
Sources
1 Manufacturing Leadership Council, "The Industrial Data Foundation Imperative: Building Manufacturing's AI Future," 2025.
2 ARC Advisory Group, "The Context Crisis: Decoupling Data, Defending IP, and the Missing Link for Agentic AI," 2025 to 2026.