Workflow
Validate a design
The checks that are cheap in software and expensive everywhere else. Validation runs the whole design — sequences, guides, model, parts, documentation — and reports what it found rather than quietly fixing it.
5
check groups
Full
off-target sweep
Versioned
report
CPU
engine class
01
The goal
Most design errors are boring. A part whose orientation flipped during an edit, a primer whose binding site no longer exists, a model assumption that stopped matching the construct three revisions ago, a guide that looked fine before the host genome was updated. None of them are interesting, and all of them are costly once material has been ordered.
Validation is the deliberate pass that goes looking for them. It is not a gate that silently blocks you — it produces a report, with severities, and leaves the judgement where it belongs.
02
What gets checked
Sequence integrity
Reading frames, start and stop codons, internal stops, junction continuity, and whether the annotation still describes the sequence it is attached to. Cheap checks that catch expensive mistakes.
Off-target evidence
Every guide in the design is swept against the host genome with Cas-OFFinder and scored in the CHOPCHOP and CRISPOR tradition. Guides whose off-target picture has changed since they were chosen are flagged explicitly.
Model consistency
The flux model is re-run against the current construct rather than the one that existed when the target was set. Drift between what was modelled and what was built is reported as a difference, not absorbed.
Part provenance
Each part is checked for a recorded source — catalog entry, Addgene deposit, or an explicit in-project origin. Parts with no provenance are listed, because an undocumented part is a problem that surfaces later.
Documentation audit
Targets without rationale, variants without scores, guides without sweeps, exports without manifests. The audit checks that the design can be explained, not just executed.
Project rules
Workspaces can add their own rules — required annotations, forbidden parts, host restrictions, review requirements — and validation enforces them consistently across every project in the workspace.
03
Worked example
- Project
- SS-0905 — Tier 3 tobacco line
- Construct version
- v7
- Sequence checks
- Pass
- Off-target sweep
- 2 guides flagged, 1 re-designed
- Model consistency
- Warning — target set against v4
- Part provenance
- 1 part missing a source
- Verdict
- Resolve 2, proceed
A representative result: nothing catastrophic, four things worth an hour. The model-consistency warning was the useful one — the heat target had been set three construct versions earlier and nobody had re-run the model since. It still held, but confirming that is different from assuming it.
The flagged guides came from a host genome assembly that had been updated after the guides were designed. One tolerated the change; one did not and was replaced. This is exactly the class of problem that validation exists to surface, because nothing about the design itself had changed.
04
What you get
A dated report tied to a specific construct version, with findings grouped by severity and each one linked to the object that caused it. Reports accumulate, so the history of a design includes the history of what was checked and when.
Validation runs on CPU engines and is free. It is attached to export by default — a package assembled for a lab carries its validation report with it, so the receiving end can see what was checked rather than taking it on faith.
Ready to run it
Try this in the Splice Platform.
CPU engines are free to run. GPU engines run on prepaid credits.
Related