Trust
Roadmap
Near, middle and long term, in that order of confidence. No dates — the stages that gate this work run on growing seasons, and a date would be a guess dressed up as a commitment.
3
horizons
65
organisms today
1,000
constructs today
No
dates promised
01
How this list is ordered
Three horizons, ordered by how confident we are rather than by when work starts. Near term is work already underway where the main risk is execution. Middle term is work we understand and have not begun, where the shape may change once we do. Long term is where the honest statement is that the problem is not solved and we are not certain it is solvable on the terms we would want.
There are no dates. The validation stage runs on growing seasons, and anything downstream of it inherits that clock. A roadmap with dates on it would be a roadmap that is wrong.
02
Near term
Deeper expression coverage
Transcriptomic data is uneven across the 65 hosts, and stage one of the method depends on it. Filling the thin hosts improves promoter selection more reliably than any model change would.
Published benchmark results
The validation apparatus exists and the results are used internally. Publishing them per engine, stratified by tier and host rather than averaged, is work in progress.
Batch ergonomics
Batch mode works and is awkward at the margins — partial reruns, result diffing between batches, better handling of individual failures inside a large sweep.
Broader API surface
Most engines are reachable from the API; coverage and documentation are not yet uniform across all of them, and webhook event types need extending.
03
Middle and long term
More hosts
Sixty-five organisms is a reasonable span and not a complete one. Each addition needs a genome-scale metabolic model, annotation and expression context before it is worth offering — which is why the list grows slowly.
Multi-step design
The platform optimizes an enzyme well and a whole branch less well. Reasoning about several simultaneous edits and their interactions is a harder problem than running the single-edit case repeatedly.
Tighter model-to-measurement loop
HPLC results feed benchmarks today. Feeding them back into host models automatically, so a measurement improves the next prediction for that host, is understood and not yet built.
Quantitative heat prediction
Predicting a rating within a useful interval across the whole ladder, in hosts with no measured history, is not solved. Flux analysis bounds the problem; it does not close it. Sparse regions stay extrapolations.
Profile from sequence
Predicting burn profile — not just total heat — from a construct alone would remove the most expensive remaining feedback loop. The acyl branch is the lever; the mapping from sequence to perceived profile is not characterized well enough.
Pathway transfer without precedent
Transfer into hosts unlike anything in the catalog currently depends on judgement the platform cannot supply. Making that reliable is a research programme, not a feature.
04
What will not change
- Measured vs predicted
- Always visually distinct
- Runs
- Always versioned with pinned engines
- Export formats
- Open standards, no lock-in
- CPU engines
- Free
- GPU engines
- Prepaid credits, $25 → 250
- Credit unit
- ~1 Standard job
- Tool stack
- Open-source throughout
Some commitments are structural rather than scheduled. Predicted values will not start being presented as measurements. Runs will keep their pinned engine versions, so a result does not shift underneath a paper. Exports will stay in open formats — GenBank, FASTA, SBOL, ST.26 — because a design you cannot take elsewhere is a design you do not fully own.
The pricing shape holds too: CPU engines free, GPU engines on prepaid credits with Standard, Performance and Max classes, and enterprise workspaces adding API keys, webhooks, reserved capacity and SSO. If anything here changes, it will be said plainly on this page rather than discovered in an invoice.
Ready to run it
Try this in the Splice Platform.
CPU engines are free to run. GPU engines run on prepaid credits.
Related