How to Use ISA-95 and Knowledge Graphs in Manufacturing

Most manufacturers do not have a data problem. They have a context problem.

The plant is already generating signals, events, orders, quality records and maintenance logs by the second. The real pain starts when someone tries to connect it all: Enterprise Resource Planning (ERP) says one thing, the Manufacturing Execution System (MES) says another, Programmable Logic Controller (PLC) tags use local naming conventions. Every site has its own version of “standard”.

That is where ISA-95 (the International Society of Automation standard for enterprise-control integration) becomes useful. It is not a compliance badge or a dusty pyramid diagram. It is a practical way to structure manufacturing information so it scales across systems, sites and analytics use cases. This article draws on an episode of the Manufacturing Hub podcast. Its guest, David Schultz, is a principal consultant who works on ISA-95 implementations, so he has a commercial interest in the topic. He framed ISA-95 as a flexible integration standard. It helps manufacturers define common models, relationships and exchanges between business and operational systems. He then connected that foundation to a more modern topic: knowledge graphs.

For operations leaders, quality engineers and production managers, the implication is simple: if your data model is messy, your Artificial Intelligence (AI) strategy will be messy too.

This article breaks down what ISA-95 actually is, why it is often misunderstood, where it delivers a return on investment, and how knowledge graphs may help manufacturers turn disconnected data into something both machines and humans can reason about.

Key Takeaways

• ISA-95 is not the automation pyramid. The familiar layered diagram is widely used, but the standard itself is more flexible and functional than that image suggests.
• The standard’s core value is data consistency. It helps ERP, MES, control systems and other applications exchange information using shared structures instead of one-off mappings.
• Start with Parts 1 and 2. They define scope, models and foundational concepts before you get into activities and exchanges.
• You do not need to implement all of ISA-95 at once. A bounded use case, such as production order exchange, genealogy or track-and-trace, is usually the right starting point.
• ROI comes from lower integration friction. Standard models reduce rework, simplify governance and make future analytics or AI projects easier to scale.
• Knowledge graphs are useful when relationships matter. They are not a replacement for historians or relational databases, but they can add meaning across disparate systems.
• AI performs better when the meaning is already defined. If equipment, materials, processes and events have common names and known relationships, machine reasoning becomes more reliable.
• Brownfield plants should evolve, not rip and replace. Add standards progressively around new projects and interfaces rather than trying to rebuild the entire stack in one go.
• The biggest bottleneck is not just technology. It is ownership, governance and the absence of a shared language for manufacturing data.

What ISA-95 Actually Is, and What It Isn’t

If your first exposure to ISA-95 came from a LinkedIn graphic showing a neat stack from sensors to ERP, you are not alone. That image is often treated as if it is the standard.

It isn’t.

What is ISA-95? ISA-95, also published internationally as IEC 62264 (from the International Electrotechnical Commission), is a standard for integrating business systems with manufacturing operations. It defines common models and terms for production, maintenance, quality and inventory activities. That lets an ERP system, an MES and other applications exchange information without a custom mapping for every single interface.

One of the strongest points from the discussion was that ISA-95 is fundamentally about integrating business systems and manufacturing systems. ISA-95 brings structure to information exchange between enterprise applications and plant-floor operations. It is less about a rigid hierarchy and more about functional boundaries, models and interfaces.

That distinction matters because many manufacturers dismiss ISA-95 too early. They assume it demands a top-down architecture, point-to-point layer hopping, or a full MES overhaul. In reality, the standard is more modular than that.

Why the pyramid causes confusion

The pyramid is useful as a teaching tool, but it creates two bad habits:

1. It implies that data must move only layer-by-layer
2. It makes the standard look more rigid than it is

In practice, ISA-95 defines what kinds of activities, resources and exchanges exist. It does not prescribe one network design or one software stack.

To be fair to the pyramid, Part 1 does contain the Level 0 to 4 functional hierarchy that it is drawn from. The point is that the standard does not require data to hop from level to level.

