ISA-95 Manufacturing Knowledge Graph for Operations Intelligence

A large manufacturing enterprise had already invested in operational reporting, production dashboards and quality tracking. The challenge was not the absence of data. The challenge was that production events, equipment states, material lots, work orders, quality deviations, maintenance activity and process parameters were still analysed as separate fragments.

When a production anomaly occurred, teams could usually identify the immediate symptom: a yield drop, a quality deviation, an equipment alert, a repeated non-conformance or an abnormal process reading. What took far longer was understanding how that signal connected to the wider operation. Which work orders were affected? Which equipment hierarchy was involved? Which material lots passed through the same process segment? Which upstream operations showed similar behaviour? Which corrective action had worked in comparable situations before?

AgentFaktory designed and implemented an ISA-95 aligned manufacturing knowledge graph to turn operational data into a connected intelligence layer. The graph represented production, equipment, material, personnel, process, quality and maintenance entities as relationships rather than isolated rows. This allowed the client to move from dashboard-based observation to graph-based investigation, anomaly detection and recommended action.

The challenge

The client’s existing environment could report production performance, quality exceptions and maintenance activity, but those views did not explain the connected operational story. A quality team could see NCRs. A production team could see work-order progress. A maintenance team could see equipment alerts. A plant manager could see throughput and downtime. The missing layer was the relationship model that connected all of these views.

This created friction during investigations. When an abnormal quality pattern appeared, analysts had to manually check the production order, equipment used, material lot history, process route, previous anomalies, inspection results and maintenance records. Each investigation required a new set of joins, assumptions and spreadsheet logic.

• Anomalies were detected in separate systems but not connected across the full manufacturing operation.
• Equipment, material, process and quality records did not share a single investigation model.
• Teams could not quickly list all work orders, units, lots or operations affected by a suspected issue.
• Recommendations were dependent on expert judgement and past experience rather than reusable evidence paths.
• AI-assisted investigation needed structured operational context before it could produce trusted answers.

What was built

AgentFaktory built a manufacturing operations knowledge graph aligned to ISA-95 concepts. The graph connected the physical model of the plant with the execution model of production and the event model of operations. Equipment, process segments, material lots, work orders, personnel roles, quality events and maintenance activity became connected graph entities.

The graph was designed as an operational intelligence layer, not a diagramming exercise. Each node and relationship was created to support a business question: where did the issue occur, what was running at that time, which material was consumed, which equipment was involved, which quality event followed, what similar cases happened before, and what action should be taken next.

Relationship-first operations intelligence

The important shift was treating relationships as first-class operational data. A work order ran on a line. A process segment used a piece of equipment. A material lot was consumed by an operation. A unit was produced through a sequence of steps. A quality deviation occurred after a specific operation. A maintenance event affected equipment that was later used in production. These relationships are where root-cause investigation becomes possible.

Each relationship retained evidence: source table, source field, timestamp, matching rule, confidence and lineage. This allowed users to distinguish direct operational facts from inferred relationships. The graph could therefore support both automated traversal and human review.

Full-operation view

The knowledge graph was not limited to one dashboard or one plant function. It was built to represent the full operational flow: planning, execution, production events, equipment usage, material consumption, quality checks, deviations, maintenance actions and recommendations. This made it possible to move from a local symptom to a broader operational context.

For example, a yield anomaly could be traced from the production order to the process segment, from the process segment to equipment usage, from equipment usage to maintenance events, from the operation to material lots, and from material lots to other impacted work orders. That path is difficult to represent cleanly in a normal BI model, but it is natural in a knowledge graph.

Anomaly detection layer

The anomaly detection layer used the graph as operational context. Instead of flagging only a metric breach, the system could enrich the anomaly with connected entities: equipment, process segment, material lot, work order, quality event, maintenance history and similar prior cases.

This made alerts more useful. A production variance was no longer just a number outside a threshold. It became an evidence-backed operational event: where it happened, what it touched, what changed before it, what quality signals followed it and which other units may be impacted.

• Equipment-level anomaly: abnormal behaviour around a specific line, cell, tool or asset.
• Process-level anomaly: unusual cycle time, rework, yield or deviation pattern within a process segment.
• Material-level anomaly: abnormal quality or performance pattern linked to a material lot or supplier batch.
• Quality-level anomaly: repeated defect or NCR pattern connected to a common operation or equipment path.
• Operational-sequence anomaly: a pattern that appears only when events are evaluated as a connected path rather than standalone records.

Recommendation engine

The recommendation layer converted graph findings into practical operational follow-up. It did not simply rank alerts. It used the connected evidence path to suggest the most appropriate next action: inspect affected units, review a process segment, check a material lot, raise a maintenance task, hold downstream production, or compare the issue with similar historical cases.

Recommendations were designed with traceability. A user could see the anomaly, the graph path, the impacted entities and the evidence behind the suggested action. This helped business teams understand why a recommendation was made and decide whether to act, escalate or monitor.

AI explanation layer

The AI explanation layer sat above the graph. It did not invent root causes from a prompt. It retrieved graph paths, anomaly context, evidence records and recommendation outputs, then translated them into a clear operational explanation for engineers, quality teams and plant leadership.

This gave users a more useful answer than a dashboard alert. A production leader could ask why an anomaly was flagged and receive a structured explanation: the affected operation, equipment path, material exposure, related quality events, similar historical cases, confidence level and suggested next action.

Outputs delivered

• ISA-95 aligned operations entity model covering equipment, process segments, work orders, materials, personnel roles, quality events and maintenance signals
• Graph-ready entity and relationship tables with evidence, confidence and lineage
• Anomaly context views linking abnormal signals to affected operations, equipment, materials and quality outcomes
• Root-cause traversal outputs for production, quality and maintenance investigations
• Recommendation outputs with action type, priority, owner, evidence path and status
• AI-ready graph explanation views for operational Q&A and case summaries
• Operations dashboard and API layer for impacted entity analysis and follow-up tracking

Governance and controls

The graph was built with controls for operational trust. Recommendations were separated from automated execution. Low-confidence relationships were not used for high-impact recommendations without review. Sensitive operational identifiers were controlled through role-based views. Every recommendation retained the graph path and source evidence used to generate it.

• Source lineage for nodes, relationships, anomalies and recommendations
• Confidence scoring for inferred relationships and similar-pattern matches
• Separate investigation, recommendation and AI context views
• Human approval for production-impacting actions
• Auditability of recommendation evidence and user follow-up status

How success was measured

The client measured the value of the graph through operational usefulness. The key questions were whether teams could trace an anomaly faster, identify impacted entities more reliably, reuse prior investigation paths, generate better recommendations and explain decisions with evidence. The graph became valuable because it reduced the number of manual joins and assumptions required during real production investigations.

Outcome

The client gained a connected operations intelligence layer across production, equipment, material, quality and maintenance data. Instead of treating anomaly detection, root-cause analysis and recommendations as separate capabilities, the knowledge graph connected them into one repeatable operating model.

The largest impact was the ability to move from isolated operational signals to evidence-backed action. Teams could start with an anomaly, traverse the affected operation, understand the connected entities, compare with similar historical cases and trigger a recommended follow-up workflow.

AgentFaktory role

• Defined the ISA-95 aligned graph model and operational entity hierarchy
• Mapped production, quality, material and maintenance data into graph-ready structures
• Designed relationship evidence, confidence and lineage rules
• Built anomaly context outputs and root-cause traversal patterns
• Designed recommendation structures for operations, maintenance and quality follow-up
• Created AI-ready graph explanation views for business-readable investigation summaries