Building a Quality Operations Domain Ontology in Manufacturing

In the previous articles, we defined a small 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 gives us the shared concepts needed to describe manufacturing operations:

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

However, it deliberately does not define concepts such as laboratory testing, quality specifications, retained samples, non-conformance reviews, or material disposition.

Those concepts belong in a quality-domain ontology.

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

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

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

The model is based on a food-production operation, but the same extension approach can be applied to pharmaceutical, chemical, automotive, and other manufacturing environments.

Extending the Core Ontolgy

The quality ontology introduces more specific concepts by making them subclasses of the existing core concepts.

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 still defines the general semantic structure of manufacturing operations. The quality ontology adds the concepts required to describe how quality is assessed and how quality decisions affect materials and production.

The resulting structure is:

Core ontology
    ↓
Quality-domain ontology

For example:

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

Every quality-specific process retains the shared meaning of the core Process concept: it is work that happens over time and affects or produces something.

1. Extending Location with quality areas

Quality activities occur in particular parts of the manufacturing environment.

The quality ontology introduces:

QualityLaboratory SUBCLASS_OF WorkCenter

InspectionStation SUBCLASS_OF WorkCenter

A QualityLaboratory is the controlled area where samples are analysed for attributes such as:

• pH
• Brix
• Viscosity
• Colour
• Microbiology

An InspectionStation is a point on or beside the production line where product is checked against defined quality criteria before it is allowed to proceed.

At the knowledge-graph level, actual locations could later be represented as:

MainQualityLab INSTANCE_OF QualityLaboratory

FillInspectionStation3 INSTANCE_OF InspectionStation

Quality processes can then be connected to those locations through the core relationship:

TestingExecution4711 OCCURS_AT MainQualityLab

BottleInspection88 OCCURS_AT FillInspectionStation3

The quality ontology therefore gives the general core concept Location a more precise quality-control meaning.

2. Extending PhysicalEntity with samples and test equipment

The quality ontology introduces three physical concepts:

Sample SUBCLASS_OF Material

RetainedSample SUBCLASS_OF Material

TestEquipment SUBCLASS_OF Equipment

A Sample is a representative portion of material drawn from a batch or container for quality analysis.

For example:

BatchSample4711 INSTANCE_OF Sample

A RetainedSample is a sample that is stored through the product shelf life so that it remains available for later reference or investigation.

For example:

RetainedSample4711 INSTANCE_OF RetainedSample

TestEquipment represents the laboratory instruments used to measure quality attributes.

Examples include:

pH meter
Refractometer
Viscometer

An actual instrument could be represented as:

PHMeter12 INSTANCE_OF TestEquipment

The core classification tells us that these are physical entities. The quality ontology tells us the particular function they have within the quality domain.

Their participation in a specific quality process can then be described separately:

BatchSample4711 PARTICIPATES_IN PHTestingExecution88

PHMeter12 PARTICIPATES_IN PHTestingExecution88

The sample and instrument are physical things. Their involvement in a particular test is contextual.

3. Extending Process with quality work

The quality ontology introduces an abstract parent concept:

QualityProcess SUBCLASS_OF Process

It then defines five major types of quality work:

Inspection
Sampling
Testing
Disposition
NonConformanceReview

Inspection

Inspection represents examining a product against defined criteria to judge whether it conforms.

For example:

BottleInspection88 INSTANCE_OF Inspection

This could represent checking bottles for:

• Correct fill level
• Cap placement
• Label position
• Foreign bodies
• Packaging damage

Sampling

Sampling represents drawing a representative portion of material from a batch or container for analysis.

For example:

BatchSampling4711 INSTANCE_OF Sampling

The process creates the connection between the source material and the physical sample that will later be tested.

Testing

Testing represents measuring product attributes in the laboratory using a defined test method.

For example:

PHTestingExecution88 INSTANCE_OF Testing

Testing may measure attributes such as:

• pH
• Brix
• Viscosity
• Colour
• Microbiological count

Disposition

Disposition represents deciding the fate of a batch or material lot.

Possible decisions include:

