DARNTECH
GBGreg · the on-prem knowledge layer for life-science work
Aug 2025 → May 2026 · v3
362 commits · 10 real lab projects ingested
darn-tech.com · darrenarney.com
What it does for the room · why it's the engine · what we built to get here

We want to make every company in the room better at the thing it already does.

GBGreg is an on-prem AI layer that sits on top of a company's own body of work — its protocols, its data, its code — and turns it into grounded, cited answers and validated, generated artifacts. It runs air-gapped on a sub-$2K box, so the data never leaves the building. Built and battle-tested in the hardest vertical there is — regulated, GxP lab automation. The same engine is built to drop into any lab, CRO, or device company sitting on knowledge it can't put in the cloud.

Capability map · click a node to read the story BUILT READY NEXT · g8
local model stack 35-stage RAG pattern detection schema authority code generation knowledge graph the cut · 45K→635 cross-project intel benchmark scoring FAT/SAT remediation multi-tenant isolation air-gapped deploy equipment-safety checks citations to source recomposable stack runs on itself 2nd product shipped your data stays put channel-deployable ship-empty appliance on-prem regulated CRO / pharma pilot SBIR · health track IU Health lab instrument-vendor channel
The cohort thesis

We don't just want to join the cohort. We want to help it.

Every life-science company in a cohort like this shares three things: a dense proprietary corpus it has built at great cost, a hard constraint against cloud AI (NIH-funded IP, composition-of-matter secrets, client-confidential CRO data, clinical PHI), and a regulatory deadline where auditable and cited beats fast and plausible. That is precisely the seam GBGreg was built for. Below are the recurring shapes — each one a cohort-mate we'd want to work with as a design partner, and some as a channel.

Toxicity / predictive-modeling SaaS
corpus · 1M+ historical analyses, dose-response models, NAM-aligned regulatory docs
Ask their own analyses — "show me runs like compound X" — and generate FDA NAM-aligned submission text grounded in real model output, cited, on-prem. They already sell to pharma who can't cloud their data — which could make them a channel, not just a customer.
Stem-cell / preclinical CRO
corpus · assay protocols, SOPs, study reports across many clients
Onboard scientists and answer "how did we run that assay for client Y" with citations. Cross-project intelligence across client studies without leaking detail between clients — a feature GBGreg already ships, and a CRO's home turf.
Drug-discovery / IND-stage therapeutics
corpus · SAR on a proprietary scaffold, in vivo studies, IND-enabling docs
Retrieve "which derivatives showed efficacy at dose X" and draft IND sections from real study data, cited to source. On-prem is existential — the entire company is a composition-of-matter secret that can never touch a cloud LLM.
Bioprinting / device + instrument control
corpus · fabrication recipes, validation runs, an instrument-control codebase
Generate and validate manufacturing / instrument control code and process documentation from their own validated runs. The near-exact technical twin of what GBGreg already does in lab automation.
362
commits · Aug ’25 → today
10
real lab projects ingested
6,000+
instrument steps mapped
635
validated patterns · post-cut
Why believe we can do that for your company? Because we built it the hard way first. The four acts below are the proof — how the engine got made, and why the same engine drops into any life-science company sitting on knowledge it can't put in the cloud.
Act I · foundation
Aug – Oct 2025 · 87 commits

Pick the hard scope on purpose. Stand up the stack to support it.

In lab automation, software that generates instrument-control code by following rules is the easy 80%. The valuable part is the apps-scientist judgment — knowing which rule to bend, and when, so a method runs on real hardware without wrecking a $300K instrument or a week of samples. The first decision, the hardest one to walk back: build a judgment layer, not a faster code generator. A generator that only follows rules produces output nobody trusts without an expert checking it. That moves the bottleneck, it does not remove it.

Two more decisions followed quickly. The models would run on local hardware, never rented from the cloud — because the labs that need this most (pharma, biotech, and CROs under GxP and 21 CFR Part 11) legally cannot send their automation IP to a cloud LLM. And rather than answering from memory, every question would first pull relevant real examples from a curated project library and reason from that evidence. Retrieval, not chat. By October the first hybrid retrieval pipeline was in the tree — vector search, reranking, and grounded generation, end to end. 4f91c2f · RAG Foundation

