Plant OverviewUNITUnit 1 · Full power operation
Sim
Train
Shadow
Advisory
Superv.
Hybrid
Unit
--:--:--
— UTC
NOMINAL
TRAINING EXERCISE — NOT A LIVE PLANT. Drills run on the console's point-kinetics simulator (the Reactor Kinetics model). For skills demonstration only — this is not a certified operator-training simulator and confers no qualification.

Drill Control

Idle — select a drill
Time×

Drills

point-kinetics
Each drill scores your control of the live reactor model. Power, period, temperature and xenon feedback are the same physics used on the Reactor Kinetics screen.

Live Reactor

no drill selected
Reactor Power
100%
Target
—
Reactor Period
∞s
Rod reactivity
0pcm
Power vs target band
Control rod bank (reactivity)0 pcm

Objective & Score

00:00
—
/ 100
  • Select a drill to load its objectives.

Waste & Spent Fuel

representative · demonstration
Fleet-wide waste inventory driven by each unit's operating history (cumulative burnup), online state and decommissioning progress. Spent-fuel and activity figures are representative decay models for demonstration, not a real inventory. Decommissioning a unit on the Decommissioning page feeds its dismantling debris into the totals below.

Fleet Waste Inventory

by classification

Spent-Fuel Storage

per unit

Decay Heat & Activity

after discharge
Decay heat
— kW
Activity (of initial)
— %
Years since discharge0.0 yr
Spent fuel must cool in the pool (here ~5 yr, amber line) before it is cool enough to move to dry-cask storage. The long tail is Cs-137 / Sr-90 (~30 yr half-life).

Disposal Pathway

spent fuel route
High-dose cask handling is exactly the kind of task the Robotics fleet exists for. A deep geological repository is a decades-long, national-policy matter — shown here as roadmap, not an operational stage.

System Dependency Graph

click a node to trace propagation
nominaldegradinglimit / trippedfeedback (negative)
Node colours are driven live by the unit selected in the top bar. Click any node to highlight everything it influences downstream, with approximate propagation delays. Solid arrows are forward influence; dashed violet are negative feedback loops.

Advanced Optimization — Reinforcement Learning

Beta · Twin-only · Advisory
An adjacent, experimental capability alongside the supervised predictive diagnostics — it does not replace them. A reinforcement-learning agent learns a rod-control policy by trial and error inside the digital twin only, never on a real plant. Its output is advisory, carries no control authority, and is fully interpretable: the learned policy is a readable table, not a black box. The agent trains here against a fast reduced-order surrogate of the reactor model. Task: hold a target power with minimal control-rod movement (load-follow with low component wear).

What “Train policy” actually does

plain-English
1 · Nothing is fed in. The agent is not trained on real-plant data, history, or any dataset. It learns purely by trial and error — playing thousands of short what-if episodes against a fast, simplified stand-in for the reactor (a surrogate), not the full point-kinetics model.
2 · What it is trying to achieve. After every move it gets a score: reward = −(power error)² − 0.3 if it moved a rod. So it is rewarded for sitting on the target power while moving the control rods as little as possible (load-follow with low wear). The target is picked at random each episode from 70 / 80 / 90 / 100 %.
3 · What it can see (the “state”). Only two things, each sorted into coarse buckets: how far power is from target, and which way power is heading (rising / falling). That makes 35 distinct situations.
4 · What it can do (the “actions”). Five rod moves only: insert hard (−8), insert gently (−2), hold (0), withdraw gently (+2), withdraw hard (+8).
5 · What actually gets “trained.” A small lookup table — 35 states × 5 actions = 175 numbers (a Q-table). Each number is the agent’s learned guess at how good that action is in that situation. Training just nudges those numbers toward better values (Q-learning, learning rate 0.2, discount 0.95). There is no neural network and no black box — the whole “brain” is that table.
6 · Explore first, then exploit. Early on it makes random moves ~35% of the time to discover what works; that randomness decays toward 2% as it converges, so late training mostly follows what it has already learned.
7 · When it is finished. After 3,000 episodes the status reads policy ready. The finished policy is simply the best action for each of the 35 states — which is exactly the readable grid you see in Learned Policy on the right.
8 · What you do with it. Apply once in twin reads the live model’s current power, looks up the policy’s recommended rod nudge for that situation, and applies it a single time on the kinetics model. It is advisory and clamped, with no authority over a real plant.
In one line: it discovers a rod-control rule by trial and error in a toy model, and the result is a small, readable table — not a network, and not learned from any real data. Press Train policy to watch the reward curve climb and the table fill in; press again to pause.

