Can Ontology Transform the Nuclear Industry into a Real‑Time Computable System?

Introduction – Expanding nuclear production is not only a hardware challenge; it requires compressing supply‑chain, engineering, quality, personnel, and regulatory states into a single real‑time digital thread. Centrus disclosed at AIPCon 9 that project‑control data could lag up to eight weeks while planning to grow from 16 to 11,520 centrifuges, making spreadsheets a systemic risk. The proposed solution is to build a unified operational model with an ontology and let auditable agents perform impact analysis and transaction write‑back within a human‑approval boundary.

01 – Expanding the System State Space – With only a few devices, teams rely on experience, meetings, and spreadsheets. When centrifuge count reaches the ten‑thousand level, each object simultaneously links to material, process, quality records, personnel shifts, suppliers, and critical paths. The combinatorial explosion of relationships turns the problem from “record more data” into “continuously compute the entire system’s dependencies.”

02 – Treating Each Device as a Living Object – A sustainable object model must define sites, centrifuges, parts, tasks, suppliers, defects, inventory, personnel, and milestones. Every object carries attributes and connections to BOM, routing, quality batch, schedule, and plan dependencies. For example, a material defect can be traced through the relationship graph to calculate its impact on installation, staffing, cost, and delivery dates. Unlike ETL‑only data integration, an ontology preserves object identity, business state, semantic relationships, and action permissions.

03 – Agent Workflow as Influence‑Graph Optimization – The agent’s typical chain is: listen to defect, delay, or resource‑change events; retrieve related objects and dependencies; generate root‑cause hypotheses; compute impact on critical path, inventory, and staff; compare alternatives such as supplier swap, expedited shipping, or staff re‑allocation; finally submit the recommendation and rationale for human approval. Each step depends on structured context rather than pure natural‑language reasoning.

In a bearing‑quality case, the system compared cost versus schedule, suggested switching suppliers and expediting the order, and reduced transport time from three weeks to one week. The key is that the recommendation references quality batch, supplier capability, plan node, and budget impact, avoiding decisions based on isolated data islands.

04 – Human‑in‑the‑Loop Transaction Chain – In highly regulated domains, an agent’s ability to call tools does not equal autonomous control. The required execution architecture is: the agent proposes a solution, professionals review and modify it, an authorizer approves, and an orchestration layer writes back to scheduling, payroll, procurement, and site‑notification systems via controlled interfaces. The chain must provide identity authentication, least‑privilege access, approval policies, idempotent writes, failure rollback, and non‑repudiable audit. Agent output remains a candidate decision; production actions must be deterministic transactions. Maturity is measured by explainability, clear approval, and traceable execution rather than autonomy percentage.

05 – Metrics Focus on Decision Latency – When project control spans the full value chain, every defect handling, supplier replacement, and staff adjustment leaves a structured trace for risk models and optimizers. Continuous monitoring of data freshness, anomaly detection time, recommendation‑to‑approval cycle, write‑back success rate, critical‑path deviation, and audit coverage is essential. Scaling from 16 to 11,520 devices expands organizational complexity; the foundation of industrial AI is a closed loop of real‑time events, operational ontology, constraint optimization, human approval, and transaction execution. Only a stable loop can move agents from demo to regulated production.