Act II · learning to be honest
Oct 2025 – Mar 2026 · 168 commits

Patterns, consolidation, and the cut.

The next four months were about discipline. Pattern detection found the recurring shapes inside real automation work — and immediately exposed how much of that detection was wishful. A schema-consolidation push enforced one source of truth per kind of data, retired a parallel-worktree development method that had outgrown its usefulness, and broke oversized files apart so they could be reasoned about by humans and retrieval alike. By February, generation had moved from describing automation code to producing it, scored honestly against the same benchmark a human reviewer would use, and a knowledge graph let retrieval connect work across separate client projects without leaking project-specific detail between them. c84dc49 · Neo4j cross-project

The defining moment of that work was a subtraction, not an addition. Pattern detection had logged 45,219 recurring shapes. Almost all of them were noise — coincidences the detector mistook for meaningful structure. A retrieval system fed mostly noise returns answers that are confident and wrong. Tightening the detectors, adding a confidence floor and per-file de-duplication, re-extracting from scratch:

98.6% noise. Retrieval quality went up on the same benchmark. The valuable part of an expert corpus is not how big it is — it is what is in it. 05dc41a · 45K→635

Act III · what runs today
Apr – May 2026 · ongoing

Wired for the room the cloud vendors can't enter.

What runs today: a single working system that ingests real lab-automation project archives, answers questions about them with citations back to working instrument code, generates validated automation, and runs the entire stack — models, retrieval, knowledge graph — offline on a sub-$2,000 server. No internet. No per-query meter. No data leaving the building. That last property is not a feature; it is the entire market. Pharma QC, biotech, and CRO labs under 21 CFR Part 11, GxP, and data-residency rules are structurally barred from cloud-only AI. GBGreg is built to live inside that wall.

Which forces a discipline most AI vendors skip: we never hold the customer's data. The product is built to ship empty — every core intact (35-stage retrieval, pattern intelligence, validated code-gen, the knowledge graph, acceptance-test remediation) and zero pre-loaded client IP. The customer deploys it on their own hardware and fills it with their own corpus. DArnTech is a software vendor and an integration partner — never a data processor. That posture is what a regulated lab's legal team needs to hear, and it is the same sentence as the sales pitch: your data never leaves your building, and it never touches ours.

The model is already proven once outside the lab — a second product, the same substrate repackaged for a channel partner's customer, recognized first revenue April 30. That proves the stack is recomposable and channel-deployable: it can be handed to a partner and stood up for their customer. Three things are wired and waiting for the right introduction — a ship-empty appliance any regulated lab can self-host, a lab-vertical ICP built from real project depth, and an on-prem footprint the cloud market cannot match. None of those is technology risk. Each is a warm-introduction risk.

Act IV · what the network opens
June – August 2026 · the next window

The next nodes are introduction-shaped — exactly what an accelerator opens.

Everything above is built or wired. What's left is not technology risk — it's the right conversations, and they are precisely the conversations a life-science accelerator network exists to open. Four doors. A CRO or pharma lab willing to run a first on-prem pilot on its own automation codebase. An introduction into IU Health's own labs as a reference deployment. An SBIR/STTR Phase I on the health track (NIH/NSF), where validated, auditable, on-prem AI for regulated environments is squarely in scope — and where this cohort's own curriculum already points. And an instrument-vendor channel — Hamilton, Tecan, Beckman and beyond — where GBGreg becomes the AI layer a hardware vendor ships alongside the box.

The ask is narrow and warm-introduction shaped: connect us to one regulated lab with an automation codebase it can't put in the cloud, and one channel partner who already sells into those labs. Every company in a cohort like this could be a design partner — and the two that sell into pharma themselves could be distribution. The playbook has run once. With the right ICP filter, it can run again.

Built · ten months · one specialist · 362 commits · 10 ingested lab projects · 6,000+ instrument steps · 45,219 patterns cut to 635 · runs air-gapped on a sub-$2K server, your data never leaves the building · first revenue recognized. Ready · ship-empty appliance · lab-vertical ICP · on-prem-fit. Next · the four warm conversations on the right — and every company in the room we want to help.