RELATIONSHIPS ARE KEY TO MANUFACTURING PROBLEM SOLVING

A production manager gets a text at 6:40 AM, scrap on Line 3 has doubled overnight.

Not a gradual drift, rather it has doubled between yesterday's shift report and this morning's. The instinct is to treat this like a simple lookup problem. Pull up the line's dashboard, find the metric that jumped, find the cause, fix it. That instinct is wrong, and figuring out why it's wrong is the whole point of this article.

Here's how the morning actually goes. The scrap report tells her which line and which shift, but not why. So she starts asking questions, and each question drags her into a different part of the plant.

First, what changed on the machine itself? The maintenance log shows a bearing was replaced on the extruder two days ago. Maybe relevant. She needs to know whether that extruder feeds the section of the line generating the scrap, which means she needs the process flow: what feeds what, in what order, at what rate. The maintenance record and the process sequence live in two different systems, and nothing links them automatically. She's doing the linking in her head.

Second, is it the material? She pulls the lot numbers running through Line 3 last night and traces them back to the incoming raw material lots. That's material genealogy: this batch became that batch became this finished good. If a bad resin lot is the culprit, she needs to know everywhere it went, because there may be scrap coming on other lines she hasn't heard about yet.

Third, who was running the line? Different operators run a process differently, because tacit adjustments accumulate over years and nobody writes them all down. She checks the schedule, finds a name, and needs to know whether that operator has run this line-and-product combination before, or whether last night was their first time after a transfer. That's a relationship between a person, a role, a piece of equipment, and a point in time, and it lives in nobody's report.

Fourth, was it electrical? The extruder pulls off a specific motor control center. A voltage sag or phase imbalance overnight might explain an instability no process sensor would show, because those sensors measure the process, not the power feeding it. Answering this requires knowing which MCC powers which equipment, a completely separate map from process flow.

Fifth, the utilities. Compressed air pressure, chilled water temperature, steam quality can all shift a process without tripping a line alarm. She needs to work through data from the utility systems this line depends on, and whether anything upstream had an event overnight.

Sixth, the schedule. Maybe the line ran a different product mix than planned, meaning a different recipe, different setpoints, different tooling. Scheduling knows what was supposed to run. It doesn't know whether the changeover was executed correctly.

Seventh, environmental conditions. Humidity swung overnight, and this polymer is sensitive to ambient moisture during a specific process stage. Nobody logs "weather" next to "scrap," but the relationship is real.

Eighth, quality inspections. Were in-process checks actually performed on schedule, or did a staffing gap let a defect through that should have been caught hours earlier?

By 10:45 AM, she has her answer. It turns out to be a combination of two things: the new bearing changed the extruder's thermal profile slightly, and that shift, combined with the overnight humidity swing, pushed a moisture-sensitive resin outside its process window. Neither factor alone would have caused it. Both together did.

Notice what just happened. She didn't investigate one system. She investigated eight different kinds of relationships between the same set of physical and organizational entities: what's connected to what, what feeds what, what's powered by what, who's assigned to what, what happened when, what's supposed to happen versus what actually happened. Every one of those relationships lives somewhere. Almost none of them live next to each other. And almost none of them will be captured anywhere for the next person who has to do this same investigation six months from now, on a different line, with a different combination of causes.

‍That's the actual problem that needs addressed. Not scrap. Not this specific plant. The fact that manufacturing knowledge lives in relationships between things, and those relationships are almost never modeled on purpose. They get rediscovered, from scratch, by whoever happens to be investigating, every single time.

Relationship Dimensions

Let's put a name on what just happened, because once you see it, you can't stop seeing it. A relational dimension is an independent way that operational entities relate to one another. "Independent" is the important word. Each dimension answers a different kind of question, and knowing the answer in one dimension tells you nothing about the answer in another. A few examples of relationship dimensions, all drawn from the investigation above.

‍Physical hierarchy. Plant contains Area, Area contains Line, Line contains Machine. This is containment. It answers "where is this" and "what's part of what," and it's usually the first thing anyone models, because it's the most obvious.

