R&D systems
A sequence is more than an experiment
DNA designs, lab notes, and analysis can drift apart. We need a practical framework for building a traceable molecular biology workflow.
Imagine you inherit a construct called pAAV_final_v7.gb
The file opens perfectly. The bases are there. The annotations are tidy. The map looks finished.
What it cannot tell you is why this promoter won over the other two, whether the unusual junction was intentional, which primer pair produced the clean colony, why the first transfection was excluded, or where the script lives that turned the plate-reader export into the figure in last quarter’s deck.
The sequence survived. The experiment did not.
That is not a failure of GenBank, SnapGene, or any other sequence format. A sequence file is exceptionally good at representing a sequence. The failure comes when we ask a sequence file, or a folder full of files, to become the memory of an experiment.
The experiment is larger than its design
A construct is often the most concrete artifact at the start of a molecular biology workflow. It is tempting to treat it as the center of the record. But the sequence is only one layer of the experiment.
To understand what happened, a future teammate needs at least five kinds of context:
| Layer | The question it answers | Where it often hides |
|---|---|---|
| Intent | What were we trying to learn? | A meeting, slide, or message thread |
| Design | Why this sequence and not another? | A person’s memory or an old file version |
| Execution | What actually happened at the bench? | A paper notebook, ELN, or phone photo |
| Evidence | Which raw data and analysis support the result? | Instrument exports, scripts, and spreadsheets |
| Decision | What did we conclude, and what changed next? | A presentation or the next experiment itself |
Lose any one of these and the project becomes harder to review. Lose the links between them and the team has to reconstruct the experiment from timestamps, filenames, and memory.
This is the context gap: the distance between a scientific decision and the record needed to understand it later.
Every handoff drops a relationship
The typical workflow is a chain of capable tools.
The design moves from a sequence editor to an order. The order becomes tubes and samples. The protocol lives in a notebook. The instrument produces an export. The export moves into Python, R, or a spreadsheet. The conclusion lands in a deck. Then the next design begins.
At each handoff, the artifact usually survives. The relationship often does not.
The CSV is preserved, but not the sample map used that morning. The protocol is preserved, but not the deviation that rescued the run. The plasmid is preserved, but not the rejected alternatives. The figure is preserved, but not the analysis parameters that made it.
Good research-data practice has long emphasized that data needs rich metadata and provenance to remain reusable. The FAIR Guiding Principles made this explicit for scientific data. The National Academies’ report on reproducibility and replicability also treats transparent methods, data, and analysis as part of credible scientific work.
But a lab cannot solve this with a policy document. The record has to be captured close enough to the work that maintaining it is easier than losing it.
A useful experimental record is not exhaustive. It is connected.
Five links worth preserving
You do not need a perfect ontology to close the context gap. Start by preserving five links.
1. The question → the design choice
Record the reason a design exists. “Added a second NLS because localization was weak in the previous construct” is more valuable than “v7.” The sentence does not need to be long. It needs to be attached to the change.
2. The design choice → the exact sequence version
The construct that was discussed, the construct that was ordered, and the construct that was tested should be distinguishable. Stable versions matter more than elaborate naming conventions.
3. The sequence → the protocol and sample
Connect the digital design to its physical execution. Which sample came from which construct? Which protocol version was used? What changed on the day? This is where a project record stops being a design archive and starts representing an experiment.
4. The raw data → the analysis method
Keep the source file, transformations, parameters, and output together. A final chart without its path from raw data is an illustration, not a reusable analysis.
5. The result → the next decision
Close the loop. Write down what the team believes now and what it will do differently. Negative and ambiguous results belong here too. They often carry more design value than the clean success that makes the slide.
A minimum viable project memory
Most teams can improve traceability before changing software. Try this lightweight standard on the next experiment:
- Give the project one canonical home.
- State the question in two sentences or fewer.
- Attach design decisions to exact sequence versions.
- Record deviations when they happen, not at the end of the week.
- Keep raw data beside the code, formula, or parameters used to transform it.
- End each run with a short outcome note: what happened, what we think it means, what happens next.
The test is simple. A teammate who did not run the experiment should be able to answer the next important question without scheduling an oral-history session.
There is a useful restraint here: do not capture everything.
Teams abandon documentation systems that ask them to become archivists. Preserve the context that changes interpretation or action: rationale, identity, deviation, evidence, and decision. A hundred automatically collected events are less useful than one clear sentence explaining why the team changed direction.
AI makes the context gap impossible to ignore
An AI assistant can draft a protocol or suggest a sequence edit in seconds. Whether that suggestion is useful depends on the context it can see.
If the sequence is in one tool, the failed assay is in a slide, and the constraint is buried in a notebook, the assistant has two options: ask the scientist to restate the project or make a fluent guess. Neither is the transformation labs are looking for.
When the project is connected, AI can behave differently. It can reason over the current sequence and the notebook entry that explains its purpose. It can run a tool, expose the result, and present a proposed change for review. It can help structure a bench photo without pretending that OCR is scientific judgment.
Grounded does not mean infallible. It means the suggestion has a visible basis, and the researcher has something concrete to inspect.
The project, not the file, should be the source of truth
This idea shapes how we are building Plasmo.
A Plasmo project can hold the sequence design, scientific notebook, files, images, spreadsheets, Python analysis, collaborators, and AI conversation in one working context. Proposed sequence changes are reviewable. Accepted work has history. Notes can point back to designs instead of describing them from memory.
We are not trying to make the sequence file less important. We are giving it the experimental context it has always been missing.
The distinction matters. Better file organization helps you retrieve artifacts. Better project memory helps you understand decisions. The first saves search time. The second changes what a team can learn.
Make the next experiment easier to inherit
Scientific work is full of legitimate uncertainty. A complete record will not make a noisy assay clean or turn a weak hypothesis into a strong one. It will do something more practical: let the next person see what was known, what was done, and why the team chose its next move.
That person might be a collaborator next week, a new hire next year, or you after six months on another project.
The next time they open final_v7 the right question is not “where are the other files?” It is “what did we learn?”
The answer should be a link instead of an archaeological dig.