Software-controlled, not software-locked: why the wording matters for protocol fidelity
Why "software-controlled" (not "software-locked") is the accurate description of Singulator protocol fidelity — and what that distinction means for core facilities and S10 grant reproducibility.
- "Software-controlled" and "software-locked" are not synonyms — one describes reproducibility, the other implies a vendor-imposed ceiling. The architecture is the same; only the accurate word survives scrutiny.
- The protocol lives in software, not in operator technique — a senior tech and a first-week trainee produce the same nuclei because neither one is making protocol decisions in the moment.
- The protocol library evolves; it isn't frozen at purchase — new validated tissue types and optimizations ship to existing instruments on a normal release cadence. Closer to a smartphone OS than fixed firmware.
- For core facilities and S10 grants, that's the reproducibility argument — the capital investment gets more capable over its life instead of depreciating into rigidity.
A few months ago, in a sales conversation with a single-cell core director, a senior PCS product manager caught herself describing the Singulator as "software-locked." The director's body language shifted. The conversation cooled.
When she asked him about it later, he was direct:
"Software-locked sounds like I can't optimize it. Like I'm stuck with whatever decisions you made when you built the cartridge. If a tissue type doesn't work, am I just out of luck?"
One word changed the value the director thought he was being sold. "Locked" implied rigidity. "Locked" implied loss of control. "Locked" implied that the institutional capability — the thing the core was buying for a multi-year lifecycle — would be capped by the vendor's release decisions.
The product manager went back and changed every instance of "software-locked" to "software-controlled" in the next sales deck. The next conversations went differently.
That difference is worth a few minutes of attention if you're a core director, an S10 grant writer, or anyone evaluating a multi-year capital purchase.
What "software-controlled protocols" means at the architecture level
The Singulator Platform runs nuclei-isolation protocols defined in software and executed by a single-use cartridge. The protocol — exactly which mechanical forces, exactly which timings, exactly which fluidic transitions — is specified by the instrument and the consumable, not by the operator's technique or judgment.
That's the part that makes the prep reproducible across operators. A senior tech and a first-week trainee produce the same nuclei because neither one of them is making protocol decisions in the moment. The protocol is in the software.
The protocol isn't locked. It evolves. New tissue types get validated. New protocol options get released. Optimizations get pushed to existing instruments. The library of available protocols grows over time — and any installed Singulator runs the latest validated protocol for any tissue type the platform supports, the moment that protocol is released.
The right mental model is closer to a smartphone OS than a fixed-firmware appliance. The instrument is the same; the software-defined behavior gets better.
Why this matters for core facilities and S10 grants
For a single-cell core that supports many PIs across many tissue types, the question isn't "does this instrument work for the workflow we have today" — it's "will it still work for the workflow we have in two years, when a new PI walks in with a tissue type we've never processed."
A truly locked instrument is a multi-year bet on what the vendor decided to support at the time you signed the purchase order. That's a reasonable risk if the vendor's roadmap aligns with where your science is going. It's not a great risk if the science moves and the instrument doesn't.
A software-controlled platform doesn't make that bet the same way. New tissue types are protocol additions, not hardware additions. If a PI brings a tissue type you haven't seen, you check whether a validated protocol exists for it. If one does, you run it. If one doesn't, you ask the vendor when one will be released — and the answer is usually "soon" because protocol expansion is a normal release cadence, not a major-version hardware refresh.
For an S10 grant proposal, that's the reproducibility argument the review committee responds to. The capital investment isn't depreciating into rigidity. It's a platform that gets more capable over its life.
What this looks like in practice
Today, the Singulator Platform supports protocols across 80+ validated tissue types — fresh, frozen, OCT, and FFPE. That number wasn't where it started. Each tissue type is a validated protocol release; new types get added as the validation work completes.
When you buy a Singulator today, you're buying access to today's tissue-type library AND every future protocol release that runs on the same hardware. The S200+ shipping today will run protocols that don't exist yet a year from now.
That's not the same thing as "locked."
A small wording change with practical consequences
Core directors and S10 reviewers read instrument descriptions the way scientists read methods sections — looking for the constraints that aren't being disclosed. "Locked" reads as a constraint. It reads as a vendor-imposed ceiling on a multi-year capital purchase.
"Software-controlled" reads as what the architecture actually delivers: protocol consistency and reproducibility across operators, without surrendering the ability to optimize or expand the tissue-type library over the instrument's lifetime.
The phrasing has been updated everywhere in customer-facing PCS materials. The architecture didn't change. The description now matches what the platform actually does — and what a core director is actually buying.
Evaluating for your core?
20 minutes with a PCS application scientist on your intake profile — your hardest tissue types, the FFPE submissions you're currently turning away, and where the Singulator fits your S10 grant cycle.