‍Process flow. Tank feeds Mixer, Mixer feeds Extruder, Extruder feeds Packaging. This tells you the order material moves through the plant, which is a completely different question from where things are physically located. A tank can be right next to a mixer it has nothing to do with, and feed a mixer three buildings away.

‍Electrical distribution. Transformer powers Motor Control Center, MCC powers Motor. This tells you shared points of failure and shared power quality issues. It has almost nothing to do with process flow. Two machines that are electrically siblings might be on opposite ends of the process.

‍Material genealogy. Lot becomes Batch becomes Finished Good. This is traceability through transformation, and it's the dimension that matters most the moment there's a recall, but it's structurally unlike any of the others because the "things" being related aren't fixed assets, they're quantities of material that come into existence and get consumed.

‍Personnel. Operator assigned to Line, Technician assigned to Work Order. People relate to equipment and to each other in ways that shift shift to shift, which makes this dimension inherently time-sensitive in a way physical hierarchy usually isn't.

‍Maintenance. Motor installed on Pump, replaced on this date, by this technician, with this part. This dimension tracks the history of what's actually inside a piece of equipment right now, which frequently differs from what the original engineering drawing says should be inside it.

‍Information systems. Sensor connected to PLC, PLC connected to Historian tag. This is the plumbing that gets data from the physical world into a system a human or an algorithm can see, and it's worth modeling because sensors get moved and remapped more often than anyone updates the documentation.

‍Business. Order produces Batch, Batch fulfills Order. This connects the shop floor to the commercial side, and it's the dimension finance and sales actually care about.

‍Temporal. Asset occupied this location during this time period. This one differs from the rest: it isn't a new kind of relationship, it's a property of every other dimension. Everything above has an "as of when" attached to it, whether anyone records it or not.

None of these dimensions compete with each other. None of them is the "real" model with the others as afterthoughts. They're independent views of the same operation, and the reason the scrap investigation took three hours instead of thirty minutes is that none of them were connected to each other ahead of time. Every question required a manual bridge between two dimensions that had never been introduced to one another.

Where This Concept Has Already Been Validated

If this sounds like a novel argument, it isn't, and it's worth pointing at the place in the industry where a very similar realization has already been formalized.

CESMII, the Smart Manufacturing Institute (cesmii.org), organizes its architecture around three imperatives. The first is defining standardized information models for manufacturing assets and processes, what CESMII calls Smart Manufacturing Profiles, or SM Profiles. An SM Profile is essentially a class definition; it says what a pump is, what properties a pump has, what a valid instance of "pump" looks like, in a standardized, vendor-neutral way. That's genuinely useful. Without it, every integrator and every plant invents its own definition of "pump," and none of them are compatible.

But CESMII didn't stop there, and the reason matters here. The second imperative is explicitly about instantiating those standardized definitions into real objects, connecting those objects through relationships, and persisting the history of both the data and the context around it.

CESMII is direct about the sequencing: you don't reach the third imperative, exposing smart interfaces to applications and AI, until the relationship work in the second is done. A library of well-defined pump types with no relationships between them doesn't tell you what feeds what, what depends on what, or what happens when something fails.

An SM Profile defines what something is. It's a description, a template, a type. Operational relationships define how everything works together, how the individual instances of those types actually interact in a real, specific plant. Both are necessary, and neither one substitutes for the other. Without relationships, profiles become isolated descriptions. You can have a beautifully standardized definition of every asset type in your plant, and still be completely unable to answer "what happens if this valve closes," because that question isn't about any one asset's definition, it's about how instances of different asset types are connected to each other in a specific, physical, as-built configuration.

Without creating typed relationships, they become inconsistent and impossible to govern. If every engineer invents their own naming and structure for "feeds" or "powers" or "maintained by," you end up with a relationship model that's just as fragmented as the tag-naming chaos everyone already complains about, just one layer up.

This isn't a call to adopt a specific framework. It's worth knowing that a well-funded, industry-wide effort looked hard at this exact problem and arrived at essentially the same conclusion: standardized definitions and explicit relationships are two separate, equally necessary pieces of work, and most organizations have historically only done the first one.

Why Basic Physical Hierarchies Aren't Enough

