Workflow
Reproduce a result
Every run is stored with the inputs, parameters and engine versions that produced it. Re-run it as it was, or fork it and change one variable — the difference between those two is the whole point.
Every
run versioned
Pinned
engine versions
Fork
to vary one input
Shareable
run links
01
The goal
The question “how did we get this number?” should have an answer that takes seconds, not an afternoon of reconstructing someone’s session from memory and a screenshot. Computational design generates results faster than most teams can document them, and the gap is where trust in the output quietly erodes.
The platform closes that gap by making the run, rather than the result, the thing it stores. A number without its run is an orphan; the interface does not really let you produce one.
02
How it works
Everything is a run
Flux solutions, variant scans, folds, guide sweeps, codon adaptations, assemblies, exports. Each one is stored as an object with its inputs attached, not as a value written into a project.
Versions are pinned
A run records the engine version and model weights that produced it. When an engine is updated, old runs keep pointing at what actually ran, so results do not silently change underneath you.
Re-run unchanged
Open any run and execute it again against its stored inputs and pinned versions. Identical outputs confirm reproducibility; differences are reported with the reason, which is itself informative.
Fork to vary
Forking copies the run, lets you change exactly what you intend to change, and records the parent. The lineage of a design becomes a readable tree rather than a folder of near-identical files.
Share the run, not a screenshot
A run link gives a collaborator the inputs, the parameters, the versions and the output together. Reviewing becomes possible without a call to explain what the picture meant.
Cite it
Runs carry stable identifiers, so a methods section or an internal report can point at the exact computation rather than describing it approximately.
03
Worked example
- Original run
- Flux solution, SS-0733, March
- Stored inputs
- Host model, media, target, construct v4
- Pinned engine
- COBRApy flux engine, versioned
- Re-run
- Identical solution
- Fork
- Same inputs, construct v7
- Difference
- Amine-branch ceiling raised
- Lineage
- Both runs linked, parent recorded
Re-running the March solution confirmed it was still the solution — useful on its own when a result is about to be quoted in a report. The fork is where the work happened: one input changed, everything else held, and the difference in output attributable to that change rather than to drift in six other things.
That is the discipline the structure encourages. When varying one thing is easier than varying several, people vary one thing, and the resulting record is interpretable months later.
04
What you get
A project whose history is legible: every result reachable from the run that produced it, every run reachable from the project, and every fork showing what it changed. Reviews stop being archaeology and audits stop being a special event.
Storing and re-opening runs costs nothing. Re-executing a CPU run is free; re-executing a GPU run spends credits as the original did — $25 for 250 credits, one credit for roughly one Standard job — because it is genuinely running again.
Ready to run it
Try this in the Splice Platform.
CPU engines are free to run. GPU engines run on prepaid credits.
Related