How to Design an Ontology for Manufacturing Operations

In the first article, I explained that an ontology is a formal, machine-readable model of entities that exist in your manufacturing domain, how they relate to each other, and what rules apply to them. And that one of the best examples of applications is that when made available to AI agents, it gives them a structured representation of operational reality, helping these probabilistic AI systems operate within clearly defined guardrails.

But how do you actually design an Ontology?

The first, and most important, decision is whether you should take a top-down or bottom-up approach?

Choosing an Ontology-Building Approach

There are two common approaches to building an ontology: top-down and bottom-up.

In a top-down approach, domain experts and other relevant stakeholders work together to model the domain. They identify the important concepts, define their properties, describe the relationships between them, and establish a shared vocabulary.

In theory, this allows you to create a comprehensive model of your manufacturing operations before implementing it.

In practice, however, trying to understand and formalize the entire language of manufacturing operations upfront is painstaking, time-consuming, and difficult to scale. No single person or team fully understands the operational reality across every plant, production process, and business domain.

Even if you successfully captured that reality, you would only be representing the organization as it exists at that moment. Equipment, processes, responsibilities, and operational practices will continue to change.

The alternative is a bottom-up approach.

Here, you add concepts, properties, and relationships incrementally as they appear, change, or become relevant.

For example, when a new machine or capability is added to a production line, you add it to the model. When you discover that, despite what the plant diagram shows, a blender actually feeds from Holding Tank 1 rather than Holding Tank 2, you update that relationship. When you learn which conditions operators actually respond to during production, you capture that operational knowledge as well.

This approach is more adaptable and better reflects the reality of a changing manufacturing environment.

However, it introduces another risk. Without shared rules and governance, different teams may describe the same concepts in different ways. One site may define a machine as an Asset, another as Equipment, and another as a Work Unit. Over time, the ontology can become an inconsistent collection of locally defined concepts that is no longer useful across the organization.

The most practical solution is therefore a hybrid approach.

You begin by defining a small core ontology containing a limited set of stable, highly abstract concepts and relationships. Individual operational domains can then extend that foundation from the bottom up as new requirements, assets, processes, and relationships emerge.

This gives teams the flexibility to model their operational reality without losing consistency across the organization.

Defining The Core Concepts of a Manufacturing Operations Ontology

The first step is to define the core ontology. The key requirement is that it remains small and precise enough to constrain interpretation, while also being extensible enough to support different manufacturing domains without forcing them into one oversized universal schema.

At a high level, most manufacturing operations can be described using a relatively small set of fundamental concepts. Based on this, I would structure the core manufacturing ontology around nine concepts: Process, PhysicalEntity, OperationalEntity, Location, Capability, Role, Agent, Event, and State.

Let us examine each of these concepts in more detail.

1. Process

A Process represents work that happens over time and creates, transforms, moves, inspects, maintains, or otherwise affects something. For example, Mixing, Welding, Packaging, Inspection, Cleaning, and Material transfer.

A process may contain subprocesses and may be executed manually, automatically, or through a combination of people, equipment, and software.

2. PhysicalEntity

A PhysicalEntity is a physical entity that exists within the manufacturing environment. For example, Material, Product, Equipment, Tool, Container, and Sample.

The concept describes what something is, not the role it plays in a particular process.

3. OperationalEntity

An OperationalEntity is an informational object that directs, constrains, describes, or records operational work.For example, Order, Schedule, Recipe, Procedure, Specification, Work instruction, Production record, Inspection result.

Operational entities can be divided broadly into those that describe intended work and those that provide evidence of completed work.

4. Agent

An Agent is something capable of participating in, controlling, or making decisions about a process. For example, Personnel, Team, Equipment controller, Software application, and AI agent.

An agent does not necessarily perform the physical transformation itself. It may supervise, coordinate, control, approve, or make decisions about the process.

Equipment can be both a PhysicalEntity and, where it acts autonomously, a type of Agent.

5. Location

A Location represents where an entity, agent, or process exists or occurs. For example, Enterprise, Site, Area, Work center and Work unit. The ISA-95 equipment hierarchy model would extend this concept.

6. Capability

A Capability describes what an entity, agent, or organizational unit is able to do. For example, Mixing capability, Filling capability, Temperature-measurement capability, Sterilization capability, Inspection capability. This separates what a resource can do from the process it is currently executing.

7. Role

A Role describes how an entity participates in a particular process or relationship. For example, Input, Output, Performer, Observer, Controller, Consumer, and Producer.

