The Refinery
The facility sits on the Texas Gulf Coast, east of Houston. It processes crude through three distillation units, with Unit 3 (vacuum distillation) handling the heaviest fraction of the crude slate. The refinery operates continuously under a Process Safety Management program, holds a Texas Commission on Environmental Quality (TCEQ) air permit governing emissions from each process unit, and files an Environmental Protection Agency (EPA) Risk Management Plan as a covered facility under the Clean Air Act. Three AI models run against Unit 3 alone: a process optimizer, a predictive maintenance system, and a scheduling tool. The facility employs 23 engineers with more than 15 years of tenure at the site.
That collective knowledge: informal thresholds, equipment behavior under edge conditions, running sequences that diverge from the written SOP for reasons the SOP does not explain. None of it appears in any system of record. It is evaluated daily against outputs from AI models that were built without it. Three events will expose that gap. All are already scheduled.
The Gap Nobody Inventories
AI models in industrial environments produce recommendations. Those recommendations are evaluated against rules: regulatory limits, operating procedures, engineering judgment built over years of direct observation. In most operations, those rules exist in three places: regulatory filings and internal documents, the heads of experienced engineers, and knowledge transmitted informally across shifts. The first category is retrievable. The second and third disappear when people do.
The result: AI systems continue producing outputs after the people who knew how to evaluate those outputs have left. The model does not know a rule exists. The operator inheriting the system does not know the rule was never encoded. The gap between what the AI was built against and what it is actually running against widens, invisibly. This is the inventory problem that does not appear on any AI deployment budget and does not surface until a decision fails audit or causes an incident.
What Nexus Maps Before Anything Runs
Before any AI recommendation is validated, Nexus builds an operational graph of the refinery: process units, applicable regulations, AI models, and the people whose knowledge governs each. Rules are machine-executable (condition, threshold, severity, source) and every rule carries its origin: a regulatory citation or a named expert, with confidence score and reviewer. When Ray’s retirement is logged as a Change Event, Nexus identifies every rule carrying his name and flags them for re-review before he walks out. The graph does not assume continuity. It tracks where continuity is at risk.
The Acquisition Closes. The Knowledge Gap Becomes Visible.
On day one, the acquiring company's engineering team opens the Nexus Ontology Manager. The system surfaces 47 rules carrying departed engineers as their primary source. It identifies which AI decisions are validated by those rules, which equipment those decisions govern, and which rules have not been re-reviewed since their original author left. The acquiring company does not inherit a liability it cannot see. It inherits a documented knowledge gap with a defined remediation scope.
Without Nexus, this is an invisible event from the AI systems' perspective. The models continue running. The rules they were built against remain in documents and in the heads of people who no longer work there. Nobody has a map of which AI decisions are operating on institutional knowledge that has left the building.
That distinction changes the risk profile of the acquisition. A refinery with Nexus deployed is not just an asset with AI systems. It is an asset whose operational knowledge is inventoried, traceable, and structured to survive the people who built it. In a transaction, that is a measurable difference in what the buyer is actually purchasing.
What Happens When an AI Recommendation Arrives
Six weeks into deployment. The process optimizer recommends increasing throughput on Unit 3 by four percent. The recommendation enters the Nexus validation engine. Nexus identifies the process context and equipment set, retrieves every active rule governing that unit, and evaluates each against current operating state.
Two rules flag. The first is a regulatory limit on pressure differential under sustained high-load conditions. The second is sourced from Ray's capture session: an informal ceiling on throughput that applies when ambient humidity exceeds a threshold the SOP does not mention. Both return ALERT status. The recommendation does not reach the workflow in its original form. It reaches the operator with both flagging rules surfaced alongside it, with sources, confidence scores, and operating conditions at time of evaluation.
The operator decides. The recommendation, the flagging rules, the model version, and the operating state at that moment are written as an immutable record. It does not expire when Ray retires. It does not disappear when the company changes hands.
Ray Retires. The Knowledge Does Not.
Eight months after deployment, Ray's last day is administrative. The knowledge transfer completed three months earlier, through a structured capture session that produced 23 rules sourced to Ray and reviewed by a second process engineer before activation. Eleven are active constraints on Unit 3. Four have already flagged AI recommendations that would have passed the validation engine without them.
The refinery does not hold a technical debrief on Ray's last day. The debrief already happened, in a form the system can evaluate. His name remains on 23 rules. His departure triggers a Change Event that flags those rules for periodic re-review, now assigned to the engineer who succeeded him. The knowledge does not retire. The obligation to maintain it transfers to someone who can.
The Model Updates. The Validation Scope Resets.
When the process optimizer upgrade is deployed, Nexus logs a Model Change Event: the updated model identifier, the deployment timestamp, and the prior version it replaced. Nexus then traverses the rule graph to identify every rule whose source evaluations were conducted against version 2.1 outputs. It scopes the re-validation to rules governing the decision types where the model's behavior changed, as characterized in the vendor's release documentation and any internal test results. Rules governing unaffected domains remain active. The rest are flagged for re-review before the updated model is authorized to the same operating scope.
This is not a full audit. It is a delta. The facility does not re-validate 23 rules because one version number incremented. It re-validates the six rules that govern throughput recommendations under high-load conditions, because those are the rules whose evaluation assumptions the model change plausibly affects. The scope is computable from the graph. Without the graph, the scope is unknown and the usual response is to assume continuity, or to run a full re-validation that consumes resources disproportionate to the actual change.
The third event is structurally identical to the first two. A change occurs in the environment the AI is running against. The validation layer either tracks the change and computes the remediation scope, or it does not. If it does not, the AI continues producing recommendations whose evaluation basis is now unverified.
What Compounds Over Time
Nine months after initial deployment, the refinery's AI models have run against validated rules across all three process units with a clean incident record. Rule coverage on Unit 3 exceeds 90 percent. The conditions required to expand AI authorization are now met: the process optimizer acts without per-decision approval within defined operating windows. Not through a policy decision. The evidence record showed that rules were current, knowledge sources were verified, and the operating envelope was documented. The upgrade from supervised to semi-autonomous operation is a contractual milestone, not a posture.
New engineers joining after the acquisition are onboarded against the same rule set Ray helped build. The knowledge Ray carried is encoded in the rule library. The knowledge that left with departing engineers is documented, flagged for re-review, and being reconstructed through structured interviews with the engineers who remain.
The Architecture Behind It
The architecture is not new. Defense and intelligence organizations have operated decision systems with the same structure for decades: nuclear command and control, Signals Intelligence (SIGINT) correlation pipelines, and battlefield management systems such as the Joint Automated Deep Operations Coordination System (JADOCS) all rely on an ontology of real-world objects, a validation layer checking outputs against structured knowledge, and a change propagation engine that computes what re-evaluation is required when the environment shifts. Those systems work because decisions are governed by explicit, traceable rules rather than by the implicit knowledge of whoever is available. The model itself is interchangeable. What matters is the validation layer that sits above it.
BelmanAI Nexus is built for exactly these events: model updates, retirements, and acquisitions that expose what was never written down or never tied to a specific model version. It converts what your best people know into infrastructure and rechecks only what the change affects. Your data stays on-site; your model choices stay yours.