How ISA-95 and Industrial Ontologies Support Shop-Floor Decisions.

TL;DR

• The packaging line example is illustrative. An ERP order is due today, but SCADA reports that its assigned line is unavailable.

• ERP supplies order constraints, MES supplies operation and lot status, and SCADA supplies equipment state. ISA-95 concepts and an ontology join those records and establish whether the event can support a decision.

• Humble consumes that context to prepare a resequencing recommendation with evidence and constraints. Humble does not produce the ontology or replace ERP, MES, or SCADA.

• An authorized person approves the action unless plant leadership has permitted bounded autonomy. The plant routes the task and uses a permitted integration to record approved changes in the authoritative system. An owner checks the outcome before accepting any change to procedural knowledge.

The gap between contextualized data and a shop-floor decision

A validated data join can show that packaging line A became unavailable while an assigned order remains due today. The join cannot establish whether another line can take the order, whether its material lot is released, or who may approve a dispatch change. A recommendation needs current source records, checked constraints, supporting evidence, and a decision owner.

ISA-95 models more than equipment hierarchy. The OPC Foundation’s ISA-95 Common Object Model provides equipment, material, and personnel models that a plant can use to describe the records involved. A plant must still verify that a line state event matches the right MES operation and lot at the relevant time. Even a valid match leaves the scheduling choice unresolved.

The ontology platform comparison covers platform selection. The ISA-95 integration architecture guide covers system boundaries, while the ISA-95 and industrial ontologies explainer covers how the data gains shared meaning. This article picks up after that work. Humble consumes the resulting context to support a daily decision rather than replacing the ontology infrastructure, ERP, MES, or SCADA.

Input-to-action flow at a glance

This illustrative flow follows a packaging order due today after line A becomes unavailable. The walkthrough below examines each handoff.

1. ERP provides the order, due date, priority, and commercial constraints.

2. MES provides the current operation, material lot, and quality disposition.

3. SCADA reports line A’s state, event time, and signal quality.

4. Plant-defined ownership rules identify the authoritative records. ISA-95 concepts and ontology mappings connect the order, operation, lot, and equipment event across time. The plant checks freshness, mappings, and lot status.

5. Humble consumes that context and prepares a recommendation with source evidence, constraints, and reasoning.

6. An authorized person approves the action unless plant policy explicitly permits bounded autonomy.

7. The approved task goes to the responsible operator or agent.

8. A permitted integration records any approved change in the authoritative system.

9. The decision owner compares the outcome with the expected result and approves any adjustment to procedural knowledge.

ERP: order priority, due date, and commercial constraints

In this illustrative scenario, ERP establishes why a production order due today needs attention when packaging line A becomes unavailable. In this example, plant policy makes ERP authoritative for the order’s priority, due date, and commercial commitments. Those records give a downstream decision layer the order ID and constraints it must respect when considering a different production sequence.

ERP cannot establish whether line A is currently available or whether another line can run the order. Its inventory commitment also does not establish that the required material lot has cleared a quality hold. MES and SCADA must supply that execution and equipment context before anyone can assess an alternative.

MES: operation state, lot genealogy, and quality disposition

MES supplies the execution context that the ERP order cannot provide. In the illustrative packaging scenario, MES identifies the order’s current operation, the material lot assigned to it, and any active quality hold. Its genealogy records which lots entered earlier operations. If the assigned lot is on hold, moving the order to another line would not make it ready to run.

MES also shows whether a proposed change fits the operation’s dispatch rules, where those rules are configured. The operation’s resource requirements help the plant check whether a replacement line can run the assigned material lot. MES can pass the operation ID, lot status, and applicable restrictions downstream, but those records alone cannot establish whether another line is available.

SCADA: equipment state and the moment of signal

In this illustrative packaging scenario, SCADA reports that line A has become unavailable and passes on the event timestamp and signal quality flag. The timestamp lets the plant compare the event with the MES operation in progress. The quality flag lets the plant check whether the signal meets its rules for use in a decision.

The signal alone cannot establish which order was affected, whether its lot remains approved, or whether another line can take the work. Local automation and safety logic stay with the plant’s controls. Before anyone recommends resequencing, the contextualization layer must match the event to line A and the relevant MES operation at that time.

The ISA-95/ontology join: making the event admissible

In the illustrative packaging example, the line A event becomes usable only after a governed join connects it to the order at risk. The semantic layer maps the ERP order ID to its MES operation and lot, then matches that operation to the SCADA event using equipment identity and the time the line became unavailable. An event for a different line, or one recorded after the operation ended, cannot support the same decision.

Before Humble receives the joined event, the plant should check that each source is fresh enough for the decision, the order maps to the active operation, and the lot has an approved disposition. The checks should also confirm compatible units, a valid equipment mapping, and no unresolved conflict between systems. For example, if MES reports that the operation has finished while SCADA reports line A as unavailable, the decision layer needs a resolved timeline rather than an assumed cause.

ISA-95 provides material and equipment concepts. The plant defines its site-specific relationships and validity rules in its ontology and governance process. An unresolved check should hold the recommendation for an authorized owner to investigate.

Humble's decision layer: from contextualized event to recommendation

In the illustrative packaging scenario, Humble consumes a validated event that connects an ERP order due today, its MES operation and approved lot, and SCADA’s report that packaging line A is unavailable. Its decision intelligence role is to assess whether line B can take the order. A proposed resequencing plan must account for line B’s capability, lot disposition, changeover time within the shift, and downstream commitments. If the lot is on hold or line B cannot run it, the proposal should rule out that option.

