Method validation

An ELN that gets a melting temperature wrong is worse than no ELN at all, because you would trust the wrong number. ResearchOS answers that worry by checking its own math, on every commit, against the published tools your field already relies on.

The concept

ResearchOS runs its sequence and lab calculations in your browser. Melting temperature, sequence alignment, restriction digest, translation, protein parameters, the lab calculators, and the cloning engine all execute locally on your machine, with no server round-trip and no proprietary black box. That is good for privacy and speed, but it raises a fair question. How do you know the numbers are right?

The answer is that ResearchOS does not ask you to take its math on faith. For each capability, it compares its own output against a peer-reviewed reference implementation that the field already trusts. These are not numbers we invented. They come from the same tools working scientists cite in papers.

What it is checked against

The reference tools, called oracles in the code, are the established names in computational biology and statistics.

Biopython for melting temperature, alignment, restriction digest, translation, and protein parameters (molecular weight, isoelectric point, and related properties).
primer3 for nearest-neighbor melting temperature, the workhorse behind most primer-design pipelines.
pydna for restriction-ligation and Golden Gate assembly products. Gateway recombination is checked separately against the published attB site sequence.
scipy and statsmodels for the Data Hub statistics engine: t-tests (Welch and Student), ANOVA (one-way, two-way, repeated-measures, Kruskal-Wallis, Friedman), correlation (Pearson and Spearman), simple and multiple regression, logistic regression (including the Firth penalized-likelihood fallback), dose-response curve fitting, Grubbs outlier tests, power and sample-size calculations, and the assumption checks (Shapiro-Wilk, Levene, Brown-Forsythe).
lifelines for the Kaplan-Meier estimator, log-rank test, Gehan-Breslow-Wilcoxon test, and Cox proportional hazards regression (including the likelihood-ratio test and concordance).
scikit-learn and R's pROC for ROC curve and AUC (including the Hanley-McNeil standard error).
R's survival library as a second reference for the Kaplan-Meier, log-rank, and Cox outputs.

For every showcase case, ResearchOS records its own value, the pinned oracle value, the exact tool version, the specific function called, and the committed script that re-derives the reference number. A reader can follow that trail and reproduce it.

Reproducing published results

Matching a reference tool shows ResearchOS computes the same thing another program computes. A stronger check is reproducing what the literature itself reports, so the same validation now includes cases drawn straight from primary sources. ResearchOS translates a gene and reproduces the protein that gene's own GenBank record annotates, digests a known plasmid and reproduces its fragment sizes, and takes a published qPCR standard-curve slope and reproduces the amplification efficiency the paper reports. Each case cites its accession or DOI, every input and reported value is transcribed verbatim from the source rather than paraphrased, and the comparison runs through the same gate as the rest.

Where our result and a familiar figure differ for a real reason, we show the real one and explain it rather than matching the textbook out of habit. The lambda HindIII digest is the clean example. The deposited sequence yields seven fragments, not the eight bands of the classic gel marker, because the extra band comes from the cohesive ends annealing during marker preparation, not from an additional cut site. We pin the honest in-silico result and say why.

Why the numbers cannot silently drift

The honest part is not just that ResearchOS matches these tools once. It is that the match is re-checked automatically and can never quietly fall out of agreement. The public Method validation page and the test that gates the build both call the exact same function, buildTransparencyReport() in frontend/src/lib/transparency/run.ts. The page can never advertise a comparison the test is not enforcing, because they are computed from one source.

That gating test, report.test.ts, runs on every commit. If a future change to a ResearchOS calculation pushes its output past the agreed tolerance for any case, the comparison fails, the test fails, and the build fails before the change can reach you. A documented, explained difference (for example, primer3 using a different nearest-neighbor table) is allowed and shown on the page with its reason. A true, unexplained drift is treated as a bug and stops the release.

The public Method validation page showing a summary of exact matches, cases within a documented tolerance, and a small number of larger documented differences, with a differences spotlight calling out the cases that diverge. — The public Method validation page. Every comparison is counted (exact, within tolerance, or a documented difference), and the cases that diverge are spotlighted rather than hidden.

What this does not claim

Matching a reference tool means ResearchOS computes the same thing the reference computes, faithfully. It does not mean the underlying method is the only valid one, and it does not replace your own judgment about which method fits your experiment. The point is narrower and more useful. When ResearchOS gives you a number, you can confirm it agrees with the tool you would have reached for anyway.