Building a Quality Operations Domain Ontology in Manufacturing

In the previous articles, we defined a core manufacturing ontology and then extended it with the concepts required to describe production operations.

The same approach can be applied to quality.

The core ontology already provides the shared concepts needed to describe manufacturing operations: Process, PhysicalEntity, OperationalEntity, Agent, Location, Capability, Role, Event, and State.

What it deliberately does not define are quality-specific concepts such as laboratory testing, retained samples, specifications, non-conformance reviews, or material disposition. Those belong in a quality-domain ontology.

The purpose of the quality ontology is therefore to add the vocabulary required to describe how product quality is inspected, measured, judged, documented, and governed, while keeping those concepts connected to the shared manufacturing core.

In this example, the quality ontology covers three main areas:

• In-line inspection
• Laboratory sampling and testing
• Material disposition and non-conformance handling

The example is based on food production, but the same extension pattern can be applied to pharmaceutical, chemical, automotive, and other manufacturing environments.

Extending the Core Ontology

As with the production ontology, quality concepts are introduced by specializing concepts that already exist in the core.

For example:

QualityProcess SUBCLASS_OF Process
Sample SUBCLASS_OF Material
QualitySpecification SUBCLASS_OF OperationalEntity
QCTechnician SUBCLASS_OF Agent
TestingCapability SUBCLASS_OF Capability
QualityEvent SUBCLASS_OF Event
ApprovedState SUBCLASS_OF MaterialState

‍The core remains unchanged. It describes the general structure of manufacturing operations, while the quality ontology provides the more precise vocabulary required for quality management.

For example:

Process
   └── QualityProcess
         ├── Inspection
         ├── Sampling
         ├── Testing
         ├── Disposition
         └── NonConformanceReview


Every quality process therefore remains understandable as a type of manufacturing Process.

Quality Locations, Samples, and Test Equipment

Quality activities occur in identifiable locations. The core already defines WorkCenter, so the quality ontology can specialize it with:‍

InspectionStation SUBCLASS_OF WorkCenter


An InspectionStation represents a point on or beside the production line where product is checked against defined criteria.

Actual locations can then be represented in the Knowledge Graph:

FillInspectionStation3 INSTANCE_OF InspectionStation
BottleInspection88 OCCURS_AT FillInspectionStation3

‍The same extension pattern applies to physical entities:

Sample SUBCLASS_OF Material
RetainedSample SUBCLASS_OF Material
TestEquipment SUBCLASS_OF Equipment

‍
A Sample is a representative portion of material drawn for analysis. A RetainedSample is stored so that it remains available for later investigation or reference. TestEquipment represents instruments such as pH meters, refractometers, and viscometers.

For example:

BatchSample4711 INSTANCE_OF Sample
PHMeter12 INSTANCE_OF TestEquipment

BatchSample4711 PARTICIPATES_IN PHTestingExecution88
PHMeter12 PARTICIPATES_IN PHTestingExecution88

‍
The ontology tells us what the sample and instrument are. Their participation tells us how they are involved in a particular quality activity.

Defining Quality Processes

The quality ontology introduces:

QualityProcess SUBCLASS_OF Process


and specializes it into the main kinds of quality work including Inspection, Sampling, Testing, Disposition, and NonConformanceReview.


Together, these concepts describe a typical quality lifecycle:

Sampling → Testing or Inspection → NonConformanceReview (where required) → Disposition


Individual executions then become instances of those process types:

BatchSampling4711 INSTANCE_OF Sampling
PHTestingExecution88 INSTANCE_OF Testing
BatchDisposition4711 INSTANCE_OF Disposition

‍
Again, the ontology defines the stable types of quality work, while the Knowledge Graph records the individual activities that actually occurred.

Representing Quality Requirements and Evidence

Quality operations also require a distinction between what should happen and what actually happened. The quality ontology therefore extends OperationalEntity with concepts such as QualitySpecification, QualityPlan, TestMethod, InspectionResult, CertificateOfAnalysis, Deviation, and NonConformanceReport.


The first group describes quality intent and governance. A QualitySpecification defines the acceptance criteria that a product or material must satisfy, a QualityPlan defines which inspections and tests must be performed, when they occur, and at what frequency, and a TestMethod describes how a particular measurement must be performed.

The second group records quality evidence.

An InspectionResult captures the measured value and resulting judgement, a Deviation records a departure from an approved requirement, a NonConformanceReport documents a non-conforming material or result and the investigation that followed, and a CertificateOfAnalysis provides evidence that specified quality requirements have been met.

This lets us connect the work directly to both its instructions and its evidence:

‍

PHTestingExecution88
   IS_GUIDED_BY PHTestMethodV3

PHTestingExecution88
   CONFORMS_TO KetchupQualitySpecification

PHTestingExecution88
   PRODUCES InspectionResult88

‍
The TestMethod tells us how the measurement should be performed. The QualitySpecification tells us what limits must be satisfied. The InspectionResult tells us what was actually observed.

That distinction is particularly valuable for traceability, investigations, auditability, and AI-assisted quality analysis.

Agents, Capabilities, and Roles

Quality work involves people, equipment, and systems capable of performing particular activities. The quality ontology can specialize the core Agent concept with:

QCTechnician SUBCLASS_OF Agent
LabAnalyst SUBCLASS_OF Agent
QualityManager SUBCLASS_OF Agent

‍A QCTechnician may perform production-floor inspections and sampling, a LabAnalyst performs laboratory testing, and a QualityManager may participate in review and disposition decisions.

For example:

QCTechnician17 PARTICIPATES_IN BatchSampling4711
LabAnalyst8 PARTICIPATES_IN PHTestingExecution88
QualityManager3 PARTICIPATES_IN BatchDisposition4711

