Building a Semantic Field Runtime for Manufacturing with Raspberry Pi and Virtual Agents — A Chinoba PF Demo for Anomaly Precursors, Impact Scope, and Response Traces —

🎥 The YouTube version is also available:

Building a Semantic Digital Twin with Raspberry Pi and Mac From Factory Signals to Decision Context

Books: A Practical Guide to Semantic Digital Twin for Physical Al: Building with Chinoba PF Ontology • Knowledge Graph • DSL • Decision Trace

What matters in manufacturing AI is not merely identifying a single anomaly correctly.

A production site contains many signals and records: equipment conditions, material lots, product serial numbers, fixture changes, work environments, and maintenance histories. When these are separated across different screens and databases, it becomes difficult to answer the questions that matter when something begins to go wrong:

When did the change begin, and what changed first?
Which products, lots, or processes may be affected?
What should be checked next, and who should choose which response?
And, after acting, was the response actually effective?

To explore these questions, I built Semantic Field Runtime Studio as a Chinoba PF demonstration.

The demo uses three Raspberry Pi devices as Semantic Field Nodes (SFNs), each recording a different kind of field evidence. A System Twin running on a Mac, together with Virtual Agents, transforms that evidence into semantic context, impact candidates, investigation hypotheses, and a Decision Trace.

Three Raspberry Pis Represent Different Field Realities

In this demo, the Raspberry Pis are not treated as a small server cluster. Each one is a Field Node that represents a different boundary of the manufacturing environment.

For example, the Material Node reads the lot number on a material container and the serial number of an individual product using a barcode or RFID reader. By associating these readings with cycle-start and cycle-complete events from the Machine Node, it creates a production record showing which product was processed in which operation with which material lot.

The important point is that the Nodes do not infer causes. A Field Node is responsible for producing attributable Evidence: what was observed, when it was observed, and how it was observed.

The System Twin Turns Distributed Evidence into Manufacturing Context

The Machine Node alone cannot determine which products or lots are associated with a torque change. The Material Node alone cannot tell whether equipment behavior changed while a lot was being used.

The System Twin connects equipment, products, lots, fixtures, processes, locations, and time.

Machine SFN ── equipment changes ─┐
Material SFN ─ product and lot records ─┼─→ System Twin ─→ impact scope, investigation hypotheses, and trace
Zone SFN ──── process context ────┘

The System Twin is not simply a dashboard. It performs at least the following functions:

• Validates the source, timestamp, freshness, and completeness of Evidence
• Resolves relationships among equipment, lots, serial numbers, processes, and locations as a Knowledge Graph
• Detects change points and anomaly candidates by comparing observations with normal conditions
• Traces back from an anomaly candidate to potentially affected products, lots, and processes
• Connects human responses and subsequent results into a Decision Trace

In conventional IoT systems, torque readings, lot histories, and environmental values are often presented as separate charts. The System Twin brings them together as one manufacturing context. It makes it possible to explain not only which products should be reviewed, but also why they should be reviewed.

Virtual Agents Are Separated So That Inference Is Not Presented as Fact

The demo does not treat AI as a single, all-purpose decision-maker. Instead, it uses Virtual Agents with distinct responsibilities.

There is a reason for this separation. Even if an AI states, “The fixture is the cause,” in fluent language, that statement is not necessarily an observed fact.

In Chinoba PF, information is displayed in distinct categories.

This distinction is not only about explainability. It forms part of the Trust Infrastructure required for people to use AI safely in operational settings.

What Happens in the Demo

The demo follows a scenario in which torque variation gradually increases during tightening operation Assembly-20.

No individual reading immediately exceeds a threshold. However, compared with the normal distribution, the pattern begins to shift.

09:58  Fixture JIG-04 is replaced
10:02  Torque variation begins to increase
10:05  Product P-1024 is processed using LOT-A17
10:25  LOT-A17 is replaced with LOT-A18

The System Twin displays the anomaly candidate as a set of relationships:

TorqueVariation-01
  ├─ observedAt → TorqueStation-01
  ├─ follows → FixtureChange JIG-04
  ├─ overlaps with → MaterialLot LOT-A17
  ├─ may affect → P-1024 ... P-1041
  └─ occurs in → Assembly-20 / Cell-A

Here, P-1024 through P-1041 are not confirmed defective products. They are impact-verification candidates: products associated with the same equipment and lot during the time period in which the anomaly candidate was observed.

The AI proposes hypotheses such as:

• Mechanical misalignment after the fixture replacement
• A material-property difference in LOT-A17
• A change in machine settings or work instructions

These hypotheses are not conclusions. They are candidates for the next investigation.

People Select Responses and Learn from the Outcome

At the demo’s Human Gate, a quality engineer reviews the Evidence, Context, impact-verification candidates, and hypotheses, then selects an appropriate response:

• Additional inspection
• Lot hold
• Fixture inspection
• Continued monitoring

For example, when “Additional inspection” and “Fixture inspection” are selected, the decision-maker, grounds, scope, and actions taken are all recorded in the Decision Trace.

Afterward, the fixture can be readjusted and the system can verify whether torque variation has returned to the normal range.

Evidence → Context → Impact → Human Decision → Outcome → Trace

At this point, anomaly detection becomes more than a one-off alarm. It becomes a learning loop that detects changes early, explains potential impact, supports human response, and feeds the outcome back into future decisions.

What the Demo Visualizes

The application includes five screens.

The purpose of this application is not to showcase flashy AI automation. It is to make it possible for anyone to trace which facts AI referred to, what was derived as context, and where unverified hypotheses begin.

What Is a Semantic Field Runtime?

A Semantic Field Runtime is not merely a mechanism for collecting field signals in the cloud.

It combines Field Nodes that hold Evidence at real-world boundaries, a System Twin that integrates relationships as meaning, a Trust Runtime that separates inference from fact, a Human Gate where people take responsibility for responses, and a Decision Trace that preserves outcomes.

By treating these elements as one runtime structure, the Semantic Digital Twin moves beyond visualization.

AI is not prediction. It is decision.

Prediction is important. But value in the field comes from connecting predictions to grounded responses and recovery, then returning their outcomes to the next decision.

Chinoba PF will continue to develop the Semantic Field Runtime as an experimental and implementation platform for this purpose.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance