12 min· building· ai· water
Ninety percent of a permit is cookie cutter
A hydrogeologist at a consulting firm brought us a workflow to automate: the water-use permit applications his firm files all year, eighty-odd pages each, which he described as ninety percent cookie cutter. Most of that can be generated. What makes it worth writing about is the other thing about the document — it goes to a regulator with a licensed professional's name on the certification page, and that changes what the software is allowed to be.
Earlier this year a hydrogeologist at an environmental consulting firm brought us a workflow he wanted to automate.
His firm prepares water-use permit applications. In the state he works in, anyone who wants to pump groundwater — a development irrigating its landscaping, a contractor lowering the water table to dig a lake — needs a permit from the regional water authority, and the application is a package that runs to eighty-odd pages: the authority's forms, a demand calculation by a standard method, a write-up of the source aquifer, drawdown figures from a groundwater model, maps, ownership records, and a certification page signed by a licensed professional. Permits run for five years and get modified every year or two, so the same clients keep coming back. The work is done by staff a few years out of college and reviewed and sealed by the licensed people above them, whose hours are the most expensive in the firm.
His description of it was that ninety percent is cookie cutter. Not easy — there is no room for creativity, and you do it per the rule book. The same calculations by the same standard methods, the same forms, the same sections in the same order, and a hydrogeology write-up that, for a given aquifer, has usually been written and approved before in a neighboring application. Could that ninety percent be generated, so his people spend their time on the ten percent that needs them, and on checking the rest?
Our first thought, and his, was that this was a job for a language model pointed at the form. It is not, and finding that out is a good part of what follows. But the reason this workflow is worth writing about is not the automation. It is what the document is: a filing to a regulator, with a licensed professional's name and credentials on the certification page. If it is wrong, it is wrong in public, in a filing, under somebody's license. That single fact changes what the software is allowed to be.
The job, as it exists today
A permit application of this kind is a package, not a form.
There is an intake section — project, duration, jurisdiction, address, the coordinates and the administrative boundaries that follow from the address. A demand calculation using a standard method with its own required inputs. A section on the wells and the aquifer they draw from. A hydrogeology write-up that has to reason about the source aquifer from the nearest available borehole data. A narrative of the permit history and whatever was agreed in the pre-application meeting. Exhibits — maps, site plans, ownership documents, each labeled and cross-referenced. And a professional certification, signed.
Some of it is genuinely mechanical. Some of it requires running a groundwater model in specialist software that lives outside any of this — two or three hours for a routine site, if the coefficients are ready. And for a routine project none of it is creative, which is not the same as easy: it is exactly the kind of work that consumes a consulting firm's most expensive hours for the least interesting reason.
Why "point a model at the form" does not work
I want to be precise here because the naive version of this is very appealing and we started with it.
The first instinct is that this is a form-filling problem and a language model is obviously good at form-filling. That instinct is wrong, and the way we found out was by building toward it and stopping. What it actually required was taking the application apart section by section, working out how each one is filled in and what logic governs it, and building it the way you would build software rather than the way you would prompt a chatbot.
Because most of the inputs are not in the request. A practitioner has things at their fingertips that never appear in a brief — the site boundary as a geographic file, the in-house borehole data, the knowledge of which nearby project used the same aquifer. The customer put this better than I did: there is a lot we take for granted that we have at our fingertips. None of that arrives with the job.
Because parts of it are not text at all. A model run is a model run. It happens in specialist software, it takes a hydrogeologist's judgment to set up, and the honest architecture is that the workflow stops, the human runs it, and the result comes back in. Pretending otherwise would produce a number that looks like a modeled result and is not one, which in this context is the worst possible output.
And because the most valuable input is not written down anywhere. The approved applications tell you what a package looks like. They do not tell you why it was phrased that way — how this firm words things to avoid a round of questions, which assumptions a particular reviewer accepts, what gets left out on purpose, what supporting evidence is usually enough, which exhibits actually matter, and when it is cheaper to raise a problem early than to be asked about it later. That layer lives in the heads of the people who have filed hundreds of these, and it is the difference between a package that is correct and one that comes back clean.
You cannot infer it from the corpus, because the corpus is the output of it. You have to go and ask — what do you check first, where do juniors get it wrong, what triggers a question from the regulator — and treat the answers as part of the system rather than as onboarding notes. On this workflow that tacit layer turned out to be the highest-value thing in the build, which was not what I expected going in.
And because the useful precedent is public. This is the part that connects it to everything else we do. Applications submitted to these bodies are public record — every nearby applicant's package is available. And a hydrogeology write-up for a given aquifer that has already been reviewed and approved is reusable: the customer's own phrase was that you do not have to reinvent the wheel. So the corpus for this workflow is other people's approved applications, which is the same public record this company has been reading from the beginning, pointed at a different question.
What the workflow does
It derives everything derivable. An address yields coordinates, which yield the administrative boundaries, the nearest weather station, the applicable lookup values. Ownership documents are public and can be fetched. None of this requires judgment and all of it currently gets typed.
It drafts the reasoned sections against approved precedent. For the parts that are prose about a physical situation — the aquifer, the source, the setting — it works from the nearest relevant approved write-ups rather than from a blank page, and says which ones it worked from.
It assembles the package. Labeled exhibits, cross-references, attachments in the order the reviewing body expects them, because a technically correct application in the wrong shape still comes back.
It stops where judgment starts. The model run, the professional certification, and the decisions that depend on knowing this specific site. Those are not gaps to be closed in a later version. They are the shape of the thing.
And it produces a first draft for a person to finish. Delivered as a service first — you send the job, we send back a draft, you review and file it — with self-serve as something to earn later rather than assume. That ordering is deliberate: a workflow whose output carries someone else's license should not go self-serve until it has been wrong in front of us enough times that we know how it fails.
Permits / Groundwater withdrawal / Section 4 — Source aquifer
How you find out whether it works
This deserves its own section, because for this workflow the accuracy method is part of the product rather than an internal detail — and because the customer asked for it before we offered it.
The test is to take applications that were actually filed and approved, regenerate them from their original inputs, and compare what comes out against what was submitted. Not judged on style. Judged on whether the numbers, the sections and the reasoning land in the same place as the package a regulator already accepted.
We have run that once so far, against a single application a consultant had completed, and I want to report it at the size it actually is rather than the size it would be nice for it to be. The calculated sections came back close to the human original. The reasoned geology section was decidedly less close — which is the result you would expect, and the right way round: arithmetic against a defined method is the part a machine should win, and the part that depends on interpreting a site is the part it should not.
More useful than either number were the two defects it surfaced. A table that had been correctly computed and then silently dropped from the assembled document — the calculation was right and the output was incomplete, which is the failure mode most likely to survive a casual review, because nothing looks wrong. And a spatial query that returned the wrong set of neighboring permitted users, which is not a formatting problem but a piece of reasoning that was confidently incorrect.
One more caveat, since I have written elsewhere about how easy it is to score your own homework: that comparison was made by a model reading both documents, not by a hydrogeologist. It is a reasonable way to triage where the differences are. It is not the same as an expert saying the output is fit to file, and the difference between those two matters more here than anywhere else we build.
That is the same move as reading a decade of minutes to see whether the signals were there before the project appeared: you cannot evaluate a system like this on how convincing its output looks, only on whether it reproduces outcomes that already happened. Convincing is the failure mode, not the goal.
The risk nobody in this category names
The sharpest question about this workflow is not about accuracy. It is about validation. An experienced hydrogeologist reads a write-up and knows whether it is right; somebody a year out of college will press the buttons and submit it. Most of the people who would actually use a tool like this cannot yet tell the difference — which means the check the firm has always relied on has quietly stopped running.
That is the real risk of every document-generation product and almost nobody selling one will say it out loud. The tool does not make a junior into an expert. It makes a junior indistinguishable from an expert at the moment of submission — and completely distinguishable three months later, when the deficiency letter arrives and somebody has to explain a number nobody can trace.
The answer is the principle everything we build keeps arriving at from different directions: show the source. Not a confidence score. The actual provenance of each field — this value was derived from the address, this paragraph came from that approved application for the same aquifer, this figure came from the borehole record you uploaded. Then a senior person can review the parts that matter in minutes rather than re-deriving everything, and a junior can be asked where did this come from and be expected to answer.
Provenance is not a trust feature here. It is the quality-control mechanism the firm already has, restored to a process that would otherwise remove it.
What it cannot do
It cannot sign.
A submission of this kind is certified by a named professional whose license is attached to it and who carries the liability. That signature is not a formality at the end of the process, it is the thing being purchased by the regulator — somebody qualified is asserting that this is true, and can be held to it.
Software cannot hold a license. It cannot be sanctioned, insured or struck off. So the most that a system like this can honestly be is the fastest possible way to get a competent professional to the point of signing, and the ambition to remove them is not a roadmap item, it is a category error.
Which means the roles have to be separated on paper before anything is built: what the system drafts, what is technical judgment, what is professional certification, and who carries responsibility for the submission. Four different things, and the temptation is to let them blur, because the output is good enough that blurring them feels pedantic.
That temptation is the actual hazard, and it is worth being blunt about the mechanism. The better the draft gets, the more casually people rely on it — not through carelessness, but because relying on things that keep being right is how competent people save time. So the quality of the output is itself what erodes the review, which is a genuinely awkward property for a product to have and not one you solve by being careful. You solve it structurally: the draft is assembled, a person cleans it, a reviewer validates it, and a licensed professional signs. Four hands, deliberately, and the system occupies exactly the first.
And it does not travel to the next jurisdiction for free. The workflow was built against one regulator's regime, whose forms, expectations and precedent are unusually well documented in public. Pointing it at a neighboring authority is not a configuration change: some bodies simply do not publish the same artifacts, so the precedent corpus that makes the whole thing work may not exist there in the same form. Each regime is closer to a new build than a new tenant, and pretending otherwise is how this kind of product overpromises.
And it does not stretch to the hard cases. These packages have routine shapes and unusual ones, and the unusual ones are unusual precisely because they require a different basis of review — larger projects, contested aquifers, demand justifications built on population projections that the standard form does not contemplate. A workflow tuned to the routine case will produce something plausible for the unusual one, which is worse than producing nothing. Knowing which case you are in is, for now, a judgment made by a person before the workflow starts.
Related
- The proposal you already wrote — the same move on a different document: take a structured form apart and fill what the record can fill.
- Nobody reads the minutes — the public record this draws its precedent from.