Articles
9 minutes
Copy Link
When Does a Manufacturer Need an Industrial Ontology Before Adding AI to Factory Operations?
TL;DR
One plant, one bounded decision: verify the equipment, lot, and order mapping before recommending a schedule change. A plantwide ontology is not a prerequisite.
Several decisions at one plant: use an ISA-95-aligned information model when scheduling and investigations need the same equipment and material definitions.
Shared decisions across plants: govern an ontology when site-specific IDs or status definitions would change the outcome of the same decision.
Expansion trigger: repeated remapping or a cross-site rule that treats different lot statuses as equivalent warrants a named semantic owner and validation across affected decisions.
Humble's role: use contextualized data to show the evidence, constraints, and approval rights behind a proposed action. Humble does not build the mapping or ontology.
Does this AI use case actually need an industrial ontology?
An industrial ontology is not required when one plant can verify the relationships needed for a specific AI decision. For a scheduling exception, you may only need to confirm that an MES lot, an ERP order, and an equipment record refer to the same work at the relevant time. A plant owner can maintain that bounded mapping and check it whenever a source identifier or operating rule changes.
An ISA 95 information model becomes useful when several decisions or applications need consistent definitions of materials and equipment. ISA 95 covers materials, equipment, physical assets, personnel, and their relationships. It is more than a plant hierarchy. Distinguishing an equipment role from the physical asset assigned to it lets you retain the role when an installed device changes.
Do not buy cross-plant ontology tooling to fix one plant's scheduling exception. Invest in shared semantics when two sites must agree on what an equipment class, lot status, or order milestone means before they can make the same decision. Name an owner who approves changes and checks their effect at both sites. For a local decision, keep the verified mapping or ISA-95-aligned model. The ISA-95 versus ontology guidance covers their definitions.
Industrial ontology vs. ISA-95 vs. plant mapping: which does factory AI need?
Option | Best fit | Shared meaning | Change owner | Validation | Expand when |
|---|---|---|---|---|---|
Bounded plant mapping | One scheduling decision at one plant | Verified equipment, lot, and order links | Plant process owner | Check IDs, timestamps, and joins after source changes | Another decision needs definitions that must stay consistent |
ISA 95 information model | Scheduling and investigations reuse local definitions | Shared classes, instances, properties, and relationships | Plant data owner with operations | Test definitions and links across local uses | Decisions across plants need consistent meanings |
Governed ontology across plants | Recurring decisions compare sites with different conventions | Shared definitions and relationship rules | Central data owner with site owners | Test site mappings and affected decisions after changes | More sites or decisions must reuse those definitions |
Each move up the matrix increases the cost of changing a definition. A transmitter replacement may change the physical asset ID without changing the equipment role it fills. A plant mapping needs one check after the swap. A cross-plant rule needs an owner to confirm how every affected site records the change before dependent decisions use it.
A scheduling exception traced through a bounded mapping
A single plant can evaluate a scheduling exception with a verified mapping when the decision depends on a small, stable set of relationships. Consider an illustrative case in which SCADA reports equipment tag EQ07 stopped at 09:14, while MES records lot L204 against work center WC07 at 09:15. The plant’s approved mapping links EQ07 to WC07 for that time period, and MES links L204 to ERP order O918. Those checks establish which order the stoppage affects without requiring a cross-plant ontology.
The proposed decision is to move order O918 to work center WC09 at 10:00. Before presenting the recommendation, the decision layer checks WC09’s MES status, approved equipment eligibility, lot availability, and any scheduling constraints the plant has specified. In this example, the planner must approve the move before it is released. ERP and MES remain the systems of record for the order and production activity.
The plant could set a five minute freshness limit for equipment status in this example. The decision layer withholds its recommendation for planner review if WC09’s status is older than that limit, the lot and order cannot be linked, or equipment eligibility is unconfirmed. If WC09 becomes unavailable after approval but before release, the planner cancels the proposed move and reassesses the order. The separate walkthrough of decisions across factory systems covers the broader flow.
When is a plant mapping no longer enough for factory AI?
The second local use case is the first expansion test. If a scheduling rule and a root-cause investigation each maintain their own link between work center WC07 and equipment tag EQ07, a tag change forces two updates and two checks. A plant-owned ISA-95-aligned model gives both uses the same equipment definition, while the plant remains responsible for verifying each source link.
A cross-plant decision needs more than matching column names. One site may mark a lot available when production ends, while another waits for a quality release. A shared recommendation based on those statuses would treat different conditions as equivalent. If the decision must work across both sites, a central owner should govern the meaning of available, record each site's exception, and test the decision whenever that rule changes.
Do not promote a mapping solely because another plant has started an AI project. Keep the smaller scope if each decision stays local and you can verify its source relationships. Move up when reuse or cross-site decisions make separate definitions difficult to validate consistently.
Where Humble fits once the semantic scope is set
Humble is a downstream decision layer that uses contextualized data for a defined operational choice. A verified mapping may supply enough context for a bounded scheduling recommendation. Decisions that rely on shared equipment, lot, and order meanings across plants need those meanings governed before the decision layer uses them. Humble does not create the mapping, ISA 95 model, or ontology, and it does not replace industrial edge, integration, MES, ERP, or SCADA infrastructure.
Humble applies decision intelligence after the plant has established enough context to act. In the scheduling example, the recommendation can show the source records, the constraints checked, and the planner who must approve a move. Plant leadership may later permit specific routine moves within its own limits and withdraw that permission when needed. A missing lot-to-order link should hold the recommendation for review. Building an ontology cannot repair an unverified link on its own.
Book a Call with Humble
If you have scoped the mapping or model for a specific decision, book a call with Humble to discuss the evidence, approval rights, and stop conditions that decision would require.
See If Humble Fits Your Floor
Use the Humble fit test to describe the decision you want to support and the data context you already trust. Start with that decision before committing to a larger semantic model.
FAQ
Is ISA-95 itself an industrial ontology? No. ISA 95 provides information models for manufacturing operations, but it does not define every meaning a manufacturer needs to share across plants. Manufacturers must define and govern those site-specific meanings. The ISA 95 versus ontology guide explains the distinction.
Can a bounded mapping be good enough permanently? Yes, if one plant uses it for a stable decision, source relationships remain verified, and a named owner checks changes. A second use case or repeated remapping may justify a shared model, but neither automatically calls for a cross-plant ontology.
Who should own cross-plant ontology governance? Give a central manufacturing data owner authority over shared definitions, with plant operations owners responsible for confirming local meanings and approving changes that affect decisions. The owner should record who approved each definition and when it changed.
Does Humble require an ontology? Not necessarily. Humble sits downstream of contextualized data as a governed decision layer. A verified mapping may be enough for a bounded use case, while a cross-plant decision may need governed shared semantics first.
What should an uncertain buyer do first? Pick one operational decision and trace its source IDs, timestamps, and equipment, lot, and order relationships. Name who can approve the action and which missing or stale evidence must stop it. That test reveals which meanings need to be shared.
Stay Current on Manufacturing Decision Intelligence
For more on manufacturing decision intelligence, subscribe to Humble's newsletter.