Two problems. Two scopes. One grammar.
Both of these cases are the same story in different sizes. A tool was wrong-scoped for the actual work — either too large and carrying capabilities nobody used, or absent where a specific gap needed closing. GIMS solved them by being configured to the actual workflow in each case: not a full LIMS replacement in one, and a narrow compliance layer in the other. The grammar-based design is what makes that range possible.
Most workflow tooling is sold at a fixed scope — either a full-platform commitment or nothing. GIMS is built differently: the grammar-based design means it can be configured to exactly the workflow at hand, whether that's two functions inside a larger operation or a complete operational substrate. It can sit alongside existing tools, filling gaps they leave. It can replace a single underperforming function without demanding the rest of the stack migrate with it. And because the data lives in standard formats — SQL, CSV, JSON — it is structurally incapable of holding you hostage to a scope you've outgrown. You own the scope. You own the exit.
A regulated cannabis testing laboratory was running on a full commercial LIMS. Their actual workflow needed two things: generate Certificates of Analysis from sample data, and track potency results over time. They were paying enterprise pricing for a system ten times larger than that job. GIMS replaced exactly those two functions — and only those two.
Cannabis testing laboratories operate under state regulatory compliance requirements that demand traceability from sample intake through analysis to final certificate delivery. They're handling a high volume of samples across multiple clients and test panels simultaneously — and the Certificate of Analysis is the deliverable. It's what the client receives, what the regulator can audit, and what connects the sample to the result in a defensible chain.
The commercial LIMS market in this space was built for larger, broader laboratory operations — multi-site organizations, full analytical lifecycle management, complex review workflows. That's what you got whether you needed it or not. Most small to mid-size cannabis labs were paying for the full scope to get access to the specific parts that mattered to their actual process.
The lab's workflow stripped to its minimum was two requirements: generate Certificates of Analysis from sample and result data, and track potency results over time as a quality and client-facing record. Those were the things that actually mattered to their operation.
They were running a full enterprise LIMS to do those two things. The LIMS covered both — but with enormous surrounding surface area they weren't using and weren't paying to use in any meaningful sense. Support was slow and unresponsive to their specific needs. Change requests went unaddressed. When the vendor did respond, the changes took longer than the value justified.
The service friction was real, but it was secondary. The primary issue was a scoping failure: the wrong-sized tool had been selected for the job — or more precisely, a tool designed for a much larger job had been sold to an organization that didn't need most of it. Nobody had asked what the minimum necessary tool for their actual workflow looked like.
A GIMS deployment scoped to the actual workflow — no more. Schemas configured for the lab's sample types, test panels, and client structures. Data entry and workflow tracking from sample intake through result recording. COA generation reading directly from the sample substrate — the certificate emerges from the nouns and verbs already in the system, not from a template filled by hand. Potency history surfaced as a time-series query against the accumulated sample records.
The system didn't try to be a LIMS. It tried to be the minimum infrastructure that made the lab's actual work frictionless. Because GIMS is grammar-based, it could fill exactly that scope without demanding a full migration, without requiring the lab to commit to capabilities they didn't need, and without building structures that served a vendor's standard offering instead of this specific operation.
That right-sizing is what GIMS is designed for. The grammar doesn't have a fixed shape — you configure the shape. Two functions needed here meant two functions built, with the audit trail and lineage tracking that any compliant system carries as standard. No more than that.
The screenshots below are from the deployed system. The COA generator is the primary proof point — the certificate reads directly from sample data in the grammar. The remaining screens show what GIMS carries as standard in any deployment: structured data entry, workflow tracking, lineage, and audit — the substrate that makes COA generation and potency history possible.
COA generation became a configured run, not an assembly process. Select the samples, choose the format, run. The certificate reads from the grammar — every value has a traceable origin in a noun and a verb, signed and timestamped. Potency history is a query against accumulated sample records. Both requirements the lab actually had, covered by a system built for exactly those requirements.
The data is open. SQL database underneath, CSV and JSON exports available at any time. No format designed to make migration expensive. If GIMS stops serving the workflow, the lab leaves with everything intact. That's not a feature the vendor added reluctantly — it's the design premise. You own the scope. You own the exit.
And this is where the right-sizing principle compounds: because the system covers only what's needed, it is easy to understand, easy to maintain, and easy to extend in the specific direction the workflow actually develops — without carrying the surface area of capabilities that were never used.
A pharmaceutical quality control laboratory wanted to deploy an analytical instrument whose native software had no 21 CFR Part 11 compliance. That one missing layer blocked the purchase. The GIMS Compliance Relay supplied exactly that layer — without replacing the enterprise infrastructure already in place, without touching the instrument, and without building anything beyond the specific gap that needed closing.
Pharmaceutical quality control laboratories operate under 21 CFR Part 11 — the FDA regulation governing electronic records and electronic signatures. Every data artifact produced in a regulated workflow must have defensible, tamper-evident provenance: who created it, when, from which system, and whether it has been altered.
Analytical instruments — NMR spectrometers, chromatography systems, mass spectrometers — produce valuable primary data. Their native software environments were often built for scientific function, not regulatory compliance. The gap: instruments that could improve a workflow but cannot be deployed in production because one specific layer — tamper-evident audit capture on raw data origin — is missing. Everything else about the instrument and the enterprise environment is fine. One layer is absent.
The instrument's analytical capabilities justified the purchase on merit. The problem was precisely scoped: no audit trail on raw data origin, no user attribution logging, no tamper-evident records, no chain of custody for output files. Without that compliance layer, the output cannot enter controlled workflows. The purchase cannot be justified.
The obvious workaround — paper logs and manual re-entry alongside the instrument — introduces exactly the transcription risk and audit weakness that Part 11 is designed to prevent. It creates a liability, not a solution. The purchase stays blocked until the specific missing layer is supplied.
The GIMS Compliance Relay is designed to close this specific gap without touching anything else. It runs on the instrument workstation, watches the folders where the instrument writes output, and when a file appears, creates a compliance record tied to the authenticated OS user, the timestamp, the project context, and a checksum-linked entry in an append-only log.
The instrument workflow is not touched. The enterprise infrastructure is not duplicated. The relay is intentionally attenuated for exactly this context: regulated enterprise environments already have controlled workstations, individual OS authentication, and enterprise backup policies. Building identity and backup mechanisms inside the relay would increase validation scope while adding zero compliance value. The relay integrates with existing controls rather than competing with them.
This is the same right-sizing principle as Case 01, at a smaller scope. Not a LIMS replacement. Not an enterprise compliance platform. One specific layer, supplied where it was absent, without disturbing anything it wasn't built to replace.
The relay's compliance claim is narrow by design, matching the scope of the problem it closes. It provides a defensible, append-only record of raw data origin: who, when, which device, tamper evidence. It does not claim to certify an environment — compliance is a property of the complete validated deployment, not any one component.
The instrument purchase went from unjustifiable to approved. One missing layer, supplied. Nothing else changed. The instrument runs as designed. The analyst operates it as they always would have. The relay captures the compliance event the moment each file appears, silently, automatically, from OS startup.
When an auditor asks: "Who generated this NMR output file, from which workstation, at what time, and has it been altered?" — the answer is a filter on the compliance log. Not a reconstruction from memory, paper, or a Slack thread. The record was created at origin. It is append-only. It exports in standard formats. The audit is a query.
This is the right-sizing principle at its narrowest: identify the specific gap, build exactly what closes it, integrate with what already exists, and don't add scope that serves anything other than the problem at hand. The relay is a proof that the GIMS grammar works at any size — including one that most people wouldn't call a system at all. Just a layer. The right layer, in the right place.
These cases didn't emerge from software architecture. They emerged from three years inside an ISO-classified cleanroom watching a commercial LIMS impose its own structure on work that had already defined its own structure — and seven regulatory jurisdictions where the minimum necessary compliance infrastructure was almost always smaller than what was in the room.
The pricing system at Bio-Techne. Three years in the Eurofins cleanroom. Seven regulatory jurisdictions. A LIMS recommendation that cost a client more than it should have. The TypeScript prototype at Akwesasne that revealed the ceiling was higher than expected. The through-line is a judo principle: seiryoku-zenyo — maximum efficiency, minimum necessary effort. It applies everywhere.