There is a question I have been asking, in one form or another, since the first job out of college. It predates the software. It predates the consulting practice. It is a judo principle: seiryoku-zenyo — maximum efficiency, minimum necessary effort. Not efficiency as speed, not minimalism as aesthetics, but a precise and somewhat relentless interrogation of what work simply must be done to achieve a goal, and what work exists only because nobody has yet asked whether it needs to exist at all. Every domain I have entered has had an answer to that question that surprised me. The answer has always been the same shape: less than you think, if you look at it honestly.
The first one was almost comically small. A pricing system at a life sciences company — OEM antibody data, vendor spreadsheets, a reconciliation process that took several hours and required a specific person to perform in a specific order or the whole thing would quietly produce wrong numbers. The person who maintained it had developed a fluency with its idiosyncrasies that had become, over time, indistinguishable from expertise. He was not wrong about the system. He had simply learned to be very good at a bad thing.
I fixed it with VBA in a fraction of the time it had taken anyone to explain the problem to me. The multi-hour process became twenty minutes. What struck me was not the technical simplicity of the fix — it was that nobody had asked why the system existed in that form in the first place. The answer, it turned out, was that nobody had had to. The person maintained it. The system persisted. The question never needed to be asked.
The question I was asking without yet having a name for it was: what work here simply must be done? The reconciliation process, stripped of its accumulated ritual, was twenty minutes of actual work wearing several hours of inherited habit. The person who maintained it was not the problem. He was the symptom of a system nobody had examined. The moment you examine it — the moment you ask what is strictly necessary — the answer is usually embarrassingly smaller than what currently exists.
The ISO 14644-classified cleanroom is a controlled environment in the most literal sense. What enters is accounted for. What leaves is accounted for. Every surface, every contact, every action is documented. The work I performed there — clinical transplant sterility testing, life-critical microbiological compliance — demanded a quality of attention that I have not since found in any other environment. The margin for error is a concept that does not apply. There is no margin.
And then there was the LIMS.
A Laboratory Information Management System is the software layer through which laboratory work is recorded, tracked, and reported. In principle, it should be the thing that makes the documentation requirement frictionless — the system that gets out of the way so the scientist can do the science. In practice, three years as a daily end user taught me that every commercial LIMS is built by people who have never sat inside one. The interfaces are designed for data entry rather than for how data is actually generated. The workflows encode assumptions about laboratory procedure that are wrong in ways that accumulate slowly and grind constantly.
The cleanroom itself is an expression of seiryoku-zenyo in its strictest form. Every action accounted for. No wasted movement. No ambiguity about what must be done because the consequence of unnecessary variation is contamination and a failed test on a transplant sample. The LIMS existed alongside that discipline and was its opposite: a system that imposed work serving its own structure rather than the outcome the work was meant to produce. By the end of three years I knew precisely which parts of my daily workflow were irreducible and which existed because a vendor had made a design decision for reasons that had nothing to do with me. That distinction became the basis of everything that followed.
It is worth being precise about what cannabis testing laboratories are actually doing. They are not doing science in the hypothesis-testing sense. There is no theory under examination, no experiment designed to reveal something previously unknown. The sample arrives. The question is whether it passes. The work is careful observation under regulatory scrutiny, and the output is a defensible record that the observation occurred correctly. The science is not the frontier. Knowing what the regulations actually require — and why — is the frontier.
I founded Equilibrium Scientific in 2022 to work at that frontier. The clients were labs trying to get through a regulatory gate, or trying to open a new business and needing to demonstrate they could get through one. The gap I was closing was not usually technological. It was understanding: what does this accreditation body actually need to see, what does "defensible" mean in this jurisdiction, what will the auditor actually ask. I was often the scientific knowledge in the room as much as the systems knowledge. The tech was frequently fine. The problem was the person using it not knowing what they were trying to prove.
The jurisdictions were not all the same story. The Caribbean engagements worked — the people there knew what they needed and what they had could deliver it. The Akwesasne situation was its own thing. The Mohawk Nation is a sovereign territory, which means certain regulatory requirements that apply to state-licensed operations simply do not apply there. Someone had sold them enterprise compliance infrastructure calibrated for a regulatory burden they did not legally carry. The question of what work was strictly necessary had never been asked on their behalf. They were paying for overhead — inflexibility, poor support, a system that served the vendor's standard offering more than it served their actual situation. The minimum necessary compliance infrastructure for their context was substantially smaller than what they had been sold. Nobody had told them that.
Michigan is the engagement this chapter returns to. A laboratory reached their ISO/IEC 17025 accreditation review with approximately three months of preparation undone and two weeks remaining. We compressed the work and got them through. Zero accreditations lost across all engagements — not because the regulatory environment was forgiving, but because the preparation was correct once someone in the room understood what correct looked like.
Along the way, we made a mistake. Early in the practice, we recommended a LIMS platform to a client in good faith. The vendor was not responsive to the client's actual needs. Requests went unaddressed. The system did not adapt. It was eventually replaced — which is expensive, disruptive, and a particular kind of accountability that attaches to whoever made the recommendation. We did not lose the client. We did lose a clean record. And I came away from it with a very specific opinion about what a LIMS should be: built by someone who has had to use one, responsive to the people inside it, and not dependent on a vendor who has already moved on to the next sale.
The Michigan crunch was possible because of a set of Google Sheets documents that most clients never knew existed. Complex enough to automate the statistical analysis for method validations — accuracy, precision, LOD/LOQ, reproducibility — in enough depth that I could look at a dataset and make a definitive call in hours rather than days. Compare datasets, identify gaps, tell a client definitively whether they had enough or needed more. The speed that looked like expertise from the outside was, in large part, infrastructure built before it was needed. I had made the instrument before I knew I would need it, and when I needed it, it was ready.
Akwesasne was different. Lower stakes in the sense that the regulatory situation was clear once understood, which meant there was room to experiment. I had been using AI tools to extend what I could build, and for the first time I tried building something with real structure — a TypeScript prototype, AI-assisted, something that actually held together under use. It worked. Not just adequately. It worked well enough to make me genuinely curious about the ceiling. The question that followed was not what is broken and needs fixing. It was I just found out I can build serious software — so how far can I actually take this?
The answer turned out to be: pretty far. GIMS is a grammar-based, schema-driven workflow engine — nouns, verbs, adjectives, phrase handlers defining any workflow through configuration rather than code. The structural approach emerged from AI experimentation, not from software architecture training. I came in as a systems thinker first and a developer second, and the grammar-based model was the most natural way to describe what I had been trying to think through for years. Laboratory testing, HR onboarding, financial approvals: the same engine, different configurations. It went further than I expected it to go.
But the deeper target was never the LIMS market specifically. It was the SaaS lock-in structure. The commercial workflow software industry runs on a single bet: that the switching cost, once you are inside, is higher than the ongoing subscription. Your data is in their format, your workflows are in their system, and leaving costs more than staying. The bet usually pays off. GIMS is built on the opposite premise.
Spin it up quickly. Modify it without a support ticket. Add an attribute when you need one. Automate something with a short Python script against a well-documented template. Your data lives in a SQL database. Your exports are CSVs. If you want to leave tomorrow, everything is organized and ready. The minimum amount of structure required to do the work — and nothing beyond it. The value is not that GIMS is better to use than the incumbents, though I believe it is. The value is that it applies seiryoku-zenyo to the infrastructure itself: it is structurally incapable of holding you hostage because there is nothing in the design that serves any interest except yours.
Bottlenecks are not problems to be solved. They are features of reality — the point where the available throughput is smaller than the demand, and no amount of effort on the wrong side of them changes that. The question seiryoku-zenyo asks about a bottleneck is not how to eliminate it but how far it can be pushed. Every time the constraint moves, the space of what is possible expands. This is what GOMS is about.
Building GIMS with AI assistance was fast relative to building it without. It was also slow relative to what it should have been. The bottleneck was not the model — the model was capable. The bottleneck was everything surrounding the model: the copy-paste loop, the error reporting, the session-by-session reconstruction of context that the model needed to do useful work. That surrounding overhead was not irreducible. It was just work that nobody had yet compressed.
GOMS uses MCP integrations to interface directly with the errors and the codebase. No copy-pasting. No manual error reporting. No reconstructing context from scratch. The irreducible minimum of human involvement is preserved — approval gates at the moments that genuinely require judgment — and everything else is compressed to the extent current tooling allows. The bottleneck has moved. It will move again. The point is not to reach a final state but to keep asking where the constraint is and what it would take to push it further.
It is closer to setting up your own Bitcoin node than to founding a new blockchain. It solves a specific problem at a specific scale, and it is not a claim about the ecosystem. It is the same claim this document has been making since the pricing system at Bio-Techne: here is the work that simply must be done, and here is how much of the surrounding noise turned out to be optional.
Eight years. The pricing system at Bio-Techne. Three years in the cleanroom watching a LIMS impose its own structure on work that had already defined its own structure. Seven regulatory jurisdictions where the minimum necessary compliance infrastructure was almost always smaller than what was in the room. A Google Sheets document that made a Michigan crunch survivable because the irreducible analytical work had already been compressed. A TypeScript prototype at Akwesasne that revealed a ceiling much higher than expected. A workflow engine built to give data back to the people who generate it. A development environment rebuilt around the question of what overhead was actually optional.
The through-line is not a technical stack. It is not an industry. It is a single question, asked in each new room, about what work simply must be done to achieve the goal — and the consistent discovery that the honest answer is smaller than what currently exists. The excess is not always malicious. It is often just accumulated habit, inherited structure, work that was necessary once and persisted past the moment it stopped being necessary. The practice is noticing it. The discipline is doing only what remains.
Seiryoku-zenyo. Maximum efficiency, minimum necessary effort. It is a judo principle. It applies everywhere I have looked.