From Prediction to Proof: One Platform for the Chemistry in CMC

Ask a formulation researcher how much of the week goes to rerunning an experiment whose result they already suspected. The answer is rarely small.

Ask where that suspicion would come from in the first place, and the honest answer is often: a folder of PDFs, a stack of patents, and an Excel file someone built for a different project two years ago.

It would be convenient if predicting a molecule's properties solved that problem by itself. It doesn't. A property estimate is only useful if it leads somewhere — into a formulation candidate, an experiment plan, a result that can be checked against a standard. Treating prediction as the whole product is how a platform ends up being one more calculator sitting next to the spreadsheets it was supposed to replace.

At Alche, we built a platform for the chemistry side of CMC — the C in Chemistry, Manufacturing, and Controls — that starts with property prediction but doesn't stop there. It carries a compound from a predicted property, through formulation design and experiment planning, to a result that can be reported and reused.

A molecule doesn't need a physical sample to start answering questions. Represented as a SMILES string — a compact, standard notation for molecular structure — it can be parsed, canonicalized, and run through prediction models before a single milligram is weighed out.

Our platform predicts the properties formulation decisions actually depend on: solubility across a pH range, permeability, logP and logD, pKa, melting and boiling point, density, bioavailability. But the prediction isn't the destination. It's the input to the next three steps: choosing a formulation, planning how to test it, and evaluating whether it worked.

Choosing an excipient is a reasoning problem before it's a search problem. Solubility, partition coefficient, and molecular weight narrow down what a substance can plausibly do — act as a filler, a binder, a disintegrant, a surfactant — before anyone opens a reference table.

Our platform uses the predicted profile to propose formulation candidates directly, and checks each one against precedent: how a similar active ingredient was actually formulated before. A close match is treated as a starting point; an inexact one is flagged as exactly that, not quietly extrapolated as if it were exact.

Once a candidate formulation exists, the next question isn't whether to test it — it's how many runs, at what levels, in what order, to learn the most from the fewest samples. That's a statistical design problem most researchers currently solve by hand, in a spreadsheet, one factor at a time.

Our platform generates the experimental design directly from the formulation variables — the factors, the levels, the run order — so the plan going to the bench is already structured for analysis, not reconstructed afterward.

Before: a hypothesis about an excipient's compatibility got tested the only way available — by running it, then a second time to rebuild a design table nobody had saved. After: the same hypothesis gets a property-based estimate and a generated experimental design before a single sample is prepared, and the physical run is reserved for what prediction and design can't settle on their own.

This isn't about removing the bench. It's about spending bench time on runs that actually need to happen, planned well enough that one pass is usually enough.

A formulation decision rarely rests on the compound alone. It rests on precedent — how a similar active ingredient was handled before, what excipients showed up in comparable formulations, what a patent or a paper says about a critical quality attribute. Normally, that means searching across patents, papers, and internal records that don't share a format, let alone a search box.

Our platform keeps that reference data structured and searchable in the same place as the prediction results, so checking a hypothesis about solubility and checking the precedent for it don't require switching tools.

The real cost of scattered documentation isn't storage. It's reassembly. Every time a project's formulation decisions, experimental design, and evaluation results live in separate files, someone has to manually stitch them back together to answer a simple question: where did we land on this, and why.

Our platform keeps a compound's property analysis, formulation design, experimental design, and evaluation results — including how a result compares against a reference standard — linked as one continuous record, from the first predicted property to the last measured one. When it's time to report out, that record exports as a formatted document — not a set of files someone has to merge by hand.

Every property shown on the platform is labeled as what it is — an estimate, not a measurement. That distinction isn't a footnote. A prediction earns its place by telling a researcher where to spend the next experiment, not by pretending to replace it.

Design-of-experiments plans, dissolution comparisons, and formulation records live next to the property predictions and reference data that motivated them, instead of in a separate document a researcher has to reconstruct from memory.

When a team builds the same comparison spreadsheet more than once, that's not a training gap. It's a sign the platform should have already had the answer. We build toward that, one repeated spreadsheet at a time.

None of this replaces a formulation researcher's judgment, and it isn't meant to. What it removes is the tax paid at every handoff between predicting, designing, and testing — the week spent re-deriving a property that prediction could estimate in seconds, the afternoon spent redrawing a design table that already existed somewhere, and a report stitched together from files that never quite matched. Alche is building this as one example of what happens when prediction is treated as the first step of a workflow, not the whole product.