Civic Innovations

Somewhere in the tens of millions of words that make up a typical state’s statutory code, there are requirements that no longer make sense.

Provisions that demand wet signatures when digital alternatives exist. Reports that agencies must file but few people read. Approval chains that add weeks to processes without adding any value. Conflicts between statutes passed decades apart. Requirements that may have seemed reasonable in isolation but interact to create bureaucratic obstacles that frustrate both government employees and the people they serve. Everyone agrees that government regulations need to be updated. The challenge is how to do it well at scale.

Manual review is the traditional approach to this problem, and it has obvious limits. Assign a team of policy analysts to read through the state code, title by title, flagging problematic provisions. They’ll find some things. But they’ll also miss things, because human attention flags over millions of words. And the work will take years, by which point new provisions will likely have accumulated.

This is why teams working on regulatory reform are starting to explore how AI tools might help. The appeal of these tools is obvious – AI can process text at a scale humans cannot. Point a model at a state’s entire legal code and ask it to flag provisions that match patterns associated with administrative burden. In theory, you would get comprehensive coverage of state statutes and regulations in a fraction of the time.

But “point AI at the problem” is not a methodology. The teams doing this work seriously are thinking carefully about how to structure the effort so that AI analysis actually produces useful, trustworthy results. Having spent time developing a methodology for a structurally similar problem, I think some important lessons transfer that can be used by teams looking to revise state regulatory rules.

The Parallel With Legacy System Modernization

The challenge of finding burden in regulations has a structural kinship with legacy system modernization that may not be immediately obvious.

Large government agencies run on a collection of systems built decades ago. These systems work, mostly, but they encode business rules that no individual fully understands. The original developers may be retired or gone. Documentation is often incomplete or outdated. The knowledge of what these systems actually do is embedded in the code itself, accumulated across thousands of modifications over decades.

When agencies try to modernize these systems, they face a fundamental problem: you can’t safely replace what you don’t understand. And understanding a codebase of hundreds of thousands or millions of lines exceeds human capacity for comprehensive review.

The parallel to regulatory burden is clear. State legal codes are massive textual corpora that encode requirements accumulated over many decades. The original intent behind provisions may be unclear. The interactions between different provisions are often complex or poorly documented. And the task of understanding what’s actually in this grand body of text exceeds what human reviewers can accomplish through direct reading.

In both cases, AI offers the possibility of analysis at scale. And in both cases, the question is how to structure that analysis so it produces results humans can trust and act on.

SpecOps and System Specifications

I’ve developed a methodology for legacy system modernization called SpecOps. The core tenet of this approach is that AI should produce an intermediate artifact that humans can verify, rather than producing final outputs directly.

In legacy modernization, that intermediate artifact is a specification document: a human-readable description of what the legacy code actually does. AI analyzes the code and generates the specification. Domain and policy experts review the specification and verify whether it accurately captures the system’s behavior. Only after verification does anyone write new code.

This is important because AI can confidently produce outputs that are wrong. It may miss edge cases, misinterpret logic, or generate plausible-looking analysis that doesn’t hold up under scrutiny. If AI outputs flow directly into action without a verification checkpoint, errors can propagate. The specification document creates a place where human judgment can catch what AI might get wrong.

For regulatory reform efforts, the parallel would be structured findings that policy analysts can review. AI would scan legal code and related documents and produce analysis: here are provisions that appear to require reports, here are potential conflicts between statutes, here are requirements that may be duplicative. But the AI doesn’t determine that these provisions are actually burdensome. It surfaces candidates. Humans review the candidates and make determinations.

This framing sets appropriate expectations. AI doesn’t replace the policy judgment required for reform. It makes that judgment possible by surfacing relevant material from a corpus too large for humans to review comprehensively.

Instruction Sets as Portable Knowledge

One of the most useful concepts from SpecOps is the instruction set – the explicit guidance that teaches AI how to analyze a specific type of material (like legacy code) – are shareable.

An instruction set for understanding COBOL code includes patterns for recognizing how COBOL structures logic, common idioms in government COBOL systems, and guidance for extracting business rules from procedural code. The instruction set is what transforms generic AI capability into context-specific analysis.

These instruction sets turn out to be highly portable. An instruction set for comprehending COBOL eligibility calculations works whether you’re modernizing a benefits system in California or a tax system in New York. The COBOL is similar enough, and the patterns of government system design are common enough, that the instruction set transfers and is useful in multiple contexts.

The same principle also applies to regulatory analysis. An instruction set for identifying reporting requirements in statutory language should work across states. One for spotting conflicts between statutes and implementing regulations could be refined through use in one jurisdiction and then shared with others. The patterns of legal drafting are similar enough that instruction sets should transfer.

This creates an opportunity for cumulative improvement. A first-generation instruction set for identifying burden sources will likely have some gaps. Those gaps become visible when policy analysts review the output and note what was missed or mischaracterized. The instruction set can then be iteratively improved, and subsequent analysis will be more accurate. Each jurisdiction that uses and refines these instruction sets can make them more valuable for the next jurisdiction that uses them.

If tools are built around explicit, shareable instruction sets rather than opaque proprietary products, the knowledge of how to find regulatory burden becomes a public good that accumulates over time.

Simple Tooling Is All You Need

One implication worth emphasizing: the tooling required for this work is not exotic.

The minimum viable toolchain for SpecOps is a Git repository, an AI coding agent, basic instruction sets, a markdown or text editor, and a pull request workflow for reviews. No specialized or expensive platform is required.

The regulatory analysis equivalent would be very similar: a frontier AI model with sufficient context window, instruction sets tuned for identifying burden patterns in legal text, a repository for managing those instruction sets and storing outputs, and a review workflow that routes findings to policy analysts for verification.

The value is in the methodology and the shareable instruction sets, not in proprietary tooling. This is important for sustainability and for cross-jurisdiction sharing. States can adopt and adapt the approach using tools they very likely already have access to.

The Future of Regulatory Reform

Teams are actively exploring how AI can accelerate the identification of administrative burden in government regulations. The opportunity is real: AI can help humans see what’s in these massive textual corpora at a scale that manual review alone simply cannot achieve.

But the goal isn’t AI-generated reform recommendations. The goal is comprehensible representations that allow humans to exercise judgment effectively. AI can surface candidate options for change. Humans haver to verify these findings and make decisions about what to actually change.

The SpecOps methodology was developed for legacy system modernization, but the core principles applies to regulatory reform as well: before you can safely change complex accumulated logic, you need to understand what’s actually there.