Building a Production Operations Domain Ontology in Manufacturing

In the previous article, we implemented a core manufacturing ontology in Neo4j. That core defined the fundamental concepts shared across manufacturing operations:

• Process
• PhysicalEntity
• OperationalEntity
• Agent
• Location
• Capability
• Role
• Event
• State

However, the core deliberately does not define production-specific concepts such as a filler, control recipe, raw material, batch-completion event, or production order.

Those concepts belong in a production-domain ontology.

The purpose of the production ontology is therefore to add the vocabulary needed to describe production operations while preserving a direct semantic connection to the shared core.

In this example, we model a ketchup production operation containing both:

• A batch-oriented make side, where ingredients are mixed, cooked, deaerated, homogenized, and buffered
• A discrete-flow pack side, where the bulk product is filled, capped, labelled, inspected, case-packed, and palletized

The same extension pattern could be used for pharmaceutical production, chemicals, automotive assembly, food and beverage, or other manufacturing domains.

Extending the Core Ontology

The production ontology introduces more concrete concepts by making them subclasses of the core concepts.

For example:

ProductionProcess SUBCLASS_OF Process

Filler SUBCLASS_OF Equipment

RawMaterial SUBCLASS_OF Material

Operator SUBCLASS_OF Agent

MasterRecipe SUBCLASS_OF OperationalEntity

ProductionEvent SUBCLASS_OF Event

This gives the production domain its own vocabulary without changing the meaning of the core.

The core still describes the universal structure of manufacturing operations. The production ontology describes what that structure looks like in the context of making and packaging a product.

The result is a two-level model:

Core ontology
    ↓
Production-domain ontology

For example:

PhysicalEntity
    └── Equipment          (core)
            ├── PreMixer   (production)
            ├── CookKettle
            ├── Homogenizer
            ├── Filler
            └── Palletizer

The production concepts become more precise, but they remain understandable through the shared core concept.

Attach to the core's tiers, not to invented ones

One rule shapes every section that follows: where the core already provides a classification tier, the domain attaches to it rather than inventing a parallel one.

The core supplies four such tiers:

It is tempting for a domain to declare its own grouping node — a ProductionEquipment above the units, a ProductionMaterial above the ingredients — so that everything the domain owns sits under one heading. Resist it. Such a node restates information the model already carries: every class in this file is labelled :Production and lives in the /production/ URI namespace, so "which equipment belongs to production?" is already answerable without it. Worse, a domain-owned parent competes with the core one — ProductionEquipment, UtilityEquipment and TestEquipment would end up as siblings, implying a subsumption between them that does not exist.

Attaching straight to Equipment and Material keeps one shared classification across every domain, so "every physical asset on the plant floor" stays a single traversal.

1. Extending the location tier with production structures

Production operations occur within identifiable operational areas and lines.

The core does not leave Location undivided: it already supplies the ISA-95 spatial levels — Enterprise, Site, Area and WorkCenter — as subclasses of Location. The production ontology extends the two levels that vary by domain, rather than attaching to Location itself:

ProductionArea SUBCLASS_OF Area
PackagingArea  SUBCLASS_OF Area

ProductionLine SUBCLASS_OF WorkCenter
PackagingLine  SUBCLASS_OF WorkCenter

The level says what kind of place it is; the production subclass says what happens there. A ProductionLine is a work centre, so anything written to query work centres finds it without knowing that production exists.

A ProductionArea represents the area in which raw materials are transformed into bulk product through batch processing.

A PackagingArea represents the area in which bulk product is converted into packaged finished goods.

The distinction reflects the two major parts of the operation:

ProductionArea
    └── ProductionLine

PackagingArea
    └── PackagingLine

The production line groups the make-side units that execute recipe phases. The packaging line groups the sequenced stations through which the product flows during filling and packing.

At the knowledge-graph level, this could later support statements such as:

KetchupLine1 INSTANCE_OF ProductionLine
PackagingLine2 INSTANCE_OF PackagingLine

CookKettle101 IS_LOCATED_AT KetchupLine1
Filler201 IS_LOCATED_AT PackagingLine2

The domain extension therefore gives the general core concept Location a production-specific interpretation.

2. Extending Equipment with production units and stations

The core divides PhysicalEntity on a single question: does the plant operate the thing, or does it flow through? Things the plant operates are Equipment; things that flow through are Material.

