openfoundry

Independent research project

The foundry for
operational intelligence.

OpenFoundry is my approach to ontology-based enterprise AI, built as a working platform rather than a paper. It gives an agent like Apollo-1 a model of the operation it can query, a schema that constrains what it may conclude, and an audit record it cannot edit afterwards.

This is an independent research project. I build it to test whether the architecture holds and to show it to people working the same problems.

Request a walkthrough →See Apollo-1

OpenFoundry Operations Overview dashboard — 'Is the unit on spec?' with KPI tiles, an off-spec banner, and a flue-gas O2 timeline

Fig. 01 — Operations Overview: is the unit on spec?

the platform

What is
OpenFoundry?

A platform for building governed, ontology-grounded AI agents on real operational context. It takes fragmented plant and enterprise data — historians, alarms, process knowledge, documents — and structures it into a semantic layer that agents can reason over safely, with every answer traceable back to its source. The architecture is the applied form of the knowledge-graph research: five layers, each one a constraint on what the layer above is allowed to conclude.

L1Data & Documents

Historians, alarm and event logs, process documentation, business systems — ingested and mapped as they are, without forcing a rewrite of how the plant already runs.

L2Ontology & Semantic Core

A machine-readable rulebook of what exists in the plant and how things may connect, written in open web standards (OWL, RDF, SPARQL). Every fact is checked against it, so an agent can't reason on a fact nobody approved.

L3Operational Context Layer

Equipment, processes, decisions, and rules connected into one operational model, with a traceable line from any answer back to the evidence behind it.

L4Grounded Agent Runtime

Runs agents on any LLM, chosen by role. Agents reason only over context they can cite.

L5Governance & Audit

Each investigation (hypotheses, evidence, conclusion, corrective actions) is saved in a tamper-evident record.

layer 2

The ontology layer

The ontology says what kinds of thing exist in the plant (pumps, streams, control loops, procedures) and which may be connected to which. The editor enforces it: each cell in the relation matrix is a connection it will either allow or refuse to draw. Derived relations are computed from rules instead of entered by hand.

An agent can't use a relationship the ontology doesn't allow, which is why its answers can be defended.

Ontology schema view showing a relation matrix between plant, system, equipment, sensor, and control-loop classes

Fig. 02 — Ontology: the plant as a governed graph

Private deployment

It runs on the owner's infrastructure and no data leaves it. The owner chooses the models and sets the rules.

Open standards

The knowledge model is stored in OWL and RDF and queried with SPARQL, so it stays readable without OpenFoundry.

Explainable

Every output points to the context it came from, so any decision it supported can be checked afterwards.

Governance built in

Access control, audit logs and approval steps are part of the core design.

capabilities

Grounded on
operational reality.

OpenFoundry agents don't answer from memory. They query the systems that already run the operation — and cite exactly what they found.

Historian Explorer trend chart for TE_8332A with normal-range band and statistics

Historian Explorer: the signal record

Historian & time-series

Sensor trends, statistics and normal ranges with alarms overlaid, searchable in plain language instead of tag codes.

Operations Studio: the plant as a live mimic

Operations Studio

The plant as a live mimic diagram. Every stream, sensor and piece of equipment links to the knowledge graph and can be inspected with one click.

Knowledge Graph: the plant as a graph

Process knowledge graph

Equipment, sensors, streams and control loops as a network you can query, so upstream causes and downstream effects are traced automatically.

Document Center: semantic search

Engineering documents

SOPs, datasheets, and troubleshooting guides retrieved by meaning, always cited by document title and revision.

use cases

Built for the questions
operators actually ask.

OpenFoundry ships with a growing catalogue of governed Skills — reusable, auditable agent capabilities designed to apply across manufacturing, energy and process, construction, and retail operations.

Root-cause investigation

Trace an anomaly to its cause across the historian, alarm log, knowledge graph, and document library.

Shift handover summary