That is especially important for modern manufacturers running hybrid environments with historians, cloud analytics, APIs, edge devices and event-driven architectures. If your team thinks ISA-95 belongs to an older era of monolithic MES deployments, you may be ignoring a standard that is still highly relevant precisely because it helps tame complexity.

ISA-95 vs Purdue: Stop Mixing Up Architecture and Information Models

Another source of confusion is the tendency to blur ISA-95 with the Purdue model.

ISA-95 derives from the Purdue Enterprise Reference Architecture (PERA), but the two solve different problems.

PERA, developed at Purdue University, defined functional levels for an enterprise. ISA-95 Part 1 builds its functional hierarchy on it. Cyber security work later reused those levels for network segmentation. That reuse helps answer questions like: what should be separated, what belongs on which network, and how should control systems be isolated from enterprise traffic?

ISA-95, by contrast, focuses on how manufacturing systems represent and exchange information.

That difference is not academic. It affects project decisions.

• If you are trying to decide where systems should sit, you are leaning towards architectural concerns.
• If you are trying to define what a production order, material lot, equipment capability or performance response should look like, you are in ISA-95 territory.

A lot of bad digital transformation work happens when teams use architecture diagrams as a substitute for information modelling. They are not interchangeable.

Why ISA-95 Matters to Metals and Steel Operations

For metals manufacturers, the business case is not abstract.

You are dealing with:

• Multi-stage processes
• Tight margin pressure
• Quality variation that can create high-value scrap
• Traceability demands
• Maintenance dependencies
• Carbon reporting pressure, including Carbon Border Adjustment Mechanism (CBAM) expectations for consistent data

In that environment, disconnected data is not just annoying. It is expensive.

A production line may already capture temperatures, speeds, chemistry, energy use, material movements and operator interventions. But if those signals are not linked to orders, heats, coils, lots, work-in-progress (WIP) or quality outcomes in a consistent way, then every report becomes a manual reconciliation exercise.

GoSmarter, built by Nightingale HQ, applies the same idea to certificates. Its MillCert Reader treats the heat number as the shared identifier, much as ISA-95 treats a material lot. Certificate data links to the matching stock in Metals Manager. Cutting Plans work from that same stock, so the heat stays attached to every piece you cut.

It works alongside your existing ERP and spreadsheets: upload certificates as PDFs or photos, bring stock and orders in by CSV, and pull data out through the API. That mirrors the incremental, brownfield-friendly approach this article recommends. For a wider look at that choice, see MES vs specialist tools and GoSmarter vs generic ERP planning modules.

On cost, the Workshop plan is £350/month rolling, or £280/month billed annually. Cutting Plans starts on the Production plan, from £950/month. Typing a certificate by hand takes 5 to 10 minutes. At 20 certificates a week, that is roughly 7 to 14 hours a month of admin. Value those hours at your own loaded labour rate and compare the total with the plan price. The ROI hub shows the full working.

For IT teams, you can export your data, and bulk-import stock and orders from CSV, through a REST API (Representational State Transfer Application Programming Interface). GoSmarter stores your data on Microsoft Azure in UK data centres. AI extraction may run outside the UK. We use uploaded certificates, de-identified, to improve our own extraction models. We never share them with other customers or third-party AI providers. Microsoft does not train on your data.

ISA-95 helps by giving operations a common data vocabulary across four major operational domains highlighted in the discussion:

• Production
• Maintenance
• Quality
• Inventory

That matters in steel because margin protection often depends on decisions made across those boundaries. A quality deviation may trace back to maintenance conditions. Inventory timing may affect WIP handling. Production performance may only make sense when matched against the schedule requested upstream.

Without structure, every analysis starts from scratch.

Where the ROI Actually Comes From

When executives ask about Return on Investment (ROI), the wrong answer is often “standardisation is best practice”.

That is true, but not persuasive.

The stronger answer is this: ISA-95 reduces the cost of making data usable more than once.

In the discussion, Schultz pointed out that teams often model data around their immediate application. That is natural, but it creates a long-term mess. One team creates a bespoke model for one tool, another does the same for a different site, and eventually everyone needs a fourth abstraction layer just to reconcile the first three.

That is where cost piles up:

• extra integration work
• brittle mappings
• duplicated logic
• poor governance
• slow onboarding of new applications
• delayed analytics projects

Practical ROI levers

For manufacturers, the return tends to show up in these areas:

Faster integration between systems

Production orders, goods issue/receipt, genealogy and performance data can move with less custom translation.

Better governance

A shared model reduces endless debates over naming, ownership and interpretation.

Easier scaling across plants

What works at one site is easier to replicate if the underlying data model is not unique to one programmer, one integrator or one historian schema.

Stronger analytics and AI readiness

You spend less time on cleansing and context-building, and more time on solving real process problems.

Lower risk during software changes

If your logic sits inside one vendor’s stack, replacing a component becomes painful. A standard model provides some insulation.

For “cheque signers”, this translates into a simpler argument: less integration waste, less scrap from misunderstood data, and fewer dead-end digital projects.

Where to Start: A Practical ISA-95 Adoption Path

One of the more useful parts of the conversation was the guidance on where to begin inside the standard itself.

ISA-95 is not a one-document read. It spans multiple parts, and that can feel intimidating. The recommendation was clear: start with Parts 1 and 2.

Part 1: Scope and boundaries

This helps teams understand what the standard covers, what functions sit where, and what kinds of activities fall inside the model.

Part 2: Models and objects

This is where the building blocks appear: resources, information models and the structures that define manufacturing entities.

Once those are understood, teams can move into:

Part 3: Activity models

This covers the operational domains and shows how teams define and measure activities.

Part 4: Object models and attributes for MOM integration

Manufacturing Operations Management (MOM) integration is the Level 3 job. This part includes work masters and workflow specifications that link the four domains at Level 3.

Then later:

Part 5: Business-to-manufacturing transactions

Part 5 defines the transactions between business and manufacturing systems. These are the “verbs”, applied to the “nouns” from Parts 2 and 4.

Part 6: Messaging service model

Part 6 defines a technology-neutral messaging service model.

Eight parts are published. Part 7 covers the Alias Service Model and Part 8 covers Information Exchange Profiles. Schultz says Part 9 is in progress.

For brownfield operations, that sequence matters. Too many teams jump straight into integration technology, such as Application Programming Interfaces (APIs), Message Queuing Telemetry Transport (MQTT) messaging, Extract, Transform, Load (ETL) pipelines and dashboards, before they agree on what their objects and relationships actually are.

That is backwards.

The Best First Use Cases Are Boring, and That’s a Good Thing

There is a temptation to make your first ISA-95 project ambitious. Resist it.

A recurring theme in the discussion was to pick a bounded use case and expand from there. Good first projects include:

• Sending production orders from ERP to MES
• Capturing actual vs plan at a line or asset level
• Building genealogy or track-and-trace for a specific process area
• Standardising a small slice of inventory movement
• Creating a reusable model for one machine family

These are not flashy projects. They are useful projects.

For steel and metals operations, a smart first step might be one high-value area where quality, production and inventory meet - for example:

• slab-to-coil genealogy
• route-based WIP visibility
• standardised downtime and actual production response for one critical line

The point is not to “roll out ISA-95”. The point is to solve one integration problem in a way that can be reused.

Do Smaller Manufacturers Need ISA-95?

Not always.

That nuance matters. Schultz explicitly noted that he does not use ISA-95 for every situation. In some smaller environments, the operational scope is limited, the number of stakeholders is manageable, and bespoke approaches are still practical.

That honesty is important because over-engineering is real.

If you have one site, a handful of systems and a stable team, a complete standard-led modelling exercise may be more than you need. But even then, the principles behind ISA-95 can still improve how you structure data.

A better question than “Should we fully adopt ISA-95?” is:

Where are custom models starting to create friction?

If you are seeing any of the following, the case gets stronger:

• multiple sites defining the same concepts differently
• repeated rework for each new integration
• analytics teams spending months on data wrangling
• disagreements over what “actual”, “scheduled”, or “good product” means
• vendor lock-in around one software stack