Production equipment is operated, so the units and stations attach directly to the core class:

Filler SUBCLASS_OF Equipment

There is no intermediate ProductionEquipment parent — see the rule above. The :Production label and the /production/ namespace already record which domain owns each asset.

On the make side:

PreMixer
CookKettle
Deaerator
Homogenizer
BufferTank

On the packaging side:

Filler
Capper
Labeler
DateCoder
XRayInspector
CoolingTunnel
CasePacker
Palletizer
Conveyor

This allows the ontology to describe what each physical unit is.

For example:

CookKettle SUBCLASS_OF Equipment
Equipment  SUBCLASS_OF PhysicalEntity

An actual asset can later be represented as:

CookKettle101 INSTANCE_OF CookKettle

The core classification tells us that CookKettle101 is a physical entity. The production ontology tells us that it is specifically a steam-jacketed vessel used for cooking product.

This is an important separation.

The ontology classifies the equipment according to what it is. Its role in a particular production execution is modeled separately.

For example:

CookKettle101 PARTICIPATES_IN CookingExecution4711
CookKettle101 PLAYS_ROLE Performer

3. Extending Material with production materials

Materials are also physical entities, but they sit on the other side of the operate-versus-flow-through split: they are consumed, transformed or dispatched rather than operated. So they attach to the core's other tier:

RawMaterial SUBCLASS_OF Material

Again there is no intermediate ProductionMaterial parent, for the same reason there is no ProductionEquipment.

The domain specializes Material according to the material's stage in the production flow:

RawMaterial
IntermediateProduct
FinishedProduct
PrimaryContainer
Closure
Label
ShippingCase

A raw material is consumed as an ingredient.

An intermediate product is a bulk product that has passed through one or more processing stages but has not yet become a packaged finished good.

A finished product is the packaged and released output ready for distribution.

The packaging materials are also represented as production materials because they participate in the creation of the final sellable product.

This supports a transformation path such as:

RawMaterial
    ↓
IntermediateProduct
    ↓
FinishedProduct

and a packaging flow such as:

IntermediateProduct
+ PrimaryContainer
+ Closure
+ Label
+ ShippingCase
    ↓
FinishedProduct

Note what is not on that list. A pallet of finished cases is a UnitLoad, and it belongs to the inventory domain rather than to production. The reason is the same distinction that keeps Equipment and Material apart: a shipping case is packaging that becomes part of what ships, while a unit load is a grouping of material handled as one — a way of moving stock, not a kind of stuff. UnitLoad therefore sits directly under PhysicalEntity, as a sibling of Material rather than a child of it.

The core ontology does not need to know the difference between tomato paste, cooked ketchup and a bottle. It only needs to establish that they are materials.

The production extension supplies the more precise production meaning.

4. Extending Process with make-side and pack-side work

The production ontology introduces:

ProductionProcess SUBCLASS_OF Process

ProductionProcess acts as the parent for the work that makes or packages the product.

The three procedural tiers of a batch

The make side is not one flat list of steps. Every batch-phase message published by the plant carries three nested identifiers — the batch record, an operation number and name, and a phase number and name — so the ontology models three levels:

Batch           SUBCLASS_OF ProductionProcess
BatchOperation  SUBCLASS_OF ProductionProcess
BatchPhase      SUBCLASS_OF ProductionProcess

They are siblings, not a subclass chain. A phase is not a kind of batch; it is a part of one. The nesting is therefore asserted between instances using the core HAS_SUBPROCESS relationship:

Batch B-20260603-001
    HAS_SUBPROCESS  Cook operation 0020
        HAS_SUBPROCESS  PasteurizationHold phase 0023

This is the distinction between classification and composition. SUBCLASS_OF says what something is; HAS_SUBPROCESS says what something is made of. Confusing the two produces a hierarchy where a phase inherits the properties of a whole batch.

The named make-side operations are the concrete BatchOperation types:

PreMixing
Cooking
Deaeration
Homogenization
Buffering

Phase names — DoseWater, HeatToTarget, PullVacuum and the rest — are deliberately not classes. They are recipe-specific and unbounded, so a new product would mean new classes. They stay as instance data on the phase.

The pack-side processes include:

Filling
Capping
Labeling
Coding
ForeignBodyInspection
Cooling
CasePacking
Palletizing

