Ask a process engineer whether they would let an AI assistant modify a converged flowsheet, and the hesitation is rarely about capability. It is about trust. Not trust in the abstract, but a specific, practical question: if the tool says it changed a reflux ratio or that a column converged, how do I know that actually happened?
That question deserves a mechanical answer, not a reassuring one. This post lays out what we think that answer has to look like, and why we built Reflux around it.
The failure mode that matters is misreporting, not mistakes
Engineers already know how to handle mistakes. A wrong parameter value gets caught in review. A bad design basis surfaces when the numbers look off. The engineering workflow is built to absorb honest errors.
What the workflow is not built to absorb is a tool that reports a change or a result that did not actually happen. An AI assistant that says "I set the distillate rate to 120 kmol/hr" when the write silently failed, or "the simulation converged" when it read a stale result, has not made a mistake in the ordinary sense. It has broken the link between the report and the model. Every downstream decision inherits that break.
This is the specific hallucination risk in engineering software. It is not that the model might be wrong about chemistry. It is that the assistant's account of what it did might diverge from the state of the simulator.
Write receipts: read every change back
The fix is not a better prompt. It is a verification step that does not depend on the model at all.
Reflux drives Aspen Plus through its COM automation interface, the same interface Python and VBA scripts use. After every write, Reflux reads the value back from the simulator and compares it to what was intended. Only when the read-back matches does Reflux report the change as applied. We call these write receipts.
The distinction matters. "I sent the command" and "the simulator now holds this value" are different claims, and only the second one is useful to an engineer. A write receipt turns every reported change into a verified observation of simulator state rather than an assertion about an action.
Gates before running, gates before reporting
The same principle applies to runs. Reflux checks required-input completeness before invoking the solver, so a run is not launched against a model that cannot meaningfully execute. When the run finishes, results pass quality gates before Reflux reports success. Convergence status comes from what the simulator actually reports, and when a run fails, Reflux reads the run history and connects errors to the specific inputs and blocks involved.
In practice this means three separate checkpoints:
- Before a write is reported: the value is read back from the simulator and verified.
- Before a run starts: required inputs are checked for completeness.
- Before success is reported: results pass quality gates, including convergence status as the simulator states it.
A human review boundary in front of real changes
Verification tells you the tool is honest about what it did. It does not tell you the change was the right one. That judgment belongs to the engineer, so real changes sit behind explicit review.
Natural-language requests become inspectable actions: reading blocks, streams, and components; editing parameters and stream specs; building topology; running the solver. Reflux reads the existing flowsheet first and ties each proposed change to the specific block, stream, and result a reviewer needs to evaluate it. The reviewer sees what will change and why before anything does.
Why simulation demands more than code does
AI coding assistants operate inside a dense safety net. A compiler rejects code that does not parse. Tests fail. A colleague reads the diff. An AI that misreports its work in a codebase usually gets caught within minutes by machinery that exists independently of the AI.
Process simulation has no equivalent net. There is no compiler that rejects a flowsheet whose reported state differs from its actual state. The output is numbers, and those numbers feed decisions about equipment sizing, operating envelopes, and real plants. If the tooling does not verify its own reports, nothing else will.
That is why we think read-back verification, run gating, and a human review boundary should be treated as an engineering standard for AI in simulation, not a product feature. Any tool that writes to a simulator should be able to answer, mechanically, the question "how do you know?" If a vendor cannot describe the verification step between the write and the report, the honest answer is that they do not know.
Where Reflux stands today
Reflux supports Aspen Plus today, with a simulator-agnostic adapter architecture designed to extend to other process simulators. Engineers work with it from Slack, Teams, a local control panel, the CLI, or any MCP client. Every path goes through the same verification layer.
Request a demo if you want to see write receipts and review gates working against a live Aspen Plus flowsheet.