Physical hierarchies have earned their place in manufacturing. ISA-95's Enterprise → Site → Area → Line → Cell structure provides a common way to organize operations. Historian asset trees help operators navigate equipment. MQTT topic namespaces bring order to distributed systems. OPC UA Information Models and companion specifications go even further, introducing typed references that describe far more than simple containment. Modern manufacturing standards have long recognized that an operation consists of equipment, people, materials, processes, and the relationships between them.

The challenge isn't that these standards or structures are wrong. The challenge is that most implementations stop at the hierarchy. Containment is intuitive, answering questions like, where is this asset? Which line does this machine belong to? Which site owns this equipment? Those questions matter, and a well-designed hierarchy answers them efficiently.

But manufacturing decisions rarely depend on containment alone. When scrap increases, production slows, or reliability declines, the questions quickly change. What feeds this machine? What downstream process depends on it? Which electrical source powers these assets? Which maintenance event preceded this failure? Which operators were assigned to this line? Which material lots passed through the process? These are all relationship questions, but they exist in entirely different dimensions.

None of these questions can be answered by containment relationships alone. They require traversing different relational dimensions of the operation, each describing a different way resources interact.

A way in which you can think about relational dimensions (just a few examples and their relationship descriptors):

Physical: expressed as contains
Process: expressed as feeds
‍Electrical: expressed as powers
Utilities: expressed as supplies
‍Material: expressed as consumes and produces
Personnel: expressed as assigned to
‍Maintenance: expressed as installed on and replaced by
Automation: expressed as controlled by  
‍Safety: expressed as protects
Business: expressed as produces
‍
ISA-95 introduces the concept of a Resource Relationship Network, recognizing that manufacturing resources exist within a network of typed relationships rather than a single hierarchy. Importantly, the standard does not attempt to define every possible relationship. Instead, it provides a framework for organizations and industries to define relationship types that accurately describe how their operations work.

Unfortunately, most manufacturing software operationalizes only the physical hierarchy. The remaining relationships still exist, but they're scattered across engineering drawings, PLC programs, CMMS databases, historians, MES systems, spreadsheets, SQL joins, and, perhaps most commonly, the experience of people who have spent years learning how the plant operates.

As a result, every new analytics project, reporting initiative, integration effort, or AI pilot ends up reconstructing those relationships from scratch. One team builds SQL joins between equipment and maintenance records. Another hardcodes process flow into an application. Someone maintains a spreadsheet mapping motors to MCCs. None of these solutions are inherently wrong, but each captures only a small piece of operational knowledge, isolated from everything else.

The opportunity is not to replace the hierarchy. The hierarchy remains an essential relational dimension and often the starting point for navigating an operation. The opportunity is to elevate the other relationship dimensions to the same level of importance, treating them as reusable, governed knowledge instead of project-specific implementation details. When that happens, organizations stop rebuilding operational understanding one application at a time and begin creating a shared foundation that every future initiative can build upon.
‍

Knowledge Doesn't Live in the Node. It Lives in the Relationship

Here's the part of this argument that changes how you look at a plant once you've internalized it. A pump, by itself, is not very interesting. It has a model number, a manufacturer, a capacity rating, maybe a maintenance schedule. That's a data sheet, not operational knowledge. Now consider the same pump once you know it feeds a specific tank, is powered from a specific MCC, is maintained by a specific team on a specific interval, supports a specific line, supplies a process step with tight tolerances, and belongs to a redundancy pair with a second pump that takes over if this one fails.

Nothing changed about the pump. Every fact just added is a relationship, not a property of the pump itself. And yet the pump went from a line item in an asset register to something you can actually reason about. You now know what happens if it fails, who to call, what else might be affected, whether there's a backup. None of that came from the pump's own attributes. All of it came from how the pump relates to everything around it.

This holds almost everywhere in a plant. A sensor's value is nearly meaningless without knowing what it's measuring, on what equipment, under what conditions. An operator's name on a shift schedule means little without knowing what they're qualified to run. A maintenance work order means little without knowing what asset it applied to and what that asset does downstream.