A brief of what happened, what's still active and what to watch, with sources.

Alarm rationalization

Surface chattering, standing, and nuisance alarms against ISA-18.2 criteria.

Sensor health screening

Flag flatlined, drifting, or suspect instrumentation before it hides a real problem.

Trend anomaly scanning

Catch statistically significant deviations before they reach a primary KPI.

Compliance audit summaries

Assemble evidence-backed reports against your own procedures, citing the source for every claim.

Where I think the same approach would work

Manufacturing

Process deviations, equipment health, and procedure compliance across production lines.

Energy & process

Boiler, turbine, and process-unit troubleshooting grounded in historian, alarm, and control data.

Construction

Project, equipment, and safety context connected for on-site and back-office decisions.

Retail

Operational and supply data structured into a context layer agents can query reliably.

Skills Catalogue of runnable investigations grouped into diagnostics, operations, and governance

Fig. 03 — Skills Catalogue: runnable investigations

the agent

Apollo-1

Apollo-1 is the main agent in OpenFoundry. It is built to work the way a senior process engineer would: form a hypothesis, gather evidence, rule out alternatives, and only then conclude.

Its reference deployment is a coal-fired boiler, where it investigates temperature and pressure excursions and traces the root cause across sensors, alarms and procedures.

Investigate on evidence

Every answer traces to the historian reading, alarm, graph node, or document that produced it.

Reason before concluding

Hypotheses are logged, tested, and ruled in or out before any root cause is declared.

Explain its own work

Each investigation is saved in a tamper-evident record of what was asked, what was found and why.

Adapt to a new context

The same approach should work anywhere the operation can be modelled. So far it has only been tested on the boiler.

apollo-1

Built inside OpenFoundry.

Reports screen showing a generated finding with root cause, evidence charts, and a confidence score

reports: generated findingsreference deployment

layer 5

Governance and audit

Changes to the ontology are checked against the schema before an agent sees them. Each investigation is saved in a tamper-evident record, so nobody can rewrite it afterwards.

Governed ontology changesets

Every change to the knowledge model is schema-validated and reviewed before it merges.

Tamper-evident audit trace

Investigations are stored in a record that can be verified cryptographically.

Private deployment, any model

Runs on the owner's infrastructure with any compatible model. No data leaves it.

Audit & RCA screen showing a reasoning log with hypotheses, observations, and an evidence timeline

Fig. 04 — Audit & RCA: reasoning log & evidence timeline

regulatory design basis

Designed with the EU AI Act in mind

An AI system that advises on plant operations could fall into the EU AI Act's high-risk category. I used the Act's requirements for high-risk systems as design requirements for OpenFoundry, and I think they made it a better system regardless of the law.

This is a design choice, not a compliance claim. Conformity can only be assessed for a specific deployment, and OpenFoundry isn't on the market.

Art. 10

Data governance

The ontology defines what may exist and how it may connect, and every fact an agent reads has been validated against it. Nothing enters the reasoning path unmodelled.

Art. 11-12

Documentation & logging

Investigations are recorded as they happen (inputs, hypotheses, evidence, conclusion), so the record comes from running the system instead of being written up afterwards.

Art. 13

Transparency

Every answer carries the historian reading, alarm, graph node, or document revision it came from. An operator can check the reasoning without trusting it.

Art. 14

Human oversight

Escalation is designed around consequence and reversibility rather than model confidence, and writes to the knowledge model need human approval.

Art. 15

Accuracy & robustness

The schema constrains what can be concluded, so the common failure mode is a refusal to answer rather than a confident wrong answer.

knowledge graph

The operation as a graph

OpenFoundry keeps a graph of the operation: processes, systems, decisions, rules and data sources, connected and queryable as they change.

illustration

Want to see it run?

OpenFoundry is still a research project. I'm happy to walk researchers and operations teams through it.

Request a walkthrough →Read the research

The foundry for operational intelligence.

What is OpenFoundry?