Once those symptoms appear, standards stop feeling theoretical.

Why Adoption Still Lags

If ISA-95 is so useful, why is adoption uneven?

Three reasons came up.

1. Misunderstanding

Many people assume the standard is rigid, outdated or tied to a single architecture pattern. That misconception alone keeps teams away.

2. Cost and accessibility

Formal standards often sit behind paywalls, and that becomes a barrier for smaller teams or self-directed engineers. Schultz also noted that copyright limits how far AI tools can use the standard.

3. Ownership gaps

The host, Vladimir Romanov, raised this one from his own experience. It may be the biggest issue. At many plants, no one truly owns the data model end-to-end. Controls engineers focus on safe operation and uptime. IT focuses on enterprise systems. Business teams focus on reporting. Integrators deliver the project in front of them.

The result is a vacuum.

And in that vacuum, local naming conventions and one-off mappings flourish.

For younger operations and engineering leaders, this is often the real frustration: you can see the problem clearly, but the organisation has no natural seat for “manufacturing data ownership”.

Knowledge Graphs: Why They’re Suddenly Everywhere

Once the conversation shifted from ISA-95 to knowledge graphs, the logic became clearer.

If ISA-95 provides a common language, knowledge graphs offer a way to store and query relationships explicitly.

That matters because manufacturing data is not just about values. It is about connected meaning.

A tank level is not just a number. It belongs to a tank. That tank is part of a process segment. It is fed by one pump, discharged by another, associated with specific materials, and linked to quality outcomes and work orders.

Traditional databases can store all this, but relationships are often implied through keys, schemas and application logic. Graph approaches treat the relationship itself as important.

The simplest way to think about a graph

A graph stores:

• a thing
• the relationship
• another thing

In technical terms, that is often described as subject, predicate and object.

The example used in the discussion was a family tree because it is intuitive:

• Person A is parent of Person B
• Person B is sibling of Person C

In manufacturing, the same logic applies:

• Tank 101 feeds Reactor 3
• Coil ABC originated from Heat 456
• Sensor X belongs to Line 2
• Work order 789 uses Material Lot Y
• Inspection step Z verifies Product Grade Q

That is where knowledge graphs become interesting. They do not replace every other database. They make cross-domain context easier to work with.

Why Graphs Matter More in Process and Complex Operations

Graph thinking is especially relevant where relationships are messy, dynamic or high consequence.

That includes many metals and process manufacturing environments where:

• one failure can affect multiple downstream stages
• root causes span assets, materials and operating conditions
• time-series signals alone do not explain why a deviation happened
• analytics need process context, not just raw measurements

A conventional historian is still the right place for high-frequency time-series data. A relational database still makes sense for transactional records. The graph layer becomes useful when you need to ask more contextual questions, such as:

• Which assets were involved in this quality event?
• What materials, route steps and setpoints were common across off-spec lots?
• What other process segments depend on this piece of equipment?
• Which events upstream are often associated with downstream defects?

That is not a replacement strategy. It is a fit-for-purpose architecture.

ISA-95 and Knowledge Graphs Are a Natural Pair

Here is where the discussion became especially practical.

ISA-95 already defines many of the core manufacturing concepts needed for graph-style modelling. It names four resources:

• equipment
• personnel
• materials
• physical assets

It also defines the information that describes and exchanges them:

• operations definitions
• process segments
• capabilities
• schedules
• performance responses

If those entities already exist in a common standard, then graph models do not need to invent meaning from scratch. The relationships are easier to define because the ontology is not entirely bespoke.

This is one of the strongest strategic arguments for using standards before AI.

Without a common model:

• every AI project must rediscover terms
• relationships need to be inferred from incomplete context
• meanings drift by site, department or application

With a common model:

• the machine has less ambiguity
• the data is easier to unify
• the effort shifts from cleaning to reasoning

That does not make AI magic. It makes AI less confused.

What This Means for AI in Manufacturing