This is important because the same entity may play different roles in different contexts.

For example, a chemical may be an input material in one process, a cleaning medium in another, and a finished product in another. Modelling roles prevents us from permanently classifying it according to only one use.

8. Event

An Event represents something operationally significant that occurred at a particular point or interval in time. For example, Process started, Order released, Material consumed, Alarm activated, Inspection completed and Equipment failed.

Events provide the time-based operational evidence needed for analytics, traceability, and agentic decision-making.

9. State

A State describes the condition of an entity or process during a period of time. For example, Running, Idle, Failed, Available, In production, Awaiting inspection, Released, Quarantined

Events usually cause or indicate state changes:

EquipmentFailureEvent CHANGES_STATE Equipment

Equipment STATE Failed

The core consists of concepts that are abstract enough to describe manufacturing-wide semantics, but concrete enough to support useful operational models.

More importantly, it does not attempt to define every machine type, failure mode, material property, inspection method, process parameter, or regulatory rule. Those belong in extensions.

Defining The Core Relationships of a Manufacturing Operations Ontology

Once we have defined the core concepts, the next step is to define the relationships between them.

Concepts tell us what kinds of things exist in the manufacturing operations domain. Relationships tell us how those things are connected.

This is important because an ontology is not simply a list of manufacturing terms. Its value comes from expressing the meaning of the connections between processes, physical entities, operational entities, agents, locations, capabilities, roles, events, and states.

The requirement here is similar to the requirement for the core concepts. The relationships should be general enough to work across production, maintenance, quality, inventory, and other manufacturing domains, but precise enough to constrain how those domains represent operational reality.

Based on the nine core concepts, I would define the core ontology around the following relationships.

1. Process AFFECTS PhysicalEntity

The AFFECTS relationship describes a physical entity that is changed, handled, moved, inspected, maintained, or otherwise influenced by a process.

For example:

This is the broadest relationship between a process and a physical entity. More specific relationships such as TRANSFORMS, MOVES, INSPECTS, CONSUMES, or PRODUCES can be introduced through domain extensions. These more specific relationships can be defined as specializations of AFFECTS.

2. Entity PARTICIPATES_IN Process

The PARTICIPATES_IN relationship identifies an entity that is involved in the execution of a process.

For example:

Participation alone does not explain how the entity is involved. It simply establishes that the entity is part of the process context.

3. Entity PLAYS_ROLE Role

The PLAYS_ROLE relationship describes how an entity participates in a particular process, event, or operational context.

For example:

The relationship must be interpreted within a particular context. An entity does not necessarily play the same role permanently. For example, a chemical may play the role of an input material during a mixing process, a cleaning medium during a cleaning process, and an output during a purification process.

A more complete model would therefore associate the role with both the entity and the process:

4. Entity HAS_CAPABILITY Capability

The HAS_CAPABILITY relationship describes what an entity is able to do.

For example:

This separates the potential ability of an entity from the work it is currently performing.

A mixer may have a mixing capability even when it is idle. Similarly, a person may be qualified to perform an inspection without currently participating in an inspection process.

Capabilities may also include constraints or parameters.

For example:

Domain extensions may introduce more detailed concepts such as EquipmentCapability, PersonnelCapability, SoftwareCapability, or OrganizationalCapability.

5. Process REQUIRES_CAPABILITY Capability

The REQUIRES_CAPABILITY relationship describes the capability that must be available for a process to be executed.

For example:

This allows the ontology to distinguish between the definition of the required work and the specific resource selected to perform it.

For example:

From these relationships, an application or AI agent can determine that Mixer101 may be a suitable participant in the mixing process.

However, possessing the required capability does not automatically mean that the resource should be selected. Other factors such as availability, current state, capacity, location, authorization, maintenance status, and scheduling constraints may also need to be evaluated.

6. Process IS_GUIDED_BY OperationalEntity

The IS_GUIDED_BY relationship connects a process to an operational entity that defines, directs, constrains, or governs how the process should be performed.

For example:

Different kinds of operational entities may guide a process in different ways.

A recipe may define the sequence and parameters of a production process. A procedure may define the steps that personnel must follow. A specification may define acceptable limits. An order may authorize or request the work.

Domain extensions can therefore introduce more specific relationships such as:

These relationships can be modeled as more precise specializations of IS_GUIDED_BY.

7. Process PRODUCES OperationalEntity

The PRODUCES relationship describes an informational object that is created as a result of executing a process.

