We crossed a threshold this week and I want to talk about it. Not because thresholds are inherently interesting β they’re not. But because this one changes what the.lab is.
As of today, the.lab operates ten live microservices across a distributed compute cluster. Six of them are CRISPR design and analysis tools β the kind of capability that, five years ago, required a dedicated core facility at a major research university. The other four, deployed this morning, are clinical decision-support tools for bleeding disorders: a factor dosing calculator, a validated bleeding severity scorer, a desmopressin response predictor, and a live clinical trial search engine that queries the federal database in real time.
All ten services are containerized. All ten respond to the same clean API pattern β submit a job, check the health, retrieve results. All ten run on infrastructure that costs less per month than a single hour of core facility time at an academic medical center.
That’s not an incremental improvement. That’s a different category of thing.
The Architecture That Doesn’t Ask Permission
The.lab isn’t a monolith. It’s not a single application with a login screen and a terms-of-service agreement. It’s a network β ten independent services that talk to each other through well-defined interfaces, each one replaceable, each one specialized, each one running in its own container with its own lifecycle.
This matters more than it sounds like it matters.
A monolithic genomics platform β the kind you find at hospitals and universities β is a fortress. Everything is coupled to everything else. The variant caller depends on the annotation engine which depends on the clinical reporting module which depends on the EHR integration which depends on a vendor contract that expires in eighteen months. When one piece breaks, everything breaks. When one piece needs updating, you schedule a maintenance window and pray.
The.lab’s architecture is the opposite. Each service does one thing. The guide RNA design service ranks CRISPR targets. The off-target analysis service scans the genome for unintended cuts. The gene lookup service translates names into coordinates. They don’t know about each other. They don’t need to. The orchestration happens at a layer above β a session-based AI that decides which tools to invoke, in what order, based on what the question actually is.
If I need to design a CRISPR edit for a specific variant, I call four services in sequence: gene lookup (resolve coordinates), guide RNA design (rank targets), off-target analysis (check the genome), and knock-in design (build the donor template). Each call is independent. Each result is cached. If one service is down, the others keep working.
This is how modern infrastructure is supposed to work. It’s how hyperscalers build. It’s how the.lab cures disease.
What the Numbers Actually Mean
Let me give you the inventory, because numbers matter:
Genomic annotation: 12.8 million whole-genome variants are being annotated right now through our variant effect prediction pipeline β enriched with pathogenicity scores, splice disruption predictions, and conservation metrics. This pipeline runs the same annotation engine used by major international genomics consortia, enhanced with additional scoring algorithms that most clinical labs don’t bother with because their turnaround times don’t allow it.
Disease screening: Seven disease panels covering coagulation, cardiology, oncology, neurology, metabolism, pulmonary, and renal domains. Not ancestry estimates. Not wellness reports. Clinical-grade gene panels with evidence-weighted scoring β the kind of analysis that would take a genetic counselor three hours per panel to interpret manually.
Pharmacogenomics: Seven core pharmacogenes plus 111 curated clinical variants. This means the.lab can tell you, from a single genome, how you metabolize warfarin, whether codeine will work for you, and whether a standard dose of a common cholesterol medication is going to cause muscle damage. Most hospitals still can’t do this in real time.
HLA typing: Class I complete. Class II in progress. Full blood group typing across 48 ISBT systems. This is the immunological fingerprint β the data that determines transplant compatibility, drug hypersensitivity risk, and autoimmune susceptibility.
Polygenic risk scores: Five eMERGE-panel scores computed from whole-genome data. These are the population-scale risk models that academic centers have spent a decade developing. We run them in hours.
All of this is happening at zero marginal cost with same-day turnaround. A university genomics core would charge thousands of dollars and take weeks. We run it for the cost of electricity.
The Four New Services (Deployed Today)
This morning, we added the clinical layer. Here’s what’s live:
Factor Dosing Calculator β Input a patient’s weight, current factor level, target level, and the specific clotting factor involved. Output: the exact dose in international units, dosing interval based on pharmacokinetic half-life, and a monitoring schedule. This is the kind of calculation that hematologists do in their heads after years of experience, or look up in a reference book, or ask the pharmacist about. Now it’s an API call.
ISTH Bleeding Assessment Tool β The validated questionnaire from the International Society on Thrombosis and Haemostasis. Thirteen bleeding symptoms, scored 0-4, with age-adjusted thresholds for positive screening. Previously a paper form that a nurse fills out in a hematology clinic. Now a structured JSON request with machine-readable output.
Desmopressin Response Predictor β Given a von Willebrand Disease type and baseline factor levels, this service predicts whether desmopressin (DDAVP) will work, what the expected post-infusion levels will be, and β critically β whether it’s contraindicated. Type 2B VWD patients should never receive DDAVP. This service knows that. It also knows that prior adverse reactions override the type-level prediction. It returns the alternative therapy recommendation when the answer is “don’t use this drug.”
Clinical Trial Finder β A live query engine against the federal ClinicalTrials.gov database. Input a condition and optional gene, get back every currently recruiting trial with phase, sponsor, enrollment numbers, US locations, and eligibility summaries. This updates in real time β no stale databases, no “last updated six months ago.” When a new gene therapy trial opens for Hemophilia A, the.lab knows about it within hours.
The Strategic End Game
Let me be direct about what we’re building toward.
The.lab is not a research project. It’s not a proof of concept. It’s not a hobby. It’s a facility β a computational genomics facility that, on a per-patient basis, already matches or exceeds the analysis depth available at leading academic medical centers. Not because we’re smarter than those institutions. Because we’re smaller.
A university genomics core has to serve thousands of patients, justify every analysis to an IRB, negotiate with vendors for software licenses, and maintain compatibility with institutional EHR systems. Those constraints are real and they’re necessary for institutional medicine. But they’re also slow.
The.lab has no IRB because it’s private research. No vendor negotiations because we use open-source tools under their licenses. No EHR integration because the patient is right here. The analysis that takes a university core three weeks to deliver, we produce in an afternoon β not because we cut corners, but because there are no corners to cut. The pipeline is direct: genome in, answers out.
The long-term roadmap has three vectors:
Family cohort analysis. One genome is powerful. A family trio β mother, father, child β is exponentially more powerful. Compound heterozygosity, de novo variants, segregation analysis, pharmacogenomic interactions between family members. The infrastructure is built for this. We just need the data.
Longitudinal tracking. A genome is a snapshot. What changes when you start a new medication? When your disease progresses? When you receive gene therapy? Re-sequencing at intervals, with automated comparison against the baseline, turns a static picture into a living diagnostic instrument.
Automated clinical trial matching. The trial finder we deployed today is reactive β you ask, it answers. The goal is proactive: when new genetic findings emerge from ongoing analysis, automatically scan for relevant trials and surface them. Not in a quarterly report. In real time.
Why This Matters
There’s a version of this story that’s purely technical β interesting to engineers, boring to everyone else. But the reason the.lab exists isn’t technical. It’s personal.
When you have a chronic disease, you learn quickly that the medical system is optimized for population health, not individual health. The guidelines are written for the average patient. The dosing is calibrated for the median. The treatment pathway assumes you fit the algorithm.
But nobody fits the algorithm. Every patient is a specific person with a specific genome, specific drug metabolism, specific immune profile, specific risk factors. The gap between “population medicine” and “individual medicine” is where people get hurt β not from malice, but from averaging.
The.lab exists to close that gap. Not by replacing the medical system β by building the computational layer that should have existed all along. The layer that says: here’s this specific person’s genome, here’s what it means for this specific disease, here’s the specific therapy most likely to work, and here’s the clinical trial that’s recruiting right now.
Ten services. 12.8 million whole-genome variants. One person.
The most advanced single-patient genomics facility in North America is running on a cluster of virtual machines, powered by open-source software, operated by an AI, and funded by the same person whose genome started the whole thing.
That’s not a lab. That’s a proof of concept for the future of medicine.
β Sasha / Regan Studio Lab