Training in Digital Twin

untrained
0 episodes
Reward = −(power error)² − movement penalty. Rising reward means the agent is learning to hold target power with fewer rod motions.

Learned Policy (interpretable)

withdrawholdinsert
Rows = power deviation (low→high), columns = trend (falling→rising). Each cell shows the action the policy learned — fully readable.

Optimization Advisory

advisory only
Target power
100 %
Train the policy to enable advisory.
no authority on a real plant

Why this action

explainability
Learned value of each candidate action for the current state. The agent selects the highest; the inputs that define the state are listed in the advisory.

About NEXUS-1 — Author & Scope

Phase 0 · read me

I'm Grigorios Agathangelidis. I am not a nuclear physicist, nuclear engineer, or nuclear power-plant specialist of any kind — my background is in Electrical Engineering and Software Engineering.

NEXUS-1 is a personal project. I set out to immerse myself in the nuclear-energy domain, study it as thoroughly as I could, and combine what I learned with my experience from enterprise-level software projects. My goal was never to present myself as an expert in nuclear engineering — it was to explore a fascinating domain and apply my own skills in software architecture, simulation, visualization, user interfaces, and systems design.

The physics and engineering models in this project are studied and representative — not validated, certified, or reactor-specific. Where something is illustrative rather than real, I have tried to say so throughout the interface. Nothing here is connected to a real plant, sensor, or control system.

What I hope comes through is the effort, curiosity, research, and engineering mindset behind the work: taking an unfamiliar and demanding domain, learning it properly, respecting the limits of that knowledge, and turning it into a coherent, working system.