‍
Their classification remains separate from the role they play in a particular activity:

LabAnalyst8 PLAYS_ROLE Performer
QualityManager3 PLAYS_ROLE Approver


Capabilities provide another useful distinction: what an entity is is different from what it is able to do. The quality ontology can define SamplingCapability, TestingCapability, and DefectDetectionCapability.


These may be possessed by people, equipment, or automated systems:

QCTechnician17 HAS_CAPABILITY SamplingCapability
LabAnalyst8 HAS_CAPABILITY TestingCapability
XRayInspector201 HAS_CAPABILITY DefectDetectionCapability

Processes can then declare the capability they require:

Sampling REQUIRES_CAPABILITY SamplingCapability
Testing REQUIRES_CAPABILITY TestingCapability
Inspection REQUIRES_CAPABILITY DefectDetectionCapability

‍
This enables the graph to answer questions such as: Which qualified person or instrument can perform this required quality test?

The process does not have to be tied directly to a specific resource. It can instead be matched to resources through the capabilities they provide.

Defining Quality Events

The quality ontology also specializes the core Event concept:

QualityEvent SUBCLASS_OF Event


Typical quality events include SampleTaken, InspectionCompleted, DeviationRaised, NonConformanceRaised, and DispositionMade.


These represent significant occurrences rather than activities that unfold over time.

For example:

SampleTakenEvent4711 INSTANCE_OF SampleTaken
SampleTakenEvent4711 OCCURS_DURING BatchSampling4711

InspectionCompletedEvent88 INSTANCE_OF InspectionCompleted
InspectionCompletedEvent88 OCCURS_DURING PHTestingExecution88

‍If a result falls outside specification, a NonConformanceRaised event can record when that issue was identified. A later DispositionMade event records when the final quality decision was made.

Together, these events can reconstruct the chronology of a material's quality history:

SampleTaken → InspectionCompleted → NonConformanceRaised (where required) → DispositionMade


This chronological evidence is important for traceability, investigation, and auditability.

Defining Material Quality States

Events tell us what happened. States tell us what condition resulted.

Because quality decisions often determine whether material may be used, moved, or shipped, the quality ontology extends the core MaterialState scope with concepts such as AwaitingInspectionState, UnderReviewState, ApprovedState, RejectedState, and QuarantinedState.

‍
For example, newly produced material may initially be:‍

Batch4711 HAS_STATE AwaitingInspectionState


If a non-conformance is raised:

NonConformanceRaisedEvent88 CHANGES_STATE Batch4711
Batch4711 HAS_STATE UnderReviewState


The material may then be quarantined while the issue is investigated. Once disposition is complete:

DispositionMadeEvent88 CHANGES_STATE Batch4711
Batch4711 HAS_STATE ApprovedState


or:

Batch4711 HAS_STATE RejectedState


This illustrates why events and states should remain separate. DispositionMade records the decision occurring; ApprovedState or RejectedState represents the condition of the material after that decision. It also connects naturally to the production ontology.

Production may have completed successfully while the resulting material remains in AwaitingInspectionState or QuarantinedState. The graph can therefore represent both facts without assuming that production completion automatically means material release.

Specializing Core Relationships

The quality ontology can also make broad core relationships more precise.

The core relationship:

Process AFFECTS Entity


can be specialized with:

INSPECTS


For example:

BottleInspection88 INSPECTS BottleLot4711
PHTestingExecution88 INSPECTS BatchSample4711


Similarly, the core relationship:

Process IS_GUIDED_BY OperationalEntity


can be refined using:

CONFORMS_TO


For example:

PHTestingExecution88 CONFORMS_TO KetchupQualitySpecification
PHTestingExecution88 IS_GUIDED_BY PHTestMethodV3


These two relationships capture different meanings. IS_GUIDED_BY connects the test to the method that explains how to perform it. CONFORMS_TO connects the test to the specification that defines what requirements must be satisfied.

The domain ontology therefore becomes more precise without losing its connection to the relationships defined in the shared core.

Bringing the Quality Model Together

With these extensions in place, the graph can connect a material sample to the complete quality lifecycle. A sample is drawn from production and represented as a Sample, a QCTechnician performs the sampling using the required SamplingCapability, and a SampleTaken event records when that occurred.

The sample then participates in a Testing process carried out by a LabAnalyst and laboratory equipment. The test is guided by a TestMethod, evaluated against a QualitySpecification, and produces an InspectionResult.

If the result is outside specification, a NonConformanceRaised event can move the affected material into UnderReviewState. A NonConformanceReview investigates the problem, after which a Disposition process determines whether the material should be approved, reworked, quarantined, or rejected.

The important point is that none of these quality concepts exist in isolation.

The sample remains a type of Material. The laboratory instrument remains Equipment. Testing remains a Process. The analyst remains an Agent. The specification remains an OperationalEntity. Quality events remain Events, and quality conditions remain States.

An application or AI agent can therefore move from detailed quality facts to the shared semantic structure of the wider manufacturing model.

Conclusion

The quality ontology extends the core manufacturing ontology with the vocabulary required to describe how product quality is inspected, measured, documented, and decided.

It introduces quality-specific locations, samples, test equipment, processes, specifications, records, participants, capabilities, events, and material states. It also specializes broad core relationships with concepts such as INSPECTS and CONFORMS_TO.

The important principle, however, is not the individual classes.

It is the extension pattern.

The core ontology defines the shared structure of manufacturing operations. The quality ontology adds the concepts required to determine whether products and materials meet their defined requirements.

Because those concepts remain grounded in the same core, quality does not become a separate semantic island. It can connect directly to production processes, materials, equipment, orders, events, and execution history within the same manufacturing Knowledge Graph.

‍