For example:

This relationship is important because manufacturing processes do not only produce or affect physical entities. They also generate operational evidence.

For example, an inspection may affect a physical sample while also producing an inspection result:

These records provide the evidence required for traceability, reporting, compliance, analytics, and AI-agent reasoning.

8. Process OCCURS_AT Location

The OCCURS_AT relationship identifies the location where a process takes place.

For example

A process may occur at more than one location. For example, a material transfer may begin in a storage area, pass through a transfer system, and end at a production unit.

More specific spatial relationships may therefore be introduced where necessary:

The core relationship remains general, while domain extensions can represent the spatial detail required by a particular use case.

9. Entity IS_LOCATED_AT Location

The IS_LOCATED_AT relationship describes where an entity currently exists or is installed.

For example:

Location may be permanent, temporary, or time-dependent.

For example, equipment may be permanently installed in a production area, while a material lot may move between receiving, storage, production, and quarantine locations.

Where location history matters, the location relationship should be represented with temporal information:

This allows the knowledge graph to answer not only where something is now, but where it was at a particular time.

10. Event OCCURS_DURING Process

The OCCURS_DURING relationship connects an event to the process execution during which it occurred.

For example:

This provides the operational context needed to interpret the event.

A temperature deviation, for example, cannot be fully understood from the measured value alone. We also need to know which process was running, which recipe applied, which material was being processed, and which equipment was involved.

Connecting the event to the process allows those relationships to be traversed through the graph.

11. Event AFFECTS Entity

The AFFECTS relationship identifies the entity whose condition, status, operation, or interpretation is influenced by an event.

For example:

An event may affect multiple entities.

For example, an equipment failure may affect the equipment itself, the process it was executing, the material being processed, the associated order, and the production schedule.

This relationship supports impact analysis by allowing an application or AI agent to traverse from an event to all affected operational entities.

12. Event CHANGES_STATE Entity

The CHANGES_STATE relationship expresses that an event caused or indicated a change in the state of an entity or process.

For example:

The state before and after the event should normally be represented explicitly.

For example:

A more precise model would represent state assertions with validity periods:

This avoids treating state as a permanent property and makes it possible to reconstruct state history.

13. Entity HAS_STATE State

The HAS_STATE relationship describes the condition of an entity or process during a particular period of time.

For example:

Because state changes over time, the direct relationship may be sufficient for simple current-state queries, but a StateAssertion should be used where historical accuracy, provenance, or auditability is required.

For example:

14. Process HAS_SUBPROCESS Process

The HAS_SUBPROCESS relationship represents the decomposition of a process into smaller processes.

For example:

This relationship may be used for both process definitions and actual process executions.

For example:

The relationship allows an application to move between a high-level operation and the detailed work from which it is composed.

Domain extensions may add sequencing relationships such as:

However, sequencing is distinct from decomposition. HAS_SUBPROCESS tells us that one process is part of another, while PRECEDES tells us the order in which processes occur.

15. Location CONTAINS Location

The CONTAINS relationship represents the spatial decomposition of manufacturing locations.

For example:

This allows applications to navigate from a specific location to its broader spatial context.

For example, if a Mixer is located in a ProcessingLine, and the ProcessingLine is contained in a ProcessingArea, which is contained in a Site, the graph can determine the complete physical location of the mixer.

The core should use this relationship for genuine spatial containment. Organizational structures, responsibility structures, scheduling groups, and resource groupings should be represented through separate domain concepts rather than being treated automatically as physical locations

The Resulting Core Relationship Model

The core relationships can therefore be summarized as:

Together, these relationships provide the minimum semantic structure required to represent manufacturing operations.

They allow us to describe:

• What work is being performed
• Which entities participate in that work
• What role each participant plays
• Which capabilities the work requires
• Which operational entities guide or record it
• Where the work occurs
• Which events occurred during execution
• Which entities were affected
• How operational states changed over time
• How processes and locations are decomposed

As with the core concepts, the objective is not to define every relationship that might exist in manufacturing. More specific relationships should be introduced through domain extensions where they are needed.

The core relationships provide the common semantic foundation from which those more specialized relationships can be defined without forcing every manufacturing domain into one oversized universal model.

We have now created a specification for our semantic layer. At this stage, we can describe it as a semantic model because it defines the concepts, relationships, and rules of our domain without prescribing a specific machine-readable representation, serialization format, or database technology.

In the next article, we will implement this specification as a formal ontology in a Neo4j graph database.