The ontology also includes:

CleaningInPlace

as a production process used to clean equipment internals between production runs.

This hierarchy allows us to describe a complete production flow:

PreMixing
    ↓
Cooking
    ↓
Deaeration
    ↓
Homogenization
    ↓
Buffering
    ↓
Filling
    ↓
Capping
    ↓
Labeling
    ↓
Coding
    ↓
ForeignBodyInspection
    ↓
Cooling
    ↓
CasePacking
    ↓
Palletizing

Each process inherits the meaning of the core Process concept: it is work that happens over time and affects something.

The production ontology then explains what kind of work it is.

For example:

Cooking SUBCLASS_OF BatchOperation
ProductionProcess SUBCLASS_OF Process

An actual execution can later be represented as:

CookingExecution4711 INSTANCE_OF Cooking

This distinction between a process class and an actual execution is important.

Cooking describes a type of work. CookingExecution4711 represents one occurrence of that work for a particular batch.

5. Extending OperationalEntity with production intent and evidence

Production systems need to represent both what should happen and what actually happened.

The production ontology extends OperationalEntity with concepts such as:

MasterRecipe
ControlRecipe
ProcessOrder
WorkOrder
PackagingOrder
ProductionSchedule
BatchRecord
ProductionResponse

These can be divided into two broad groups.

Production intent

These operational entities describe or authorize intended work:

MasterRecipe
ControlRecipe
ProcessOrder
WorkOrder
PackagingOrder
ProductionSchedule

A MasterRecipe defines how a product should generally be made.

A ControlRecipe is the batch-specific recipe used for one execution, including its procedure, parameters, and material bindings.

A ProcessOrder authorizes production of a quantity of material.

A WorkOrder releases that order as executable work to a production line.

A ProductionSchedule determines when and where orders should be executed.

Production evidence

These operational entities record the result of execution:

BatchRecord
ProductionResponse

A BatchRecord contains the as-executed procedure, parameters, materials, deviations, and results for a batch.

A ProductionResponse reports outcomes such as produced quantity, material consumption, and performance.

This gives the knowledge graph a clear distinction between:

What was intended

and:

What actually happened

That distinction is essential for traceability, deviation analysis, production reporting, and AI-agent reasoning.

6. Extending Agent with production participants

The production domain also introduces specialized agents:

Operator
ShiftSupervisor
LineController
BatchManagementSystem

These extend the core Agent concept because they are capable of participating in, controlling, coordinating, or making decisions about production processes.

An Operator runs and tends production equipment.

A ShiftSupervisor coordinates and authorizes production work across a shift.

A LineController controls the equipment of a line and reports its operational state.

A BatchManagementSystem sequences batch procedures and records their execution.

These agents may participate in the same process in different ways:

Operator17 PARTICIPATES_IN CookingExecution4711
Operator17 PLAYS_ROLE Performer

LineController4 PARTICIPATES_IN CookingExecution4711
LineController4 PLAYS_ROLE Controller

BatchManagementSystem1 PARTICIPATES_IN CookingExecution4711
BatchManagementSystem1 PLAYS_ROLE Controller

The production ontology defines what kinds of agents exist. The role model explains how each agent participates in a specific execution.

7. Extending Capability with production abilities

The production ontology defines capabilities such as:

MixingCapability
CookingCapability
DeaerationCapability
HomogenizationCapability
FillingCapability
CappingCapability
InspectionCapability
PalletizingCapability

These extend the core Capability concept.

The distinction between equipment and capability remains important:

CookKettle101 INSTANCE_OF CookKettle
CookKettle101 HAS_CAPABILITY CookingCapability

The kettle is a physical entity. Cooking is something it is able to do.

The corresponding process can then declare:

Cooking REQUIRES_CAPABILITY CookingCapability

This creates a reusable matching pattern:

Process
    REQUIRES_CAPABILITY
Capability
    possessed by
Equipment

An application or AI agent can use this pattern to identify suitable equipment for a production process.

For example:

Which available production equipment has the capability required to execute the cooking phase?

The query does not need to rely only on equipment names. It can reason through capability.

8. Extending Role with production participation

The production ontology defines common participation roles:

Input
Output
Performer
Consumer
Producer
Controller
Observer

These extend the core Role concept.