Approve
Release
Rework
Reject
Quarantine

For example:

BatchDisposition4711 INSTANCE_OF Disposition

NonConformanceReview

NonConformanceReview represents the investigation of a result or material that does not meet its required criteria.

The review determines:

• What went wrong
• Which material or process was affected
• Whether the result is valid
• Whether corrective action is required
• Whether the material should be released, reworked, or rejected

These processes give the quality ontology a lifecycle that moves from observation to judgement:

Sampling
    ↓
Testing or Inspection
    ↓
NonConformanceReview, where required
    ↓
Disposition

4. Extending OperationalEntity with quality intent and evidence

The quality ontology introduces operational entities that either define what quality work should be performed or record the evidence produced by that work.

The main concepts are:

QualitySpecification
InspectionResult
CertificateOfAnalysis
Deviation
NonConformanceReport
QualityPlan
TestMethod

These can be divided into two broad groups.

Quality intent and governance

The following operational entities define or govern quality work:

QualitySpecification
QualityPlan
TestMethod

A QualitySpecification defines the attributes and acceptance limits a product must meet.

For example:

KetchupQualitySpecification
    target pH range
    target Brix range
    target viscosity range

A QualityPlan defines which inspections and tests apply to a product, when they must be performed, and at what frequency.

A TestMethod describes how a specific product attribute must be measured.

For example:

PHTestMethodV3
BrixTestMethodV2
ViscosityTestMethodV1

These concepts represent what should happen and the conditions against which quality must be judged.

Quality evidence

The following operational entities record what actually happened:

InspectionResult
CertificateOfAnalysis
Deviation
NonConformanceReport

An InspectionResult captures measured values and the resulting pass-or-fail verdict.

A CertificateOfAnalysis certifies that a batch meets its quality specification and can accompany released product.

A Deviation records a departure from an approved procedure, process parameter, or specification.

A NonConformanceReport documents material or a result that did not conform and records the review that followed.

This creates the important distinction between:

The quality requirement

and:

The evidence of whether the requirement was met

For example:

PHTestingExecution88 CONFORMS_TO KetchupQualitySpecification

PHTestingExecution88 IS_GUIDED_BY PHTestMethodV3

PHTestingExecution88 PRODUCES InspectionResult88

The specification and test method guide the work. The inspection result records the outcome.

5. Extending Agent with quality participants

The quality ontology introduces three specialized agents:

QCTechnician
QualityManager
LabAnalyst

These extend the core Agent concept.

A QCTechnician performs in-line inspections and draws samples on the production floor.

A LabAnalyst performs laboratory tests and records the results.

A QualityManager owns the final quality decision and authorizes whether material is approved, held, or rejected.

For example:

QCTechnician17 PARTICIPATES_IN BatchSampling4711

LabAnalyst8 PARTICIPATES_IN PHTestingExecution88

QualityManager3 PARTICIPATES_IN BatchDisposition4711

The quality ontology defines the types of agents involved.

The core Role concept can then describe how they participate in a particular process:

QCTechnician17 PLAYS_ROLE Performer

LabAnalyst8 PLAYS_ROLE Performer

QualityManager3 PLAYS_ROLE Approver

The current quality extension does not define new quality-specific role classes. It relies on the core role model or on a later governance extension to introduce concepts such as Approver, Reviewer, or Authorizer.

6. Extending Capability with quality abilities

The quality ontology introduces three capabilities:

DefectDetectionCapability
TestingCapability
SamplingCapability

These extend the core Capability concept.

DefectDetectionCapability is the ability to identify quality defects such as:

• Underfill
• Misapplied caps
• Label faults
• Visible packaging damage

TestingCapability is the ability to measure product attributes according to a defined test method.

SamplingCapability is the ability to draw a representative sample without compromising the sample or source material.

These capabilities can be associated with people, equipment, or systems:

QCTechnician17 HAS_CAPABILITY SamplingCapability

LabAnalyst8 HAS_CAPABILITY TestingCapability

XRayInspector201 HAS_CAPABILITY DefectDetectionCapability