There was a useful dose of scepticism in the discussion around AI claims.

Schultz’s message on AI was blunt: tools such as ISA’s own large language model still need you to know the right model, and they cannot stand in for one.

That is worth repeating because too many industrial teams are being told the opposite.

Large language models and machine learning tools can help classify, summarise, correlate and reason, but only if the data they see has stable meaning. If your systems use “equipment”, “machine”, “line”, “unit” and “asset” interchangeably, the model has to guess. Sometimes it guesses well. Sometimes it does not.

Standards and knowledge graphs reduce that guesswork.

Where this could help in practice

For metals and steel operations, an ISA-95-informed graph approach could support:

• Defect correlation across route, asset, operator, material and environmental context
• Scrap analysis tied to process segment relationships, not just timestamps
• Traceability across lots, heats, coils or batches
• Maintenance impact analysis linking asset events to quality or throughput outcomes
• CBAM and sustainability reporting where emissions, energy use and production records must align across systems

The important caveat is that none of this happens automatically. The hard work still needs doing up front. You must define the models before you expect intelligence from the outputs.

Technology Choice: ISA-95 Does Not Lock You Into One Stack

One of the more reassuring points for pragmatic engineers is that ISA-95 is not prescriptive about technology.

It does not force one protocol, one vendor or one integration method. Push, pull and pub/sub patterns can all fit. The standard is about representation and exchange, not brand loyalty.

That matters because many manufacturers are trying to modernise incrementally:

• legacy PLCs at the edge
• historians already in place
• MQTT for lightweight messaging
• APIs to cloud or enterprise applications
• mixed-vendor MES and ERP environments

In that reality, a standard model is more valuable, not less. It gives teams a way to modernise around interfaces without rebuilding everything at once.

A Smarter Brownfield Strategy: Replace Friction, Not Everything

For most real factories, especially in metals, the answer is not “start over”.

It is: add structure where the pain is highest.

A sensible brownfield strategy looks like this:

1. Identify one painful data hand-off

For example, production order execution, quality genealogy or material movement visibility.

2. Model the key entities and relationships

Use ISA-95 concepts where they fit.

3. Leave legacy systems in place

Do not rip out systems that are still doing their primary job.

4. Add a translation or context layer

This might include canonical objects, event definitions or graph relationships.

5. Expand only after the first use case proves useful

Once actual users trust the structure, extension becomes easier.

This is what Schultz calls the strangler fig method (a term from Martin Fowler). It is often more realistic than platform-first transformation programmes that promise everything and deliver dashboards no one trusts.

The Bigger Lesson: Standards Are Becoming Infrastructure for Meaning

The most important idea in the discussion was not really about one standard or one database style. It was this:

Manufacturing is moving into a phase where shared meaning matters as much as shared connectivity.

For years, industrial digital projects focused on getting data out:

• connect the PLC
• collect the tags
• centralise the historian
• mirror the database
• expose the API

That phase is no longer enough.

The new challenge is to make data understandable across people, applications and algorithms. That requires models, relationships, governance and discipline. Standards like ISA-95 help create that baseline. Knowledge graphs may become one of the more useful ways to operationalise it.

Not for hype. For context.

Conclusion

ISA-95 is often treated as either old news or unnecessary complexity. That is a mistake.

Used well, it is a practical framework for structuring manufacturing information so that systems, sites and teams can work from the same operational language. That creates value long before any AI project starts. It reduces integration friction, improves governance and makes future analytics less painful.

Knowledge graphs add another layer of potential by making relationships explicit across equipment, materials, processes and events. But they are not a shortcut around foundational work. If anything, they make the need for good modelling even more obvious.

For metals and steel manufacturers under pressure to improve yield, reduce scrap, protect margin and meet sustainability reporting expectations, the message is clear:

Better data collection is not enough. Better data structure wins.

Frequently Asked Questions

Source: “ISA 95 Standards - What are they really? - MFG HUB 274”, Manufacturing Hub, YouTube, Sep 10, 2026, https://www.youtube.com/watch?v=pk3FJn1nmsw