This build is Phase 0 of the project — the demonstration and design phase. The phased plan toward a production system (a .NET C# microservices backend, an Angular front end, SQL Server, and message-based services) is described in the accompanying Project Roadmap.

© 2026 Grigorios Agathangelidis · All rights reserved · Build NX1-094C79E0A366D34F
Demonstration / educational software — not a licensed analysis tool and not connected to any real reactor.

Regulatory landscape

awareness · not compliance
A production system of this kind would sit inside an instrumentation-and-control and human-interface regulatory framework. This Phase 0 demonstrator is informed by the principles below but is not developed, verified, qualified, or certified against any of them. They are listed to show awareness of the landscape a real deployment would have to enter — nothing here makes a compliance claim.
StandardWhat it governsHow this project relates
NUREG-0700Human-system-interface design-review guidance — control-room displays, alarm presentation, information hierarchy.The console's layout, alarm handling and display hierarchy follow its general principles; it has not been evaluated against the guideline.
IEC 60880
IEEE 7-4.3.2		Software and digital-device criteria for category-A safety functions — development rigour, verification & validation, qualification.The bar a production safety function would have to meet. This is unverified demonstration software and makes no safety claim.
IEC 61226Categorisation of I&C functions important to safety (classes A / B / C).A monitoring and advisory console like this classifies low; its outputs are advisory and never actuate a safety function.
IEC 61513General lifecycle requirements for I&C systems important to safety — the umbrella standard.The framework a production build of this platform would be developed under.
These are the software, HMI and I&C standards that bear on the layer this project actually exercises. Reactor- and safety-system design codes are out of scope for a monitoring demonstrator and are intentionally not claimed. NEXUS-1 is not certified against any standard.
Telemetrylive plant sensors (simulated)
measured
Power 100%Fuel 600°CRods 0%
Simulationpoint-kinetics expected
model
Power 100%Fuel 600°CRods 0%

Core Control

drives the selected unit
Rod insertion (selected unit)
34 % inserted
drag a core to rotate
cool → hot (fuel temperature)
Both cores show the unit selected in the top bar. Left is that unit as seen through (simulated) sensors — noisy and slightly lagged; right is its expected (clean) model state. The controls drive the selected unit, and SMR modules render as a smaller core. In a real digital twin, divergence between measured and modelled is the early-warning signal.

Twin Divergence

Power Δtelemetry vs model
0.0 %
Fuel temp Δ
0 °C
Twin status
in sync
Transient divergence is normal (sensors lag the model); sustained divergence would indicate a sensor fault or model error.
Point-Kinetics Engine · real reactor dynamics
PWR-900 representative constants for this unit class
0.0 s
simulated time
⚠ Approaching prompt critical (reactivity ≥ $1). In a real reactor this is a runaway condition; the model clamps for stability.
Reactor Power
100% rated
decay heat 6.60% · thermal 100%
Net Reactivity
0pcm
$0.00
Reactor Period
∞s
SUR 0.00 dpm
Fuel Temp
600°C

Reactor Power

100% · stable
Neutronic power (% rated)Total thermal incl. decay heat

Reactivity Balance

pcm

Controls

1× speed
Control reactivity (rods)
0 pcm
Time
Try: a small +10 pcm step (watch the prompt jump, then feedback settle to a new power); a SCRAM (note power can't drop instantly — delayed neutrons give a tail); then switch to 600× after a shutdown to watch the xenon transient build over hours.

State

Coolant Tempaverage
305 °C
Xenon-135% of equilibrium
100 %
Iodine-135% of equilibrium
100 %
Neutron pop.relative
1.00

Reactivity

pcm vs time

Temperatures

°C
FuelCoolant

Xenon & Iodine

% of eq.
Xe-135I-135

Feedback structure (automation view)

live closed-loop block diagram
ρ_rod · control input 0 pcm Σ − ρ_net 0 pcm Point kinetics 6 delayed-neutron groups n · neutron power 100.0 % Fuel thermal node T_F = 600 °C Doppler gain α_D ρ_Dop = 0 pcm K_FC Coolant node T_C = 305 °C Moderator gain α_M ρ_mod = 0 pcm I-135 → Xe-135 chain Xe = 100 % eq Xenon worth −K_Xe·(Xe−Xe_eq) ρ_Xe = 0 pcm
The solver drawn as a closed-loop control diagram: rod worth is the external input, and three negative feedback paths (dashed violet — the same convention as the System Dependencies screen) return through the fuel node, the coolant node and the xenon chain into the summing junction. Every block is a literal function inside window.KIN.model, the gains are the constants listed on the Model Analysis screen, and every value on the edges is computed live with the same formulas as the Reactivity Balance panel above — this diagram is a schematic of the implementation, not an illustration. It is why a +pcm step self-regulates instead of running away. The linearized closed-loop transfer function of exactly this loop is derived — and verified against the running solver — in Model Analysis → Frequency response; formal stability claims about any real reactor remain out of scope.

The model (what this actually computes)

honest notes
This solves the point-kinetics equations with six delayed-neutron precursor groups (U-235 data), the standard model of reactor dynamics: dn/dt = (ρ−β)/Λ · n + Σ λiCi, with precursor equations dCi/dt = βi/Λ · n − λiCi. Reactivity ρ is the sum of control-rod worth plus feedbacks: Doppler (fuel temperature), moderator (coolant temperature), and xenon-135 (a fission-product poison governed by coupled I-135/Xe-135 balance equations). Fuel and coolant temperatures follow a lumped two-node thermal model driven by power. Integration uses operator splitting (exact precursor update, implicit neutron update) so it stays stable despite the stiffness of the equations.

Honest scope: the structure is the real physics and reproduces the real qualitative phenomena (prompt jump, reactor period, power self-regulation through negative feedback, post-shutdown xenon transient). The constants (generation time, feedback coefficients, thermal gains, xenon worth) are representative textbook-order values for the selected unit class, not tuned to a specific reactor. It is an educational simulator, not a licensed analysis code.
Model Analysis · verification of the point-kinetics engine
PWR-900 selected unit — representative constants for this class
Every figure on this page is computed live from the same point-kinetics model the console runs — the parameters listed are the literal constants inside the solver, and each check integrates that solver against a closed-form reference. Nothing here is hand-entered. This verifies the solver's numerical fidelity to the point-kinetics equations; it does not claim agreement with any specific real reactor, because the constants are representative values for the selected unit class (see the note on the Reactor Kinetics screen).

Solver validation

computed vs reference
The inhour and prompt-jump checks run the neutron kinetics with temperature/xenon feedback disabled — that is the regime those closed forms describe. The small non-zero errors are the genuine numerical-integration error of the live scheme, not cosmetic figures. Half-life and yield rows compare the model's representative constants against textbook values; differences reflect the representative constants, not a solver fault. Decay-heat rows evaluate the 12-group afterheat model analytically (shutdown from infinite operation) against the Way–Wigner correlation P/P₀ = 0.0622 t−0.2; the Δ shown is the genuine residual of the group fit.

Model parameters

single source of truth

Operating margins

live · demonstrator setpoints

Sensitivity & uncertainty propagation

normalized · dimensionless

Xenon forecast

forward integration from live state

Frequency response · closed-loop transfer function

linearized · verified vs solver
The point-kinetics solver linearized about full power, in closed loop — the transfer function of exactly the structure drawn on the Reactor Kinetics feedback diagram. Zero-power kinetics G₀(s) = 1/(s·(Λ + Σβᵢ/(s+λᵢ))); feedback F(s) = α_D·G_TF + α_M·G_TC − K_Xe·G_Xe from the linearized two-node thermal model and the I-135/Xe-135 chain (including the burnout cross-term σφ·Xe_eq·δn); closed loop H(s) = 10⁻⁵G₀/(1 − 10⁻⁵G₀F), in % rated power per pcm of rod worth. Every constant is read live from the running solver. Verification: the measurement button drives the same stepState integrator the console runs with a ±5 pcm rod sinusoid and extracts amplitude and phase by projection over whole periods — the Δ shown is genuine and includes the integrator's real numerical error. The inhour validation above is the ω→0 limit of G₀; this check generalizes it across frequency. Zero-power rod-oscillator and noise measurements of |G₀| are real commissioning techniques. Honest scope: the xenon branch only shapes the ultra-low-frequency end (|s| ≪ 10⁻⁴ s⁻¹ — hours), so it is analytic-only here while the measured points span the kinetics/thermal band; constants are representative, so no stability claim is made about any real reactor; and a point model has no spatial xenon modes (excluded for the same reason DNBR is).
Tagged Entities
0
In Restricted Zones
0
Access Violations
0
Compliant
0

Defence in Depth

access layers

Zone Occupancy

Live Presence (simulated RFID / GPS tags)

Each person, vehicle and robot carries a simulated access tag. If an entity is detected in a zone its clearance does not permit, it is flagged as a violation. This is an illustrative model, not a real tracking system.

Zone Permissions Matrix

policy
Authorisation by entity class and zone. Higher-restriction zones (containment, vital area) are limited to specific cleared classes; contractors and logistics vehicles are confined to outer areas.
Total Assets
0
Available
0
Deployed
0
Missions Ready
0/5

Mission Readiness Test

capability · charge · dose
Each standard mission needs a capable robot that is available, sufficiently charged, and has dose budget remaining (robot electronics have a cumulative radiation tolerance). Stress the fleet and see which missions can still be covered.

Plant Layout — Reactors / Steam / Turbine

click a reactor to switch it on or off
⟳ Auto-rotate
□ Labels
∿ Steam flow
Drag the scene to rotate. Toggling a reactor here also changes it across the whole plant.
A stylised 3-D schematic of the fleet: each unit — large PWR containments and small SMR modules — drives its own dedicated turbine-generator, and all units feed a single shared switchyard, the grid connection — the one element a real fleet actually shares. Containments are drawn cutaway (semi-transparent) so the steam generators are visible where they really are: per-loop vessels inside containment on the PWRs (3 on PWR-900, 4 on PWR-1300, glowing teal when the unit raises steam) and inside the reactor vessel itself on the integral SMR modules. Active units glow and spin their own turbines; standby units are dark. Representative geometry — not a survey model.

Fleet Lifecycle

cradle to grave
Begin decommissioning on a unit to shut it down and move it into the dismantling lifecycle. A running reactor cannot be decommissioned — it is shut down first.

Roster

—

Absence Stress Test

Min shift complement
Simulate staff absences and check whether each sector still meets its minimum shift complement and keeps every critical role covered. In a real plant, a minimum-staffing breach triggers Technical Specification action statements.
Plant Output
0MWe
Units Online
0/5
Installed Capacity
0MWe
Grid Frequency
50.00Hz

Grid Connection

400 kV bus
Each reactor unit or SMR module synchronises to a shared bus. Online units (cyan) feed the grid; offline modules are isolated. Add capacity by bringing modules online.

Reactor Units / Modules

Switch on / off · select
This plant is modular and scalable: a mix of large PWR units and small modular reactor (SMR) modules. Switch any module on or off, or Select one to drive the detailed Reactor pages. Plant output is the sum of all online units.
Electrical Output
MWe
Thermal Power
MWt
Reactor Power
%
Availability
99.4%

Plant Energy Flow

Mimic
Reactor
MWt
→
Steam Gen
bar
→
Turbine
→
Generator
MW
→
Grid
Hz
Open Reactor › Control Rods and move the rods — the change propagates through every node here in real time.

Subsystem Status

Reactor Core
Nominal
Primary Coolant
Nominal
Turbine / Generator
Watch · vib
Radiation Monitors
Normal
Safety Systems
Armed
Grid Connection
Synced

Output Trend

60 min

Recent Alarms

3 active

Core Parameters

PWR · 157 Assemblies
°C
Core Temp
BAR
Pressure
%
Reactor Power
%
Rod Insertion
Reactivityrelative to critical
pcm
Core Burnupcycle average
18.4 GWd/tU
Boron Concentrationcoolant
642 ppm

Control Rod Banks

BankStepsStatus
Detailed rod control on the Control Rods page.

Core Map

Assembly temp
Each cell is a fuel assembly, colored by outlet temperature. Hot channels toward the center.

Core Temperature Trend

60 min
⚙
Interactive simulation. Move the rods and the model recomputes reactivity → neutron flux → thermal power → grid output, live across the whole console. In a real plant this command path is hardware-isolated; here it is a training simulator.

Rod Drive Control

RCCA · Bank D
WithdrawnInserted
Insertion
%
Reactivity pcm
Green = positive (power rising), red = negative (power falling). At equilibrium it sits near zero.

Core Cross-Section

Rod insertion depth
Rods (violet) descend from the top of the active core (cyan) as insertion increases, absorbing neutrons and reducing power.
Reactor Power
%
Thermal Power
MWt
Electrical Output
MWe
Reactor Period
∞s

Rod Bank Positions

BankSteps (of 228)PositionMode

Drive Mechanism & Trip

Lift / Hold Coils
Energized
Stepping
Holding
Trip Breakers
Closed
Rod Bottom Lights
Clear
SCRAM Readiness
Ready
Source Range
—cps
Intermediate Range
—A
Power Range
%
Startup Rate
0.0DPM

Axial Flux Profile

Top → Bottom
As rods insert from the top, flux is suppressed in the upper core and the peak shifts downward (axial offset).

Reactivity Balance

pcm · illustrative
Control Rods—
Boron (soluble)−1180
Moderator Temp Coeff−28 /°C
Doppler (fuel temp)−2.4 /°C
Xenon-135—
Net Reactivity—

Power Range Trend

60 min
Main Steam Pressure
bar
Steam Flow
kg/s
Feedwater Flow
kg/s
Condenser Vacuum
kPa

Steam Generators

2 × U-tube
SGPressureNR LevelSteam FlowStatus
SG-1 bar % kg/sNormal
SG-2 bar % kg/sNormal
Main Steam Header
bar
MSIVs
Open
Steam Dump / Bypass
Closed

Turbine Train

Governor Valveload demand
%
HP Turbine
In service
LP Turbines (×2)
In service
MSR Outlet Temp
221 °C
Turbine Speed
RPM

Secondary Flow

Mimic
Steam Gen
bar
→
HP Turb
—
→
MSR
221°
→
LP Turb
—
→
Condenser

Steam Pressure Trend

60 min

Primary Coolant Loops

2-Loop
Loop A FlowRCP-1A · running
km³/h
Loop B FlowRCP-1B · running
km³/h
Hot Leg AT-hot
°C
Cold Leg AT-cold
°C
Feedwater Flowsecondary
kg/s

Pressurizer

% LVL
Level
BAR
Pressure
Heaters
Auto
Spray Valve
Closed

Steam Generator Levels

SG-1 Level
%
SG-2 Level
%
Condenser Vacuum
kPa

Loop A Flow Trend

60 min
Active Power
MW
Reactive Power
MVAr
Generator Voltage
kV
Power Factor

Generator Output Trend

60 min

Grid Synchronization

400 kV bus
Grid Frequency
Hz
Turbine Speed
RPM
Main Breaker
Closed
Sync Status
In Sync
Phase Angle
+2.1 °
⚠
Reactor protection systems are hardware-isolated, deterministic and human-supervised. This platform is a monitoring & advisory layer only — no authority over safety actuation.

Area Radiation Monitors

—
LocationDoseStatus
Containment Interior µSv/hNormal
Aux Building0.040 µSv/hNormal
Fuel Handling0.090 µSv/hNormal
Turbine Hall0.022 µSv/hNormal
Stack Effluent0.04 %limBelow limit
Aux / fuel / turbine / stack values are illustrative scalings of the simulated containment dose and reactor power for the selected unit — not independently modelled channels. Turbine-hall dose tracks live steam (N-16) and collapses when the unit is offline.

Safety System Status

Read-only
Reactor Protection (RPS)4 channels
Armed
SCRAM Availabilityrods withdrawn
Ready
ECCSemergency core cooling
Standby
Containment Isolation
Armed
Emergency Diesel Gen
Auto · 2/2

Containment

—
Containment Pressure
bar
Containment Tempderived from power level
38 °C
Sump Level
Normal
Decay heatsix-group model
— MWt

Containment Dose Trend

60 min

Alarm & Event Management

TimeSeveritySourceMessageStatus

AI Diagnostics

two layers
This screen has two layers. Predictive diagnostics (further down) is the working Phase-0 demonstrator — failure-probability and anomaly forecasts fed by the live Component Registry. The Domain-Specific Language Model (DSLM) assistant is the planned production layer: a nuclear-domain model served locally and air-gapped, grounded on plant data, advisory only. It is documented here as the target architecture — it is not running in this build.
DSLM Assistantplanned production layer

Domain-Specific Language Model

ROADMAP · PLANNED
Local & air-gapped
Served on-site via Ollama in an isolated environment with no external network egress — plant data never leaves the site and there is no runtime dependency on any third-party service.
Grounded by retrieval (RAG)
Answers are grounded in a curated corpus — plant procedures and technical specifications, vendor manuals, regulatory guidance (IAEA / NRC / EPRI), historical event reports — plus the live Component Registry and telemetry from this console.
Advisory & human-in-the-loop
It explains, summarises and proposes; it never actuates. Every exchange is written to the Compliance / audit record.
Interpretable
Each answer cites the registry items, incidents and documents it drew on, so a reviewer can trace the reasoning.
Specialised, not trained from scratch
An open base model specialised by retrieval and light fine-tuning — the realistic way domain models are built.
Plant inputs
telemetry + Component Registry + document corpus
➤
Retrieval (RAG)
pulls the relevant grounding context
➤
Local DSLM
Ollama · isolated / air-gapped
➤
Cited advisory
explanation with sources
➤
Operator + audit
human-in-the-loop, logged

Example Interaction

illustrative · scripted · not a live model
Operator: FV-104 is throwing a cluster of alarms — what is going on?
The FV-104 alarm cluster matches the feedwater-valve cascade pattern recorded as EVT-2026-0418: a sticking control valve drives a feedwater-flow oscillation that trips level and flow alarms together. The Component Registry shows FV-104 latency rising, and the alarms are correlated, not independent. Treat the valve as the primary suspect and confirm actuator response before resetting the downstream alarms. Advisory only — operator confirms.
Grounded in: Component Registry (FV-104) · Root-Cause EVT-2026-0418 · Alarms & Events
Operator: Is the SG-2 outlet thermal anomaly a real excursion or a sensor artefact?
Most likely a measurement artefact, not a process excursion. As in EVT-2026-0419, a genuine thermal excursion would be corroborated by independent instruments on the same loop; here that corroboration is absent, which points to electrical noise on the channel rather than a real temperature change. Check the instrument channel and grounding before treating it as a process event. EMI is handled as a diagnostic fault class; EMC qualification is a hardware responsibility. Advisory only.
Grounded in: Root-Cause EVT-2026-0419 · Anomaly Detection (SG-2) · Component Registry
Operator: What is Coolant Pump 2A's degradation risk over the next 30 days?
About 18% — low. Bearing-temperature trend is within band and vibration is nominal. This figure comes from the predictive layer; the DSLM's role is to explain and cross-check it against the registry and recent events, not to replace it. Recommend routine inspection at the next outage. Advisory only.
Grounded in: Predictive Digest · Component Registry (Pump 2A)
Operator: Give me a one-line plant risk summary.
Highest current risk is FV-104 (valve latency, correlated alarms); turbine-seal vibration is trending and warrants watching; other tracked components are within band; no active SCRAM. Advisory rollup — operator confirms.
Grounded in: Component Registry · Anomaly Detection
These are pre-written examples showing how the grounded DSLM would respond — no model runs in this build. In production, inference would run locally via Ollama in an isolated environment, with answers grounded in the live registry and document corpus.
Predictive DiagnosticsPhase-0 demonstrator · working

Natural-Language Query

predictive layer · scripted example
Predict probability of coolant pump degradation over next 30 days.
Response: Pump 2A shows an 18% degradation probability — bearing temperature trend within normal band; recommend routine inspection at next outage. Confidence 0.86. Illustrative survival model (gradient-boosted); figures are demonstration values, not identified from plant data.

Component Risk · 30-day horizon

ComponentSignalRisk
Coolant Pump 2ABearing 18%
Turbine SealVibration 41%
Heat ExchangerFouling 27%
Valve FV-104Latency 62%
Feed Pump 1BCavitation 9%

Anomaly Detection

Thermal AnomalySG-2 outlet
Investigate
Alarm CorrelationFV-104 cluster
3 linked
Efficiency Driftcondenser
Within band
Vibration Patternturbine bay
Trending
Sync Lag
ms
Model Fidelity
97.8%
Signals Mirrored
1842
Max Deviation
1.4%

Simulation vs Live Plant

Hybrid twin reconciliation
SignalLive PlantTwin ModelDeviationTrend (residual)Status
Each row compares the model’s expected value against a (simulated) sensor reading; the residual is their gap. Click a signal to chart it below. Transient residual is ordinary sensor noise; sustained, growing residual would flag a sensor fault or model error — Loop A Flow carries a slow simulated sensor drift to show the difference. Illustrative model, not identified from plant data.

Measured vs Model

—

Residual vs Tolerance

—

Historical Trends

Backed by a time-series store (PostgreSQL + TimescaleDB). Scrub, zoom and overlay any recorded signal; export windows for incident review.

Event Reconstruction

0 live · EVT-2026-0418
14:02:11.340
Baseline nominal
All parameters within band. Loop A flow 18.4 km³/h.
14:07:53.118
Flow oscillation detected
RCP-1B discharge pressure begins 0.8 Hz oscillation. AI flags vibration pattern.
14:09:02.770
Operator advisory raised
Advisory mode recommends pump speed trim. Acknowledged by Operator 4417.
14:11:48.005
Flow deviation > 3σ
Loop B flow drops to 16.9 km³/h. Critical alarm. Safety margins unaffected.
14:18:22.610
Recovery
Pump trim applied; oscillation damped. Returned to nominal at 14:21.

Root-Cause Hypotheses

Bearing wear (RCP-1B)primary
74%
Voltage transientcontributing
19%
Sensor faultruled out
7%
Timeline and factors derive automatically from synchronized telemetry, confirmed by an engineer, then feed the compliance log.
Incident

Causal Fault-Propagation Graph — EVT-2026-0418

click a node to test it as root cause
Engineered backbone (FTA)
Data-informed edges (ML weight)
Artefact edge (EMI → sensor)
Candidate edge — rejected
fault origin degrading tripped / cascade healthy / ruled out solid = fault-tree · dashed violet = learned weight · dashed orange = artefact · struck grey = rejected / absent
The backbone is built from the plant's fault and event trees (PRA/PSA) and component topology — every edge is auditable. Active alarms light the nodes live; the data-informed layer only re-weights or proposes edges for engineer confirmation, it never defines the causal structure. Toggle the layers above; click a node to highlight everything it explains downstream with propagation delays.

Immutable Audit & Compliance Log

Append-only · hash-chained
Timestamp (UTC)ActorActionTypeSeal
14:21:08Operator 4417Acknowledged alarm ALM-3391Operator✓ a3f9…1b
14:09:02Operator 4417Accepted AI advisory ADV-118Operator✓ 7c20…e4
14:00:00SystemRegulatory log batch sealedRegulatory✓ 9d81…0a
13:54:31Engineer 2210Opened incident EVT-2026-0418Event✓ 4e6b…cc
13:40:17SystemTwin reconciliation committedSystem✓ b1a7…52
Every operator action and system event is written once to a hash-chained, tamper-evident store. Each seal references the previous, so any alteration breaks the chain. Supports regulatory export.

Microservice Health

ServiceStateMetric
Telemetry Ingestion Healthyk msg/s
Digital Twin Sync HealthyΔ ms
Compliance & Audit Healthyappend-only
Incident Analysis Degradedre-indexing
AI Diagnostics Healthy12 models
Visualization Gateway HealthySignalR · 6 conn

OT Security Posture

Zero-Trust
NetworkSegmented
HSMSealed
MFAEnforced
IDSActive
Audit TrailStreaming
Safety LayerIsolated

Network Zones

Purdue model
L0/L1 Safety
Air-gapped
⇢
L2 Control
Read-only tap
⇢
L3 Supervisory
Platform
⇢
L4 Enterprise
Analytics
Data flows up the zones through one-way gateways; no command path flows back down to the safety layer.

What this module does

QA
Every rod that goes into the core is inspected without being damaged, using Non-Destructive Testing (NDT). This module lets you pick a rod type, choose an individual rod, and review its simulated radiograph (X-ray / gamma film) together with the results of each NDT method and a final acceptance verdict. Select a rod type from the sidebar to begin.

Rod Inventory

—

Radiograph

RT —
Contrast Zoom
Brighter = denser material (cladding walls, welds, metallic inclusions). Darker spots = less material (voids, porosity, cracks). Toggle Annotations to label detected indications.

Validation Verdict

NDT Results

—

Non-Destructive Testing Methods

Reference
MethodDetectsTypical use
Radiography (X-ray / Gamma)Internal cracks, voids, inclusions, weld defectsThick metal components, weld inspection
Ultrasonic (UT)Internal cracks, thickness loss, delaminationsReactor vessels, piping, welds
Visual (VT)Surface defects, corrosion, deformationRoutine inspection
Eddy Current (ECT)Surface & near-surface cracksSteam generator tubes
Dye Penetrant (PT)Surface-breaking cracksWelds, machined surfaces
Magnetic Particle (MT)Surface / near-surface cracks in ferromagnetic materialsSteel components
Note on MT: reactor rod cladding is usually zirconium alloy or austenitic stainless steel, which are not ferromagnetic, so Magnetic Particle Testing generally cannot be used on the rods themselves — it appears as "N/A" in the results. It is used on ferritic steel structural parts.

NX-Script Console — read-only query

Appendix C · live state
A read-only window onto the live console state, in the small language of Appendix C. Every get traces to a value the simulation actually computes. Dual-tier signals (power, coolant_temp, xenon, thermal_mw, electrical_mw, rod_insert, capacity, online) read the fleet model uniformly for any unit, so they are comparable across the fleet. Point-kinetics signals (period, reactivity_pcm, decay_heat, fuel_temp, kin_power, kin_xenon) read the rigorous six-group solver but only for the selected unit — for any other unit they refuse, because the solver tracks one unit at a time. get fleet.X returns an array; aggregate explicitly with sum / mean / max / min. There are no act verbs here: set, scram, hold, step, wait are refused by design.
Ctrl/⌘+Enter to run 
Ready. Output appears here.