The roles describe how different entities participate in production processes.

For example:

TomatoPasteLot71 PLAYS_ROLE Input
CookKettle101 PLAYS_ROLE Performer
LineController4 PLAYS_ROLE Controller
CookedKetchupLot92 PLAYS_ROLE Output

However, roles only make sense within a particular context.

Tomato paste is not permanently an input. It is an input in a particular production process.

A more complete representation would therefore use qualified participation:

InputParticipation4711
    HAS_PARTICIPANT TomatoPasteLot71
    IN_PROCESS CookingExecution4711
    HAS_ROLE Input

This pattern can also carry context such as:

• Quantity consumed
• Participation start and end time
• Material lot
• Source system
• Equipment assignment
• Authorization

The production ontology defines the role vocabulary, while the knowledge graph applies those roles to actual process participation.

9. Extending Event with production occurrences

The production ontology defines:

ProductionEvent SUBCLASS_OF Event

It then introduces events such as:

BatchScheduled
BatchStarted
BatchCompleted
BatchReleased
PhaseStarted
PhaseCompleted
MaterialConsumed
MaterialProduced

These describe significant occurrences in the production lifecycle.

For example:

BatchStartedEvent4711 INSTANCE_OF BatchStarted
BatchStartedEvent4711 OCCURS_DURING BatchRun4711

Or:

MaterialConsumedEvent88 INSTANCE_OF MaterialConsumed
MaterialConsumedEvent88 OCCURS_DURING CookingExecution4711
MaterialConsumedEvent88 AFFECTS TomatoPasteLot71

The events provide time-based evidence of production.

They make it possible to reconstruct:

• When a batch was scheduled
• When execution began
• Which phases started and completed
• Which materials were consumed
• Which products were produced
• When the batch completed
• When the batch was released

This event history is essential for production genealogy and operational investigations.

10. Extending State with production conditions

State on its own is too coarse. A flat vocabulary of conditions lets a work order be Running and a filler be Completed, because nothing records whose lifecycle a state belongs to. The core therefore divides State into five scopes:

EquipmentState    the condition of a physical asset
ProcessState      the condition of a process execution
OrderState        an order, as planning sees it
WorkOrderState    a work order, as execution sees it
MaterialState     the disposition and availability of material

Every state class also ends in State — RunningState, HeldState, OrderClosedState. Classes share one namespace, and the natural name for a state is also the natural name for the event that causes it: BatchCompleted the event versus BatchCompleted the state. The suffix keeps the two apart.

Where the same word means different things in different scopes it is qualified as well. An order is released by planning — authorised to run — while material is released by the laboratory — approved for dispatch. OrderReleasedState and MaterialReleasedState are not the same condition, and collapsing them would let an ERP authorisation be mistaken for a quality decision.

The production ontology contributes states to four of the five scopes.

Equipment states

RunningState
IdleState
StarvedState
BlockedState
PlannedDowntimeState
UnplannedDowntimeState
ChangeoverState

These describe the operational condition of production equipment.

For example:

Filler201 HAS_STATE StarvedState

This means that the filler is unable to continue because it lacks upstream input.

Similarly:

Capper202 HAS_STATE BlockedState

indicates that the capper cannot pass its output to the downstream operation.

These states support production-performance analysis because they explain why equipment is not producing.

Process execution states

These describe a batch, an operation, a phase or a packaging run as it moves from scheduled through running to finished, including the operator interventions that hold or abandon it:

ScheduledState
StartedState
CompletedState
HeldState
ResumedState
StoppedState
AbortedState
CancelledState

Order states

The order lifecycle as the planning system sees it, mapping to the SAP status codes carried on the wire:

PlannedState          (CRTD)
OrderReleasedState    (REL)
OrderCompletedState   (TECO)
OrderClosedState      (CLSD)

Work order states

The same work seen by execution rather than planning — deliberately a separate scope, because the two systems track different milestones:

ReceivedState
DispatchedState
ActiveState
WorkOrderCompletedState
WorkOrderClosedState

These describe the lifecycle of production work.

For example:

BatchRun4711 HAS_STATE StartedState

Later:

BatchCompletedEvent4711 CHANGES_STATE BatchRun4711
BatchRun4711 HAS_STATE CompletedState

And after approval:

BatchReleasedEvent4711 CHANGES_STATE BatchRun4711
BatchRun4711 HAS_STATE MaterialReleasedState