The corresponding quality processes can state what they require:

Sampling REQUIRES_CAPABILITY SamplingCapability

Testing REQUIRES_CAPABILITY TestingCapability

Inspection REQUIRES_CAPABILITY DefectDetectionCapability

This creates the same reusable matching pattern used in the production domain:

QualityProcess
    REQUIRES_CAPABILITY
Capability
    possessed by
Agent or PhysicalEntity

An application or AI agent can use this model to identify which people, instruments, or inspection systems are qualified to perform a particular quality activity.

7. Extending Event with quality-significant occurrences

The quality ontology introduces:

QualityEvent SUBCLASS_OF Event

It then defines five quality events:

InspectionCompleted
DeviationRaised
NonConformanceRaised
SampleTaken
DispositionMade

These events record significant points in the quality lifecycle.

SampleTaken

SampleTaken records that a sample was drawn from a batch or container.

For example:

SampleTakenEvent4711 INSTANCE_OF SampleTaken

SampleTakenEvent4711 OCCURS_DURING BatchSampling4711

InspectionCompleted

InspectionCompleted records that an inspection or test finished and produced a verdict.

For example:

InspectionCompletedEvent88 INSTANCE_OF InspectionCompleted

InspectionCompletedEvent88 OCCURS_DURING PHTestingExecution88

DeviationRaised

DeviationRaised records that a departure from an approved procedure, process parameter, or specification was identified.

NonConformanceRaised

NonConformanceRaised records that a non-conforming material or test result was flagged for review.

DispositionMade

DispositionMade records that a release, rework, or rejection decision was made for a batch or lot.

These events allow the knowledge graph to reconstruct the quality history of a material:

SampleTaken
    ↓
InspectionCompleted
    ↓
NonConformanceRaised, where required
    ↓
DispositionMade

They provide the temporal evidence required for traceability, investigation, and auditability.

8. Extending State with quality lifecycle conditions

The quality ontology introduces five material-quality states:

AwaitingInspectionState
UnderReviewState
ApprovedState
RejectedState
QuarantinedState

These extend the core State concept.

AwaitingInspectionState means that material is being held until the required quality check is completed.

UnderReviewState means that the material is being assessed following a non-conforming result.

ApprovedState means that the material has passed quality judgement and is cleared for use or dispatch.

RejectedState means that the material has failed quality judgement and may not be used.

QuarantinedState means that the material is isolated and blocked from movement while a disposition decision is pending.

These states describe the lifecycle of material under quality control:

AwaitingInspectionState
    ↓
ApprovedState

or:

AwaitingInspectionState
    ↓
UnderReviewState
    ↓
QuarantinedState
    ↓
ApprovedState or RejectedState

Events can be used to explain why the state changed:

NonConformanceRaisedEvent88 CHANGES_STATE Batch4711

Batch4711 HAS_STATE UnderReviewState

Later:

DispositionMadeEvent88 CHANGES_STATE Batch4711

Batch4711 HAS_STATE RejectedState

For stronger traceability, these direct state relationships could later be represented through time-qualified state assertions.

9. Specializing the core relationships

The quality ontology introduces two more precise relationships:

INSPECTS
CONFORMS_TO

Both refine relationships already defined in the core.

INSPECTS

The core defines:

Process AFFECTS Entity

The quality ontology specializes this with:

Process INSPECTS PhysicalEntity

For example:

BottleInspection88 INSPECTS BottleLot4711

PHTestingExecution88 INSPECTS BatchSample4711

INSPECTS provides more precise meaning than the general AFFECTS relationship.

It tells us that the process examines the physical entity to judge whether it meets defined quality criteria.

CONFORMS_TO

The core defines:

Process IS_GUIDED_BY OperationalEntity

The quality ontology specializes this with:

Process CONFORMS_TO OperationalEntity

For example:

BottleInspection88 CONFORMS_TO PackagingQualitySpecification

PHTestingExecution88 CONFORMS_TO KetchupQualitySpecification

CONFORMS_TO means that the process is governed by a specification whose requirements must be satisfied.

