A model scoring 94 percent on a held-out test set may be producing recommendations evaluated against rules no one has verified in two years. Operators do not know what changed. Nothing is logged. That is the actual state of most AI deployments in regulated and industrial operations.
Model accuracy is the wrong metric. The right question is what happens between the model’s output and the operational decision. That gap is where AI deployments either earn their place or accumulate risk. In most operations, that gap is unstructured.
Nexus Goes On Top of Your Existing Models
Your existing models keep running. The validation layer goes on top.
A typical AI deployment starts with a model: a vendor-supplied process optimizer, a predictive maintenance tool, a scheduling system. It produces recommendations. Operators read them. Decisions are made. Nothing in between is structured, logged, or traceable.
Nexus installs the layer above those models. It does not touch the models themselves. It does not require a vendor switch or a retraining project. It sits between the model’s output and the operator’s decision, and it makes that space structured, validated, and verifiable.
Phase 1 · Days 0–15 · Map What Exists
The first deliverable is an inventory. Most operations have never had one.
Before any rule is written, Nexus builds an operational graph: equipment in scope, regulations governing each unit, AI models you plan to deploy or are already running, and the people whose knowledge informs how those recommendations will be evaluated. The graph does not require a database migration or a systems integration project. It is built through structured input sessions with your team.
The signal that this phase worked: the graph surfaces something that was not in any existing system of record. A regulation that applied but was not tracked. A model running against a unit that was not formally scoped. A knowledge dependency on a person who was not identified as a critical source. In one common case: a TCEQ air permit governing three process units was not linked to the AI model producing throughput recommendations for those units. The model had no rule for it. If the inventory matches exactly what you already knew, the mapping sessions did not go deep enough.
Phase 2 · Days 15–45 · Capture What People Know
A knowledge capture session is not a meeting. It produces machine-executable rules.
Process engineers, operators, and compliance leads are interviewed in structured sessions scoped to a specific unit and domain. Outputs are not notes or summaries. Each output is a rule: a condition, a threshold, a severity level, and a named source. Rules are confidence-scored and reviewed by a second person before they go live. Nothing activates without sign-off. A 90-minute session with a senior process engineer typically produces 8 to 12 draft rules. At least one will describe a condition the official SOP does not mention.
The signal: rules surface knowledge that was never in writing. Informal thresholds. Equipment behaviors under edge conditions. Operating sequences that diverge from the documented procedure for reasons the document does not explain. If every rule produced by a capture session matches something already on record, the sessions did not reach the right people.
Phase 3 · Days 45–75 · Validate Every Recommendation
The first flag matters more than the first hundred clean validations.
When rules go live, AI recommendations route through the validation engine. Each recommendation is evaluated against every active rule governing that unit and operating context. Recommendations that pass log cleanly. Recommendations that flag surface the conflicting rule, the named source, and the operating conditions at time of evaluation. The operator decides. The decision, the flagging rules, the model version, and the operating state are written as an immutable record.
The signal: a flag that changes a real decision. If no flags appear in the first 30 days, the rules are not calibrated, not that the operation is running cleanly. A validation layer that never flags is not protecting the operation; it is failing to engage with it. The fix is not more rules. It is narrower rules: tighter conditions, lower thresholds, scoped to the operating range where the AI model is actually making calls.
Phase 4 · Days 75–90 · Track What Changes
A rule library that stops changing is a rule library that stopped working.
Personnel departures, regulatory updates, and model version changes are logged as Change Events. Each event triggers automatic identification of rules whose sources have changed or whose governing conditions may be out of date. Those rules are flagged for re-review and routed to the appropriate reviewer. The rule library does not assume continuity. It tracks where continuity is at risk.
The signal: the rule library is still current six months after deployment. If it is not, the validation layer reflects what was known when the project launched, not what governs decisions today. An out-of-date rule library is worse than no rule library, because it creates the appearance of validation without the substance.
What Day 90 Looks Like
Day 90 does not produce a benchmark score. It produces a record.
Across a single process unit, a 90-day deployment produces a rule library with named sources and review dates; a decision log with model version, operating state, and flagging rules at time of evaluation; a change event record showing which rules were reviewed after each personnel departure or regulatory update; and an audit trail that answers the question any regulator, acquirer, or new engineer will eventually ask: what did the AI recommend, what rule evaluated it, who decided, and why.
Two change events in 90 days is a low but not unusual number for a single-unit deployment. One was a personnel change. One was a TCEQ permit amendment. Both triggered rule re-review within 72 hours.
No system without that record can produce it retroactively. The rules that governed decisions three months ago exist only if they were captured at the time. The knowledge that informed them exists only if it was structured before it left.
Filling that space requires structure: a rule library, a validation engine, a change propagation mechanism, and a signed audit record. That is what Nexus installs. Not a larger model. Not a new vendor.