We were recently tasked with designing a new coal combustion residuals (CCR) permit application system on a very tight timeline. The rule itself was still being written, so the usual approach would have been to wait for the policy to settle, turn it into requirements, and then start building screens.
This time, we worked alongside the policy team while the rule and the permitting process were still taking shape.
That made a real difference. We were able to ask questions before the process had been reduced to fields and checkboxes. What does industry need to submit? How will a permit writer review it? What happens when an answer is incomplete? How does the reviewer get from an answer to the engineering document that supports it? What needs to remain part of the record five or ten years later when the facility applies for a modification or renewal?
Those conversations pushed us away from thinking about the system as an online permit form. A permit application is really a collection of claims, supporting evidence, review decisions, and changes over time. The system needs to preserve the connections between all of them.
My view is that this is where many permitting systems fall short. They digitize the intake process, but the result is still a pile of forms and attachments. The applicant no longer mails a box of paper, which is progress, but the permit writer may still have to work through the electronic equivalent of that box.
The better approach is to design around the review.
Documents Should Be Evidence, Not Attachments
Documents are unavoidable in permitting. Design drawings, engineering reports, diagrams, calculations, and operating plans often contain the substance of the application. There is no practical way to turn all of that into structured fields, and trying to do so would probably make the system worse.
But simply allowing uploads is not enough.
An attachment sitting in a document tab has very little context. The reviewer may know that it supports the application, but not which answer it supports or where the relevant information is located. If the file is a thousand pages long, finding that information becomes part of the review effort.
Even a reference to “page 5” can be unclear. Is that the fifth page in the PDF viewer or the page labeled 5 in the document? What happens when the file has a cover sheet, appendices, inserts, or separately numbered sections?
We designed a document library to address that problem. The industry user uploads a document once and can reuse it throughout the application. When a worksheet answer depends on that document, the user selects it and points to the specific page and paragraph that support the answer.
On the regulator side, the permit writer sees the answer and its supporting reference together. If the answer points to a drawing on page 350, the system opens the document at that location. The reviewer does not have to search for it, and the applicant does not have to upload another copy of the same file.
I like this part of the design because it is simple and practical. It turns a document from a general attachment into a piece of evidence connected to a specific answer.
That connection also becomes part of the permit record. Years later, someone reviewing a modification should be able to see not only what the applicant said, but which document supported the answer at the time.
Structure the Parts That Benefit From Structure
The answer is not to replace documents with hundreds of data fields. Permitting systems need both.
Structured data works well for information that needs to be validated, compared, reused, or searched. RCRAInfo already has facility information, regulated units, and other regulatory context. A permit application should start with that information instead of asking the applicant to recreate it.
The worksheets then collect answers in a consistent format where that makes sense. Documents remain first-class parts of the submission, but they are connected to the structured answers they support.
This gives the permit writer a much better record to review. It also reduces repeated entry for industry and makes it possible to tell when required information is missing before a person spends days working through the package.
The important part is the relationship between the pieces:
- What question was asked?
- What answer did industry provide?
- Which document supports that answer?
- Where in the document is the supporting information?
- Which version of the question applied when the application was submitted?
If the system preserves those relationships, it can do much more than store files.
State Flexibility Needs Versioning
State-specific data creates another design problem. Different states may need additional questions for their own programs. The usual options are to put everything in a large free-form field or build a custom worksheet every time a state needs something different. Neither approach scales very well.
We explored a worksheet builder that allows state regulatory staff to configure their own questions. The system can display a worksheet based on the facility, state, or type of unit involved. A landfill can receive one set of questions while another unit type receives a different set, without requiring a new software release for every variation.
That flexibility only works if it is versioned. If a state changes a question next year, an application submitted today must still show the question that was in effect today. Otherwise, the historical record slowly stops making sense.
This is not just a database concern. It is part of the integrity of the permit record. The application needs to preserve what was asked, what was answered, and what supporting material was provided at that point in time.
At submission, the system can use the federal and state worksheets, structured answers, and referenced documents to generate a dynamic copy of record. That package goes through the existing signature process and becomes the submission the regulator reviews.
Organize the Record Before Adding AI
Once the application is organized this way, automation becomes much more useful.
We can provide the relevant CFR material, structured answers, facility context, and supporting documents to an AI model and ask it to identify possible gaps. The result is an initial compliance report that the permit writer can review before beginning the full technical analysis.
If the application is missing something significant, the regulator can return it sooner. Industry can respond sooner too. That matters because the time between submission and the first useful round of feedback is one of the places where permitting timelines can stretch.
The AI is not making the permit decision. It is helping the permit writer find possible gaps and get to the relevant information faster. The regulator still reviews the record and makes the decision.
We also introduced a focused assistant that can answer questions about a specific facility and permit application. Because it has the submission, the facility context, and the supporting documents, its answers can stay grounded in that record. Current models can also work with drawings and diagrams, which matters in a process where some of the most important information may be visual.
None of that works particularly well if the input is just a folder full of files. The AI becomes useful because the system already knows how the questions, answers, documents, and facility data relate to one another.
That is the part I think gets missed when people talk about adding AI to government systems. The model is not the foundation. The record is the foundation.
Security is part of that foundation as well. The permit data stays inside our AWS environment, and the models are not trained on it. Permit applications can contain sensitive facility information. If regulators and industry do not trust where that information goes, they will not trust the system built around it.
Build for the Life of the Permit
A permitting system should not stop being useful when the permit is approved.
The final record needs to show which facility units and processes the permit covers. When the facility later applies for a modification or renewal, the system should know what was previously approved and which evidence supported that decision.
The same applies to the review history. Submissions, requests for additional information, approvals, denials, and other review events should remain connected to the permit. Meetings and other events that happen outside the system may need to be recorded as well.
This does not mean the first release needs to automate every part of the permitting lifecycle. It does mean the data model should not treat the approved application as a packet that disappears into an archive.
The permit should become part of the facility’s regulatory history.
Start With the Review
Working directly with the policy team gave us the chance to think about these problems before the process hardened into a list of software requirements. That was important, but the larger lesson applies beyond CCR.
The best permitting systems are not built by taking a paper form and putting it online. They are built around the way information will be submitted, supported, reviewed, corrected, approved, and used again later.
Collect structured data where it helps. Keep documents where documents are necessary. Connect every important answer to its evidence. Preserve the version that was actually submitted. Give states flexibility without turning every change into a development project. Then use automation where the organized record gives it something reliable to work with.
That is a more practical way to build a permitting system. Start with the review, not just the form.