This is more precise than saying only that the process is guided by an operational entity.

The same process may also use the broader core relationship for another quality artifact:

PHTestingExecution88 IS_GUIDED_BY PHTestMethodV3

PHTestingExecution88 CONFORMS_TO KetchupQualitySpecification

The test method explains how the measurement is performed. The specification defines the limits against which the result is judged.

A complete quality example

The resulting quality ontology can support a graph such as:

BatchSampling4711 INSTANCE_OF Sampling

BatchSample4711 INSTANCE_OF Sample

BatchSample4711 PARTICIPATES_IN BatchSampling4711

QCTechnician17 INSTANCE_OF QCTechnician
QCTechnician17 PARTICIPATES_IN BatchSampling4711
QCTechnician17 HAS_CAPABILITY SamplingCapability

SampleTakenEvent4711 INSTANCE_OF SampleTaken
SampleTakenEvent4711 OCCURS_DURING BatchSampling4711

PHTestingExecution88 INSTANCE_OF Testing

BatchSample4711 PARTICIPATES_IN PHTestingExecution88

PHMeter12 INSTANCE_OF TestEquipment
PHMeter12 PARTICIPATES_IN PHTestingExecution88

LabAnalyst8 INSTANCE_OF LabAnalyst
LabAnalyst8 PARTICIPATES_IN PHTestingExecution88
LabAnalyst8 HAS_CAPABILITY TestingCapability

PHTestingExecution88 REQUIRES_CAPABILITY TestingCapability
PHTestingExecution88 IS_GUIDED_BY PHTestMethodV3
PHTestingExecution88 CONFORMS_TO KetchupQualitySpecification
PHTestingExecution88 INSPECTS BatchSample4711
PHTestingExecution88 PRODUCES InspectionResult88

InspectionCompletedEvent88 INSTANCE_OF InspectionCompleted
InspectionCompletedEvent88 OCCURS_DURING PHTestingExecution88

If the result is outside specification, the graph may continue:

NonConformanceRaisedEvent88 INSTANCE_OF NonConformanceRaised

NonConformanceRaisedEvent88 AFFECTS Batch4711
NonConformanceRaisedEvent88 CHANGES_STATE Batch4711

Batch4711 HAS_STATE UnderReviewState

NonConformanceReview88 INSTANCE_OF NonConformanceReview

NonConformanceReview88 PRODUCES NonConformanceReport88

BatchDisposition88 INSTANCE_OF Disposition

QualityManager3 PARTICIPATES_IN BatchDisposition88

DispositionMadeEvent88 INSTANCE_OF DispositionMade
DispositionMadeEvent88 OCCURS_DURING BatchDisposition88
DispositionMadeEvent88 CHANGES_STATE Batch4711

Batch4711 HAS_STATE ApprovedState

The graph is specific to the quality domain, but every major concept remains grounded in the core ontology.

For example:

PHTestingExecution88
    INSTANCE_OF Testing
    SUBCLASS_OF QualityProcess
    SUBCLASS_OF Process

and:

BatchSample4711
    INSTANCE_OF Sample
    SUBCLASS_OF Material
    SUBCLASS_OF PhysicalEntity

An application or AI agent can therefore move from detailed quality facts to the general semantic structure shared across manufacturing operations.

Conclusion

The quality ontology extends the core manufacturing ontology with the concepts required to describe how product quality is assessed, documented, and decided.

It introduces vocabulary for:

• Quality laboratories and inspection stations
• Samples, retained samples, and test equipment
• Inspection, sampling, testing, disposition, and non-conformance review
• Specifications, quality plans, test methods, and quality records
• Quality technicians, analysts, and managers
• Sampling, testing, and defect-detection capabilities
• Quality-significant events
• Material quality states

It also introduces the specialized relationships:

INSPECTS
CONFORMS_TO

These refine the more general core relationships AFFECTS and IS_GUIDED_BY.

The central principle remains the same:

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

This allows quality models to become more detailed without separating them from production, maintenance, inventory, and the rest of the manufacturing knowledge graph.