Batch process simulation, file first

Reflux now works with a commercial batch process simulator through a file-first adapter. The agent reads the input deck, makes value edits, and verifies every edit by reading it back from the file, so a change either lands exactly as written or is reported as failed.

The boundary is explicit: structural changes that belong in the vendor's own interface are declined in plain language instead of guessed at, and results load only from real run summaries. If a run has not happened, Reflux says so rather than estimating.

What's included

  • A live activity view that shows the flowsheet and each edit as it happens.
  • A one-call study tool that turns a prepared case into a design estimate inside the workbench.
  • Receipt-verified value edits, and honest refusals for structural work.

The simulator follows the conversation

Reflux now picks the right simulation backend for each request and keeps up as the conversation moves between tools. Naming a simulator always wins over any earlier session choice, and Reflux no longer interrupts work to ask which tool to use.

Boundaries between adapters got honest too. An adapter declines work that belongs to a different tool with a plain-language explanation instead of failing deep inside the simulator, flowsheet paths are never guessed, and progress labels name what is actually running.

What's included

  • Automatic backend selection, with an explicit simulator name always taking priority.
  • Clean refusals for foreign flowsheet files instead of low-level automation errors.
  • Tool status surfaced in the workbench, including opening the native application to watch changes land.
  • Early DWSIM support in development builds: flowsheets in the open-source simulator build and solve end to end, with conditions read back from the solved case.

Numbers with provenance

Every number Reflux reports now carries provenance. Values come from the simulator, never from the model's own arithmetic, and a provenance guard blocks figures that cannot be traced back to a read.

The same pass added unit-error detection and stricter run reporting: a claim about results is only made when a run actually produced them.

What's included

  • A provenance guard on reported values, backed by simulator reads.
  • Likely unit errors flagged before they reach a conclusion.
  • Run summaries that only claim what the solver returned.

Verified against Aspen Plus V14

Reflux's existing-flowsheet operations are verified against Aspen Plus V14: reading blocks and streams, editing parameters and stream specs, running the solver, and checking convergence on real cases.

Behind it, the planner that produces reviewed plans got a checkpoint and cleanup pass, and one warm simulator session is now shared across chats so a follow-up question does not pay the cost of reopening a case.

What's included

  • Existing-flowsheet read, edit, run, and convergence checks verified on V14.
  • Structured plans with explicit steps before anything touches a simulator.
  • A warm session shared across chats, with the simulator as the source of truth.

Visible distillation train

Reflux's default showpiece workflow now rebuilds a multi-column Aspen Plus train in the foreground, step by step. It starts from a verified seed chemistry case, clears the flowsheet, places three RadFrac columns, connects feed, recycle, product, pump, and letdown valve paths, then runs and saves a reusable backup case.

This is still a deterministic demo path, but it is much closer to the product shape Reflux is aiming at: an engineer can watch native simulator work happen, inspect the transcript, and review the produced case instead of trusting a hidden script.

Reviewed runs
Visible T5 distillation Saved visible_t5_distillation_demo.bkp
Reset active worksheet Blank sheet confirmed before build
Viewport refresh pass PFD redraw, zoom full, ribbon compensation
Aspen Plus foreground build
Blocks 3 columns + pump
Mode Visible Real Run
Output Saved .bkp
The changelog preview mirrors the foreground simulator behavior without embedding a fragile screenshot.

What's included

  • Seed-backed chemistry so the visual build starts from a known-good case.
  • Foreground Aspen Plus progress for block, stream, connection, configure, run, and save steps.
  • Viewport hardening that keeps the PFD drawing surface in frame during the demo.

Visible execution for simulation studies

Reflux now presents simulator work as a sequence of reviewed, visible steps: reading case files, planning the change, producing generated helpers, running the simulation, and summarizing the output.

The simulator remains the source of truth, while the agent's work becomes inspectable enough for process teams to trust before anything meaningful is changed.

Transcript opened Aspen Plus case drafted reviewed plan created FLASH, FEED, VAPOR, LIQUID ran simulation saved generated backup and summarized products

What changed

  • Reviewed tasks can change the visible plan, files, and report state.
  • Generated files are exposed as separate reviewable artifacts.
  • Preview panes highlight the exact rows and sections being discussed.
Read the article ->

Request access flow for early teams

Early Reflux usage is routed through a lightweight request flow so simulation teams can share context before anyone touches a real simulator workflow.

The same access request nudge now appears from product-like demos, CLI prompts, and contact calls to action. That keeps curiosity in the page while making the next step explicit.

What changed

  • Prompt demos reveal a request-access message after a user enters text.
  • The contact page collects role, company, email, use case, and message details.
  • The flow works on a static site without adding a backend dependency.
Read the article ->

Reviewed plans before simulator changes

The workflow now emphasizes a review gate before meaningful simulator actions, so teams can approve intent before execution. Reflux frames every edit as a plan, then requires an explicit confirmation point before native case mutation.

That gives reviewers a plain-language record of the intended engineering change and keeps prompt interpretation separate from simulator state changes.

Why it matters

  • Plan fingerprints bind approval to the exact executable plan.
  • Dry runs can validate shape, template choice, and output warnings first.
  • Process teams get a review artifact that matches the saved simulator work.
Read the article ->

Workflow context for repeatable studies

Reflux examples now describe reusable engineering paths instead of one-off scripts, which better matches how teams repeat and audit studies across adapters.

The public surface connects context collection to reviewable plans, deterministic template paths, simulator adapters, and future changelog automation from merged, user-facing product work.

What's next

  • Keep filtering public notes to merged work tagged changelog or user-facing.
  • Continue expanding the Aspen Plus, HYSYS, and Aveva Pro II adapter surfaces without coupling their models.
  • Use human review before publishing generated changelog drafts.
Read the article ->