The uncomfortable implication is that most manufacturing data systems have spent decades getting extremely good at storing nodes, tags, and records, and comparatively little effort modeling the relationships between them explicitly. The relationships exist. They're just not written down anywhere a system can use. They live in drawings, spreadsheets, and the heads of people who've been on the floor long enough to have absorbed them.

Relationships Deserve to Be Treated as Real Things, Not Afterthoughts

If relationships are where the knowledge actually is, they can't keep being treated as thin, disposable connections between the "real" objects. They need the same seriousness as the entities they connect.

Consider a relationship called "Feeds," connecting a tank to a mixer. In most systems today, if it's captured at all, it's a line on a drawing or an implicit assumption in code. But think about everything that relationship needs to carry to be useful: maximum flow rate, normal operating direction, line capacity, whether there's an isolation valve and where, a reference to the engineering drawing, the dates this configuration has been valid, the original design intent versus how it's actually operated, and its current status.

That's not metadata off to the side of the "real" information. It's engineering information, and it deserves the same rigor as the tank or mixer themselves. A relationship type should support validation, so "Feeds" can't connect two things that make no physical sense. It should support inheritance, so specialized versions don't get invented from scratch. It should be versioned, so you can tell what the configuration looked like six months ago. It should carry permissions, because who can change a documented electrical dependency isn't the same population who can update a shift schedule. It should have a lifecycle, so a decommissioned connection gets marked retired rather than quietly disappearing. And it should record source authority, so anyone looking at it knows whether it came from an as-built drawing, a live control mapping, or someone's best guess during a walkthrough.

Once you start treating relationships this way, the earlier scrap investigation looks completely different. The electrical dependency between the extruder and its MCC isn't a fact someone has to remember or dig up from a drawing. It's a governed piece of information with the same status as the extruder's own asset record. The same goes for the process flow connection, the maintenance history, the personnel assignment. None of it has to be rediscovered, because none of it was ever allowed to live only in someone's memory in the first place.

Why Strong Typing Is What Makes Any of This Scale

There's a trap waiting for anyone who takes the last section seriously and starts modeling relationships without also thinking about typing. It goes like this... five different engineers, working on five different lines, all decide to model the connection between a tank and a mixer. One calls it "Feeds." Another calls it "FlowTo." A third calls it "Supplies." A fourth writes "MovesMaterialTo." A fifth just uses a generic "ConnectedTo" and moves on.

Every one of those relationships might be correct, and every one is now unusable by anyone outside the person who created it. There's no way to query "show me everything this tank feeds," because the answer is scattered across five semantically identical but syntactically different names. It's the exact failure mode that produces tag-naming chaos in historians, just one level up the stack.The fix is the same one that's worked in software engineering for decades: strong typing, applied to both the entities and the relationships connecting them. An Entity Type defines what a valid "Pump" looks like and what properties it has, or must have. A Relationship Type defines what a valid "Feeds" relationship looks like, including what kinds of entities it can connect and what properties it must carry. A Property Type plus a Data Type defines what a valid "Maximum Flow Rate" value looks like, so it isn't sometimes a number, sometimes a string, sometimes missing units.

Typing gives you consistency, because "Feeds" means the same thing everywhere. It gives a shared vocabulary, so a new engineer can understand what relationships are possible without interviewing five other people. It gives validation, so you can't create a relationship that doesn't make physical sense. It gives governance, because someone can own the definition of "Feeds" the same way someone owns "Pump." And it gives reuse, because a relationship type defined once can be instantiated on every other line and every other plant without reinventing it.

The same inheritance and specialization that make typing valuable for entities apply to relationship types. A "Feeds" relationship for liquid transfer might specialize a more general "Supplies" relationship, which might share a base type with "Powers" in how it handles capacity and direction, even though electricity and fluid flow are physically nothing alike. Getting this right determines whether a relationship model can grow past a single line or plant without collapsing into the same inconsistent mess it was meant to replace.

The Model Never Finishes, and That's the Point

There's a temptation, once you've modeled the relationships for one line or plant, to treat the project as complete. It isn't, because the operation never stops changing. New equipment gets installed. New lines get commissioned. The company migrates historians or adds a wave of sensors during a modernization push. A new plant gets acquired, with its own naming conventions and its own undocumented tribal knowledge. Someone kicks off an AI initiative that needs to understand the operation well enough to reason about it, which means it needs exactly the relationship structure this article has been describing.

