Reaction Optimization Overview

Reaction Optimization recommends experiments by combining prior reaction evidence, measured outcomes, and constraints such as yield, selectivity, impurity level, and regulatory limits.

Scope

Gaussian-process surrogate modeling in plain language
Multi-objective optimization across yield, selectivity, and impurity profile
Regulatory constraints from ICH thresholds
Human acceptance, modification, or rejection of recommendations

Phase C engines and the capability readout

Phase C added six reaction engines to the module — yield models, retrosynthetic route scoring, forward-prediction cross-checks, a self-driving-lab (SDL) safety layer, the capability seam that governs them, and a dataset-license pipeline. They ship as default-off governed guests: no heavy dependency enters the backend’s pyproject.toml. torch, aizynthfinder, transformers, and rxn4chemistry stay site-installed extras probed at decision time, so nothing heavy activates implicitly and a deployment that installs none of them still runs the module. (v0.63.0, 2026-07-23)

What a chemist can run today

Only the surfaces usable with no heavy dependency are exposed over the API. Three are owner-scoped to a single reaction project:

Yield predictions. A lightweight surrogate is fit on that project’s own completed experiments and used to rank candidate conditions. The backend that produced each number is recorded verbatim alongside the run, and degraded conditions are disclosed in per-prediction warnings rather than smoothed over.
Route scores. A chemist-supplied route is scored by the frozen safety and green-chemistry engines. Reagents are screened, an atom economy that cannot be weighed is refused rather than guessed, and a Mermaid rendering of the route tree is persisted with the score.
Forward checks. A supplied prediction is cross-checked against the frozen engines before anyone acts on it. An unrecognised risk ranks worse than critical, so a check can never read milder than what was actually screened.

Two more are deployment-wide, read-only, and not project-scoped:

Capability readout. A single global answer to “what does this deployment actually have turned on?” — see below.
SDL site status. Read-only, and read-only by design.

What needs no extra, and what is deliberately unwired

Route scoring and forward checking need no extra. Scoring a chemist-supplied route and cross-checking a supplied prediction both run on the frozen safety and green-chemistry engines, and work on a deployment with nothing optional installed. That is the point of the split: the scoring half ships, the generative half does not.

The generative heavy paths are not reachable from any endpoint: AiZynth route proposal, RXN / transformers forward prediction, torch GNN training, and SDL execution stay deliberately unwired until the site extras and an off-request worker exist. This is a planned seam, not a shipped capability.

The SDL layer is the sharpest case. The engine exists as a library — arm / heartbeat / disarm on one monotonic timeline, a bounds-checked envelope that refuses non-finite caps and parameters, and a hash-chained journal verified by both head hash and entry count — but there is no HTTP execution surface at all: no arm, no run-step, no abort. A registered-routes test pins that absence, so an execution route cannot be reintroduced by accident. Manual make / test / learn remains the path.

The honesty readout

The capability readout reports, per capability (yield_gnn, retrosynthesis, forward_prediction, sdl_execution), whether it is enabled by flag, available by dependency probe, active for a real decision, which modules are missing, and a named reason. It is stateless and reads nothing from the database. Two of its answers look like bugs and are not:

yield_gnn reports active: false even when its flag is on and torch is installed, because activation is a per-call decision bound to a specific benchmark-gate artifact (promotion evidence tied to a gold-set checksum and a model version), never a standing global state.
retrosynthesis and forward_prediction have no generative fallback. When their extras are absent they are reported unavailable, so the corresponding generative actions are absent from the interface rather than degraded into something that looks like the real thing. This does not affect route scoring and forward checking, which are produced by endpoints that need no extra at all.

Everything here is decision support

Yield predictions are advisory decision support that rank candidate conditions for review — never a synthesis instruction or a guarantee. Route scores rank options for review and are never a safety determination. Forward checks annotate a proposal and surface flagged chemistry rather than hiding it. Every route score and forward check is recorded as requiring human review, and a qualified chemist must review every prediction before it is acted on.

Training-data governance

Training-data governance ships as a library-level control over the currently unwired training path, not as a running ingestion service: the pipeline’s license registry refuses unregistered datasets, treats HTE corpora as benchmark-only, and prohibits Reaxys, Pistachio, and Bretherick’s as sources. Content-addressed splits keep the benchmark gold set out of training, so promotion evidence is not produced on records the model was trained on.

The six engines carry 129 tests that pass with no heavy dependency installed, and went through two adversarial review passes; 34 confirmed findings were fixed, with the second pass reviewing the remediation itself.

Authoring plan

Interview the process chemist before finalizing this guide. Ask them to explain the workflow as if they were speaking to a smart non-statistician:

What makes a good first experiment set?
Which variables should be continuous, categorical, or fixed?
What does the optimizer know after each iteration?
When should a chemist reject a recommendation?
Which impurity or safety constraints are non-negotiable?

The final page should explain Bayesian optimization without jargon: MolTrace builds a probabilistic model of the reaction landscape, estimates uncertainty, and recommends the next experiment that best balances likely improvement with learning value.

Recommendation card

The next-experiment recommendation card should show:

Suggested temperature, concentration, catalyst, solvent, and time.
Predicted yield, selectivity, and impurity profile.
Uncertainty or confidence interval.
Constraint checks and any ICH-linked warning.
Accept, modify, reject, and rationale actions.