Variant Control Bench

Close

What this bench does

You are about to pay for DNA synthesis. Before the order goes out, something independent should prove the fragments actually carry the variants you asked for — and say so in a form a reviewer can audit. That is all this does, and it refuses to claim more.

The path across the bench, left to right

1. Choose the lociFive real cancer variants ship with the page. Click a row’s checkbox to include or drop it; click its name to focus it — the helix, the alignment and the protein all follow the focused locus.
2. ComposeThe composer applies each edit to the real GRCh38 window and lays one labelled fragment tile on the left pad. Nothing is verified yet.
3. Cross the barrierOnly the exported bases cross. The request, the model identity and the composer’s log stop at the wall. In code that is literal: the verify function is handed a FASTA string and a reference window, and has no parameter through which the request could reach it.
4. Re-deriveOn the right pad the fragment is placed against the reference track by shared k-mers, the edits are called out of the alignment, and indels are left-aligned before anything is compared. Risers mark every position the verifier called.
5. Read the verdictReleased only when every requested edit is recovered and nothing unrequested appears. Otherwise held, with the discrepancy named.

Assembling a construct

The Assemble tab treats a construct as what it is: an ordered set of parts — enzyme adapter, homology arm, payload, arm, adapter — joined in that order. Two ways an order fails live only here. An enzyme site that lands inside the insert makes the enzyme cut the construct in half, so a perfectly correct sequence still cannot be built. And because parts join by matching 4 nt overhangs, two constructs sharing an overhang can ligate to each other — every fragment individually correct, the pool misassembled. Neither is a sequence error; both sink the experiment.

Checking a real delivery

The Check a delivery tab is the job this is actually for. Seal the order into a manifest, then months later paste in whatever the vendor sent back. The manifest is hashed, so the result names which order it checked against, and editing it breaks the seal on purpose. It is also where an order declares edits it wants on purpose — the silent PAM-blocking substitutions an HDR template carries — so they read as intended rather than as defects. Declaring them in the sealed order means that decision was made before the delivery arrived, not after seeing a red row.

Try to break it

Two ways. Pick a seeded defect to have the composer sabotage its own export in a named way — six must be caught, two are controls that must not be flagged, because a checker that holds on everything is worthless. Or open Edit the export, change the bases by hand, and re-verify. Nothing is scripted: the verdict is computed from whatever bases are in that box.

Or let it grind

Start campaign runs the same check thousands of times against randomly mutated exports. Each cell on the left pad is one verified attempt, green where the verdict was the one the mutation required and red where it was not. A corruption that gets released is a false pass; a presentation-only change that gets blocked is a false hold. Both are bugs in the checker, and any failure replays from its seed.

A campaign that only ever reports zero proves nothing, so two deliberately broken builds are selectable. Pre-fix normalizer is the real bug this campaign found — roughly one false pass in twenty thousand attempts, which is why it survived to ship. Header-trusting placement matches fragments by the name the composer wrote on them instead of by sequence; it fails about one attempt in eight, every one of them a renamed header. Watch either get caught, then switch back.

Reading the scene