The core gives us the general concept of state. The production ontology defines the states that matter in production operations.

11. Specializing the core relationships

The production ontology does more than add concepts. It also introduces more precise production relationships.

The core relationship:

Process AFFECTS Entity

is intentionally broad.

The production ontology specializes it with:

CONSUMES
YIELDS
TRANSFORMS

For example:

CookingExecution4711 CONSUMES TomatoPasteLot71
CookingExecution4711 TRANSFORMS PreBlendLot88
CookingExecution4711 YIELDS CookedKetchupLot92

All three relationships refine the general idea that a process affects a physical entity.

However, each has a more precise meaning:

• CONSUMES identifies a physical input used by a process
• TRANSFORMS identifies material whose form or properties are changed
• YIELDS identifies a physical output created by a process

The distinction between YIELDS and the core PRODUCES relationship is particularly important.

In this model:

Process YIELDS PhysicalEntity

while:

Process PRODUCES OperationalEntity

For example:

CookingExecution4711 YIELDS CookedKetchupLot92
CookingExecution4711 PRODUCES BatchRecord4711

One relationship represents the physical output. The other represents the informational evidence of the work.

Specializing how operational entities guide production

The core defines:

Process IS_GUIDED_BY OperationalEntity

The production ontology specializes this relationship with:

EXECUTES
FULFILLS

For example:

BatchRun4711 EXECUTES ControlRecipe4711
BatchRun4711 FULFILLS ProcessOrder882

EXECUTES means that the process carries out a recipe.

FULFILLS means that the process satisfies an authorized production order.

Both relationships preserve the shared meaning of IS_GUIDED_BY, but they make the production intent more explicit.

A complete production example

The resulting production ontology can support a graph such as:

BatchRun4711 INSTANCE_OF ProductionProcess

BatchRun4711 EXECUTES ControlRecipe4711
BatchRun4711 FULFILLS ProcessOrder882
BatchRun4711 OCCURS_AT KetchupLine1

TomatoPasteLot71 INSTANCE_OF RawMaterial
CookedKetchupLot92 INSTANCE_OF IntermediateProduct

TomatoPasteLot71 PARTICIPATES_IN BatchRun4711
TomatoPasteLot71 PLAYS_ROLE Input

CookKettle101 INSTANCE_OF CookKettle
CookKettle101 PARTICIPATES_IN BatchRun4711
CookKettle101 PLAYS_ROLE Performer
CookKettle101 HAS_CAPABILITY CookingCapability

BatchRun4711 REQUIRES_CAPABILITY CookingCapability

BatchRun4711 CONSUMES TomatoPasteLot71
BatchRun4711 TRANSFORMS PreBlendLot88
BatchRun4711 YIELDS CookedKetchupLot92

BatchRun4711 PRODUCES BatchRecord4711

BatchStartedEvent4711 OCCURS_DURING BatchRun4711
BatchCompletedEvent4711 OCCURS_DURING BatchRun4711

BatchRun4711 HAS_STATE CompletedState

The graph is production-specific, but every major concept remains grounded in the core ontology.

An application or AI agent can therefore move between two semantic levels:

CookKettle101
    INSTANCE_OF CookKettle
    SUBCLASS_OF Equipment
    SUBCLASS_OF PhysicalEntity

and:

BatchRun4711
    EXECUTES ControlRecipe4711
    where EXECUTES specializes IS_GUIDED_BY

This gives the detailed production model a shared semantic structure.

Conclusion

The production ontology adds the concepts required to describe:

• Production and packaging areas
• Make-side and pack-side equipment
• Raw, intermediate, and finished materials
• Batch and packaging processes
• Recipes, orders, schedules, and execution records
• Operators and automation systems
• Production capabilities
• Participation roles
• Production events
• Equipment and batch states

It also introduces production-specific relationships such as:

CONSUMES
TRANSFORMS
YIELDS
EXECUTES
FULFILLS

These relationships either specialize the more general relationships defined by the core or provide the additional precision required by the production domain.

The central principle is:

The core ontology defines the shared structure of manufacturing operations. The production ontology extends that structure with the concepts and relationships needed to describe how products are actually made and packaged.

This allows the production model to become more detailed without losing consistency with the rest of the manufacturing ontology.