Every one of those events adds new entities, new relationships, or both. Without governance around how the model grows, it doesn't stay useful. It becomes exactly what this article has been arguing against: another system that starts clean and slowly turns into a legacy mess nobody fully trusts, because nobody can say with confidence whether it's still accurate. This isn't a reason to avoid building the model. It's a reason to build it expecting it to keep growing, with the same discipline you'd expect from any other long-lived piece of infrastructure.

Borrow From Software Engineering, Because This Problem Isn't New

Software engineers solved a version of this problem decades ago, and manufacturing doesn't need to solve it from scratch. A developer building a large application doesn't define every object from first principles every time. They define reusable classes, and every instance inherits its structure and behavior. They organize related classes into libraries, so tested functionality gets reused instead of rewritten. They use namespaces to keep large systems from colliding when two teams pick the same name for two different things. They use composition to build complex objects from simpler, well-understood pieces rather than one monolithic block. They version code deliberately, so a change in one place doesn't silently break something depending on it elsewhere. And they manage dependencies explicitly, so it's always clear what relies on what.

None of this is exotic. It's the ordinary discipline of building software that has to survive more than one developer and more than one release cycle. Manufacturing operations need the same discipline applied to operational knowledge. Instead of every plant defining its own version of "Pump" and its own version of "Feeds," an organization defines reusable entity and relationship types once, then instantiates them repeatedly across lines, areas, and sites. A new plant doesn't start from a blank page, it starts from the organization's existing library of types, adapted to its own equipment. A new relationship type isn't invented from scratch every time an engineer hits a new kind of connection, it's built as a specialization of something that already exists.

As models grow across multiple sites and eventually across an entire organization, this kind of governance stops being a nice-to-have and becomes the only thing standing between a genuinely reusable operational knowledge base and a sprawling, inconsistent mess that's technically comprehensive and practically unusable.

The Point Of All Of This

Go back to the scrap investigation one more time. What made that morning take four plus hours instead of thirty minutes wasn't a lack of data. The plant almost certainly had a historian full of process values, a CMMS full of maintenance records, an ERP full of order and lot information, and a scheduling system that knew exactly who was assigned where. Every fact needed to solve the problem already existed somewhere.

What didn't exist was the connective tissue between those facts. Nothing in any of those systems knew, on its own, that this extruder is powered by that MCC, that this operator had never run this line-and-product combination before, or that this resin is sensitive to humidity during this process stage. Those relationships were real and they mattered, but they lived entirely in the space between systems, reconstructed by a person under time pressure from memory, documentation, and a few phone calls.

That's the pattern worth taking away from this. Every significant manufacturing question, sooner or later, turns into a relationship problem, not a data availability problem. The data is usually there. The connections between it almost never are, at least not durably enough to survive the person who knew them moving to a different role.

Organizations that explicitly model those relationships, treat them with the same rigor as the entities they connect, type them so they're consistent and reusable, and govern them so the model keeps growing without falling apart, stop rebuilding the same operational knowledge over and over. They stop paying the half-a-day tax on every investigation, the multi-week tax on every analytics project, and the multi-month tax on every integration effort that has to rediscover what feeds what and who's responsible for what.

Instead, they end up with something genuinely valuable; a durable understanding of how the business actually works, one that gets more valuable every time someone adds to it instead of being thrown away and rebuilt. Dashboards get simpler to build, because the relationships they depend on already exist. Reporting gets more consistent, because different reports pull from the same underlying model instead of separate reconstructions of the truth. Integrations get easier to maintain, because the relationships they rely on are documented and governed rather than buried in code.

And, increasingly, AI initiatives get a real chance of succeeding, because a system trying to reason about a manufacturing operation needs exactly what a new engineer needs on their first day: not just a list of what exists, but an understanding of how it all connects. AI isn't the reason to do this work. It's simply one more consumer, arriving late, of an understanding that should have been built for the humans doing the investigating long before any algorithm asked the same questions.