Agenda Item 7 - The Docket and Packet Reader

Runs continuously in the background and polls feeds, ingests new filings, decides whether any public government documents touch topics that I've told it to care about.

Comment

Inspiration

Keeping up with federal regulatory proceedings is difficult. A singular agency can publish dozens of documents in a short period of time, but only a small number of them actually matter to any particular organization or person. Important deadlines can also be buried inside of long notices and proposed rules.

Agenda Item 7 was inspired by solving this- building a personal regulatory intelligence system that could continuously watch government proceedings, determine which ones are actually relevant, read the important ones, and turn them into something useful for the user.

What it does

Agenda Item 7 monitors regulatory documents from Regulations.gov and processed them through an AI-powered pipeline.

Simply set up a watch that specifies an agency and topics of interest, then the system is able to:

  1. Discover newly published regulatory documents
  2. Use Gemini 3.5-flash-lite to determine whether each document is relevant
  3. Discard irrelevant documents to not spend any resources on deeper processing
  4. Retrieve the full document for relevant filings
  5. Store the original document in Google Cloud Storage for future re-analysis
  6. Use Gemini 3.7-flash to analyze the document
  7. Track the evolving understanding of a regulatory docket
  8. Extracts important deadlines such as comment and reply-comment dates
  9. Generates calendar events for upcoming deadlines
  10. Produces a draft comment when a proceeding is still open for public comment (optional)
    • The agent has no ability to file draft comments because an agent with the authority to enter text into a federal rulemaking record on someone's behalf is the wrong shape for this problem.

For example, during testing, the system was able to examine 25 FCC documents from the past 30 days. (Capped at 25, can examine unlimited assuming unlimited time is available). It rejected routine notices and unrelated documents, but identified "Build America: Eliminating Barriers to Wireline Deployments" as relevant.

The system then identified the proceeding as FCC-2026-3072, summarized its significance, and extracted the deadlines including initial comments and any reply comments.

Running the same pipeline against FERC, one order produced a docket tracker containing ten distinct parties with separate positions. Edison Electric Institute partially supporting, Bonneville Power partially opposing over software costs, MISO citing interconnection queue growth.

How I built it

I built this primarily in Python and using a server-oriented architecture that is designed to run both locally and on Google Cloud. The core pipeline's divided into several stages:

Regulations.gov->Discovery->AI Triage->Document Retrieval->Cloud Storage->AI Analysis->Docket Tracking->Deadlines->Actions

The Regulations.gov API allowed me to get the initial document metadata. I built a defensive API adapter that is able to handle agency filtering, pagination, document normalization, rate limits, and inconsistent metadata.

The first AI stage is a lightweight Gemini triage agent. It is able to receive document metadata and the user's interests without actually downloading the document. This makes the system significantly cheaper than sending every filing through a full analysis.

Only documents that pass triage go further down the pipeline. Their full filings are retrieved and stages in Google Cloud Storage, preserving the exact source material that was analyzed. The deeper analysis is then performed by a more capable Gemini model.

The analysis produces structured information about the filings. Those results are then folded into a persistent docket tracker so that the system can build an evolving understanding of a proceeding rather than treating every filing as an isolated document.

The project also keeps track of checkpoints so that subsequent runs can distinguish newly discovered documents from documents that have already been processed.

The system was designed using Google Cloud Run, Cloud Storage, Firestore, and scheduled processing. I also built a local run_once.py runner script so that I could test the exact same processing pipeline before deploying it (and for live demos).

Challenges I ran into

One of the biggest challenges was with the behavior of the Regulations.gov API.

The API's filtering behavior was not always intuitive. Specifically, combining search-term and agency filters could produce unexpectedly poor results. So instead of relying entirely on upstream keyword filtering, I changed the architecture to retrieve agency documents and let the AI perform the relevance decision.

This created yet another challenge, though: cost.

Needing to send every document to a large model would be wasteful when most documents would be obviously irrelevant. The two-stage triage architecture solved this by using a cheaper model for the initial relevance decision and reserving expensive document retrieval and analysis for the small number of documents that pass.

Another challenge I faced was that Gemini 3.x is only served from Vertex AI's global endpoint. This means that every 3.x model returned 404 NOT_FOUND from us-central1, while client.models.list() reported those same models as present in that region. A model appearing in the listing, therefore, was not proper evidence that it will serve. This made me split configuration into two separate settings: one where models are served global, versus where infrastructure lives in us-central1.

Yet another challenge was the fact that "seen" should not be treated the same as "done". My first deduplication skipped any document that was already in the database. This meant that a document that passed triage and then failed to download was buried permanently. Because of this, I made it so that documents carry a stage, only "analyzed" and "rejected" are terminal, and anything stuck mid-pipeline is retried on the next run.

Accomplishments that I'm proud of

I'm very proud of building a pipeline that goes beyond simply asking an AI model to summarize a PDF.

I was able to combine:

  • Government API integration
  • Intelligent relevance filtering
  • Document retrieval
  • Cloud Storage
  • Structured Gemini agents
  • Persistent Firestore state
  • Docket-level reasoning
  • Deadline extraction
  • Calendar generation
  • Checkpointing and retry behavior
  • Cloud Run deployment architecture

The most satisfying result was seeing the system reject an enormous amount of irrelevant FCC material while correctly identifying a genuinely relevant wireline deployment proceeding.

The system was also designed so that failures do not necessarily lose work. Documents that fail later in the pipeline can be retried if a watch changes, while successfully processed documents are tracked through persistent state.

Most importantly, the project turns an overwhelming stream of government documents into a much smaller set of relevant proceedings.

What I learned

Building this project definitely taught me a lot. It taught me that building a useful AI application involves much more than selecting a model and sending it prompts.

A large part of the work was designing the surrounding system. Specifically, deciding what information the model should see, when it should see it, what should be persisted, and how to handle imperfect external API's.

I learned the value of structured AI outputs. Having Gemini return structured objects for triage decisions and analysis made it possible to connect AI reasoning to traditional software components such as databases, deadline trackers, and calendar generation.

I also learned that AI systems benefit from carefully designed pipelines. You need to make sure that you are being efficient with the models you choose; using a small model for triage and a larger model only when necessary made the system both more efficient and practical.

What's next for Agenda Item 7 - The Docket and Packet Reader

The next step would be turning this project from a prototype into a continuously running regulatory research assistant.

A future version could monitor many agencies and regulatory topics simultaneously, automatically notify users when a highly relevant filing appears, and maintain a richer history of how each docket has evolved.

I could also make it so that the system compares new filings to previous filings in the same proceeding, and identifies changes in an agency's position, and highlights disagreements between commenters.

Ultimately, Agenda Item 7 aims to be a docket and packet reader that continuously watches the regulatory landscape, filters out the noise, understands what changed, and tells you what actually deserves your attention. It already does this. What separates the prototype from the product is scale: the current deployment is sized for one person's interests on a hackathon budget, with per-run document caps as the cost ceiling. The architecture doesn't need to change to lift them- only the budget does.

Built With

Share this project:

Updates

Submission history