The recommendation should give the scheduler or authorized supervisor enough evidence to judge the proposed change. In this reference design, an evidence bundle records source IDs, event timestamps, constraint versions, the expected tradeoff between changeover time and schedule adherence, and the named decision owner. The proposed reasoning record would tie the plan to those inputs and explain why an alternative was rejected. The recommendation remains a proposal, not an approved dispatch change.

ISA-95 and ontology infrastructure supply context for the proposal, while Humble supports the downstream decision. Humble does not replace an ontology platform, integration layer, MES, SCADA, or ERP.

Decision rights, approval, and bounded autonomy

In the illustrative packaging scenario, the authorized scheduler or supervisor signs off before anyone moves the due order from line A to line B. The recommendation should identify the decision owner and show the evidence behind the proposed move, including line B’s capability, lot disposition, and expected effect on the shift schedule. A line becoming unavailable does not, by itself, grant software permission to change the plan.

Plant leadership can grant autonomy separately for each decision loop. In shadow mode, Humble prepares a recommendation without acting. In assisted mode, it routes the recommendation for human approval. In an illustrative autonomous mode, a plant-approved workflow could act only within configured limits, such as approved equipment, eligible lots, and a maximum schedule change. Leadership can withdraw that permission. The loop should record what it checked and what it did, and send exceptions or failed checks to a person. Quality holds, safety decisions, and commercial commitments should remain with their designated human owners unless plant policy explicitly assigns narrower authority.

Approval to make a decision does not establish permission to update ERP or MES records. The ISA-95 integration architecture guide covers that separate system boundary.

Task routing, write-back, and outcome feedback

In the illustrative packaging example, the approved resequencing plan becomes a task for the scheduler and the operator responsible for the alternate line. In this reference design, the plant routes the task through its chosen workflow with the approved lot, changeover window, and decision owner attached. An agent may handle a routine step only within limits plant leadership has authorized.

The plant records any dispatch change in MES and any revised commercial commitment in ERP, according to its ownership policy. Write-back requires an available, permitted integration and the appropriate approval. The example does not assume a native Humble connector or automatic updates to either system.

After the change, the decision owner checks actual line availability, lot status, schedule adherence, and decision latency against the recommendation’s expected tradeoff. If the alternate line stayed unavailable or the lot entered a hold, the owner can revise the handling rule rather than treating the approval as proof of success. After reviewing the result, the owner can record an accepted adjustment, its evidence, and the operator’s explanation in the plant’s procedural knowledge workflow.

System and decision-rights table

In this illustrative packaging-line example, each layer contributes to a proposed resequencing, but the plant assigns authority for the production change.

Any approved change reaches ERP or MES only through an available, permitted integration. Neither contextualization nor a recommendation changes the authoritative record on its own.

How Humble's decision role differs from ontology platform capabilities

Ontology and data platforms can participate in operational decisions. Palantir describes Actions and Processes for its Ontology, and HighByte describes controls for what connected agents can access and do in Intelligence Hub. The distinction here is the responsibility assigned to each product in the plant’s deployment, not a claim that either platform stops at data preparation.

The distinction for this article is the role assigned to each layer in a plant deployment. ISA-95 models and ontology infrastructure contextualize orders, lots, and equipment events. Humble consumes that context to prepare a recommendation, show its evidence and constraints, and route an approved task. Humble does not replace the ontology platform or the plant’s integration infrastructure. Actual decision rights and permitted transactions still depend on plant policy and configuration.

For platform selection rather than this decision workflow, see the manufacturing ontology comparison.

See How Humble Turns Contextualized Data Into a Decision

Humble can use contextualized order, lot, and equipment data to prepare a shop-floor recommendation for an authorized person to review. Your plant retains approval rights and decides which actions, if any, can run within set limits. Take the Humble fit test to assess whether a decision workflow fits your existing systems.

Book a Call with Humble to Map Your Systems to Decision Rights

For a deployment review, book a call with Humble to map which systems own order, lot, and equipment records. Bring one decision you want to improve. Use the discussion to identify who approves the action, which tasks go to an operator or agent, and whether your existing integrations permit write-back.

Newsletter

Subscribe to the Humble newsletter for practical guidance on turning manufacturing data into shop floor decisions.

FAQs

Does ISA-95 alone produce a shop-floor decision? No. The ISA-95 Common Object Model describes material and equipment relationships, but a decision still requires current evidence, constraint checks, and an authorized decision owner.

What does an industrial ontology add to ISA-95? An ontology can map site-specific identifiers and time-valid relationships so an ERP order, MES lot, and SCADA line event refer to the same operation. ISA-95 already provides information models. The ISA-95 and ontologies explainer covers their distinct roles.

Does Humble replace MES, SCADA, ERP, or an ontology platform? No. Humble consumes contextualized data to support operational decisions, while those systems retain their assigned records and functions.

Does Humble write back automatically? Not as an assumed part of this example. An approved change reaches the authoritative MES or ERP only through an available, permitted integration. The ISA-95 architecture guide explains that system boundary.

Who decides when Humble can act without human approval? Plant leadership sets decision rights for each workflow, including permitted actions, state and threshold limits, audit requirements, and a human fallback. A scheduler or supervisor approves actions outside those bounds, particularly quality, safety, or commercial changes.