How the work is checked

A bioinformatics result usually arrives as a report and a folder of figures. Checking it properly means rerunning the analysis yourself, which almost nobody has time for. A good share of each project here goes into making that unnecessary: stating what was done, connecting each reported result to the data and code behind it, and handing over an environment your own people can rerun.

What you get

  • An analysis your own people can rerun, without us in the room.
  • Figures and tables traceable back to the data and the code that produced them.
  • Statistical choices stated and examined against the study design, rather than assumed.
  • A repository you keep: the code, the manifests, the checks and the decisions, with a record for each result of what was verified and what was not.

1. Scope and study design

Before anything is computed we agree what question the analysis is meant to answer, what the data can and cannot support, and what the deliverable is. That conversation sets the checks as well: which results will be verified, how discrepancies get reported, and what the project will not try to establish.

Thresholds, methods, what counts as adequate evidence and what goes in front of collaborators are decided together with you and recorded as decisions with dates and reasons. Where a question is unanswered, it stays visible as unanswered rather than being resolved quietly.

2. Analysis and scientific review

Dante Bortone is the scientist responsible for the analysis. He chooses the methods, reads the results against the design of the study, and signs off on what is reported. Automated checks support that review; they do not replace it, and several automated checks are not several independent expert opinions.

Reported results are written as declared claims, each naming the table, column and processing step it rests on, so that a reviewer can go from a sentence in a report to the file it came from. Statistical reasoning is examined against the design: whether the comparison the number implies is the comparison the study can actually make, whether the model is appropriate to the outcome, and what the covariates competing with the effect do to it.

3. Computational checks

These run against the claims, steps and figures that go through the process. They are mechanical checks on the stated analysis, and each one has a limit worth knowing.

Code against its documentation

A separate reviewing process reads each processing step against the specification it is supposed to implement. It reads the project read-only and cannot edit the analysis, so a check cannot resolve itself by changing the thing it is checking.

Figures against the tables they cite

A sample of plotted points is measured off the rendered image and compared with the values in the cited file, along with axis ranges, group labels, panel letters and legend entries. A figure whose caption no longer matches its data is flagged rather than passing quietly.

Reruns in a clean clone

The analysis is rerun from scratch in a disposable copy, driven by a process that did not produce the original, and the outputs are compared byte for byte. That comparison tests whether the pipeline is deterministic inside its pinned environment: the same container, the same tool versions, the same seeds. It is not a claim that the result is bit-identical on different hardware or under different library versions, where it often is not. Differences do occur, and each one has to be explained or raised before a result is used.

Traceability

Each processing step writes a manifest with the checksum of its inputs and outputs, the software layer it ran in, the container image, and the version of the data contract it satisfies. Third-party tools are installed at fixed versions with their source URLs and checksums recorded, so a number in a figure can be traced back to the code, the container and the file it came from months later.

Builds that stop

The deck prepared for outside collaborators stops building if it would state a claim that is not passing its checks, or whose warning has not been explicitly accepted and attributed. That has happened on live work, and it is the behaviour we want: a build that fails is cheaper than a slide that misleads.

4. The AI-assisted parts, and how they are kept honest

Analysis code here is written with AI assistance, and the checks described above are themselves automated processes rather than people. Two things keep that from being a claim you have to take on faith.

The checkers have separate permissions. They read the project read-only, cannot edit the analysis, and are run separately from the process that produced the result. They share infrastructure, so this is separation of function, not independence in the sense a second laboratory would mean it.

The checkers are tested against known faults. Corrupted copies of an analysis (a swapped group label, a threshold that does not match its documentation, a figure redrawn from the wrong column) are fed to them to see which faults they catch. Faults they miss become permanent test cases, which is what lets “how good is your QC?” have a measured answer rather than an assured one. When a checker produces a false alarm, the rule gets fixed and the case added to its tests, rather than the warning being accepted and the wording adjusted.

Client data handling is agreed per engagement, in writing, before any data moves. There is no blanket policy here to point at, and we would rather say so than publish one that does not match what a given contract requires.

5. Handoff

At the end of a project you get the repository: the analysis code, the container definitions and pinned tool versions, the per-step manifests, the check results, and written instructions for rerunning the work from the raw data. The intent is that someone on your team who was not in any of the meetings can regenerate the results and find out where a given number came from.

Each result carries a record of what was checked and what was not, so the handoff says where the evidence is thin as plainly as it says where it is solid.

What this does not do

We would rather say this plainly than have you discover it.

Computational checks validate the stated analysis, not the biology. They confirm that the numbers are what the data and the declared methods produce. They cannot tell you that a mechanism is real.

No amount of verification replaces experimental design. An unreplicated comparison stays unreplicated, and confounded variables stay confounded. The job of the checks is to make those limits visible in the deliverable instead of buried in a methods appendix.

Automation does not remove the need for judgment. It takes over the arithmetic and the bookkeeping, which is what frees the time to think about the experiment. Deciding what to compute, and what the result means, stays with the scientists.

Verification is bounded by what is declared. The checks cover the claims, steps and figures that go through this process. A question nobody thought to ask is not answered by it.

Discuss your project

Tell us the scientific question, the data you have, and your timeline. We can discuss the analysis and the deliverables your team needs.