Skip to content
← BLUEHEALTHCARE
blueBench

blueBench

Experiment preflight gate

Checks a frozen lab run manifest and its intended conclusion against deterministic license rules before the experiment ships, and signs a LICENSED / QUESTIONABLE / REFUSED / CANNOT-CERTIFY packet with the smallest evidence set needed to clear each open hold.

Module — in active build
Request a pilot conversation Read the manual
Runs locally · CLI or web UI · Ed25519-signed receipts · no cloud account required
Who it's for

Lab and research-integrity reviewers.

What it is not

No instrument control, no LIMS write access, no biological truth claim, and no prediction of an experimental outcome. blueBench licenses recorded input capability; it does not predict the experiment's result or establish scientific truth.

Screens

blueBench runs before the experiment: a frozen lab run manifest, plus the conclusion the lab intends to draw from it, checked against license rules while the samples are still on the shelf. The four screens below start at intake, follow the bundled synthetic run-0318 twice through the library — once against a manifest carrying a stale authentication record and a missing control, once against the corrected manifest — and end at the signed receipt.

blueBench Prepare an experiment preflight screen, step 1 of 4 (Sources): a Sample data tab with an Add sample bundle button, three added files — sample-run-manifest.json, sample-conclusion-spec.yaml, sample-license-rules.yaml — each marked Ready, an Intake check panel reading required source types Complete and readable content Ready, a note that source content never leaves the machine, and a Continue to field mapping button.
Synthetic demo data
Every run starts here. The bundled sample supplies a run manifest, a conclusion spec, and a set of license rules in one step; the intake check on the right confirms all three parsed before field mapping begins. Nothing is evaluated yet.

Map fields and Configure follow; completed preflights land in the library.

blueBench Experiment preflight library screen: the suite shell's sidebar (Case intake with Library and New analysis, Evidence map, Reviewer, Case file) beside a table of two preflights of the same synthetic run, run-0318, one marked REFUSED and one marked LICENSED, above two starting cards, Start from files and Try a sample preflight, with a footer stating that blueBench licenses recorded input capability and does not predict the experiment's result.
Synthetic demo data
The same run, twice. The bundled demo preflights run-0318 against a manifest with one stale authentication record and one missing control — REFUSED with two typed holds — then against the corrected manifest — LICENSED. The first receipt is kept untouched; the second is linked to it, not written over it.

Open the LICENSED row.

blueBench Run license preflight screen for run-0318: a LICENSED badge, five count cards — 5 conditions, 4 satisfied, 0 failed, 0 unverifiable, manifest completeness 100% — a two-step strip reading PREPARED, manifest frozen, then RELEASE, recorded inputs support this conclusion, a Try a different conclusion panel with an Upload a conclusion-spec button, a Result readiness panel naming the engine version, and a claim-boundary box stating that blueBench licenses recorded input capability and does not predict the experiment's result or establish scientific truth.
Synthetic demo data
Run license preflight — a morphology conclusion checked against specimen, reagent, control, protocol and instrument evidence: four conditions satisfied from recorded sources, none failed, none unverifiable, and no holds. Unverifiable is its own count because a condition that could not be checked is never treated as a pass. The panel at the bottom makes the product's point: blueBench licenses a claim, not the specimen — the same manifest can license one conclusion and refuse another.

A REFUSED run shows the same screen with the failed conditions listed as typed holds and the smallest evidence set that would clear each one. Receipt closes out a LICENSED run.

blueBench Signed process receipt screen for the run-0318 morphology preflight, showing a LICENSED badge, a synthetic-data notice, the standalone verify_receipt.py script named as the same check the page runs, a receipt envelope listing product, schema, run id, run verdict, contract hash, payload hash, output hash, nonce, parent receipt and signer public key, and a Verify now panel with a Verify offline button.
Synthetic demo data
Signed process receipt — the LICENSED verdict, the manifest's contract and payload hashes, and the signer's public key, all in one envelope. Parent receipt reads none, this is the first run: a corrected re-run links forward from here rather than overwriting it. Verify now runs the same check the standalone verify_receipt.py performs with the application stopped entirely.
Status, measured

Under active build. CLI, API, and web UI exist; see the status page for the measured current state.

A signed receipt proves what blueBench ran and recorded; it does not prove an underlying real-world claim is true. blueBench does not approve, deny, recommend, pay, retract, or alter anything a named human is responsible for deciding.