Before you can build a compliant government site, you have to understand the standards. That sounds simple until you try it. OMB Circular A-130 references FISMA, which references FIPS 199, which references NIST 800-53. The 21st Century IDEA references Section 508, which references WCAG 2.0, now at 2.2,, two revisions while you weren't looking. Each document is 20 to 400 pages of cross-referenced regulatory language written for lawyers, not for the developer who just needs to know if their form labels pass.

GovDoc Explainer reads those documents and uses an LLM to produce plain-language summaries, practical compliance actions, and role-based perspectives so you don't have to read 100 pages of OMB circular to get the answer.

The Problem

We've been reading these standards since 2013 on GSA contracts. The information is all public. The problem is it's scattered across dozens of PDFs, web pages, and memos, each in a different register, each cross-referencing the others, none written for the people who actually have to implement them.

A PM writing a proposal doesn't need 400 pages of FedRAMP guidance. They need: what do we have to do, when, and what will it cost? A developer needs to know which WCAG criteria apply to form validation, and what's the minimum contrast ratio for error states.

The tool produces exactly that: targeted, role-specific extracts from documents that were never meant to be read this way.

How It Works

The system is configured through files in a ./config directory:

  • Sources (sources.csv) : A CSV listing every government standards document to process, organized by category: Websites & Digital Services, Security & Privacy, NIST, FedRAMP, CISA, Department of State, and more. Each row has a category, a standard name, and a URL. Local PDFs can be dropped into a folder instead, and eCFR links are fetched through eCFR's own API so the actual regulation text comes through, not the site's navigation chrome.
  • LLM choice (llm.txt) : Which model to use: OpenAI (GPT-4o mini), Anthropic (Claude), local models via Ollama, or any OpenAI-compatible endpoint; we run a Gemma 4 E4B locally through llama.cpp's llama-server. Sampling temperature is configurable, and two size thresholds (document ceiling and digest part size) are set to match the model's context window.
  • Prompts (config/prompts/) : A set of prompt templates, each producing a different view of the same document, plus the digest templates for oversized documents.
  • Company profile and perspectives (company_profile.txt, perspectives.csv) : The description of the business the summaries are written for, and the roles to analyze from. Both are company-specific: you can generate them from a free-text description of your own company or edit them by hand.

Running npm run build reads each source document, passes it through the prompt pipeline, and generates a browsable HTML output with hybrid search.

The Prompt Pipeline

Each document passes through a series of prompts that produce different layers of understanding:

1. Punchline

The first pass asks the LLM for a single-sentence elevator pitch: what is this document and what is it trying to achieve? Written in plain language that a non-technical business person could understand. This is the first thing you see in the output: one sentence that tells you whether you need to read further.

2. Overall Summary

The second pass lists the primary standards, guidelines, and requirements the document actually contains. Security, accessibility, user experience, and compliance get special attention, when the document addresses them. The prompt now says explicitly not to invent entries for themes a document does not cover; a defense-priorities regulation should not come back with an accessibility bullet just because the template asked nicely.

3. Actions

The third pass asks: in practical terms for our company, what minimal list of actions must be taken to show compliance? Each action is short, grounded in something the document actually requires, and filtered to what this role owns. If the document does not meaningfully apply to the business, the model says so and notes what is worth monitoring instead of fabricating a checklist.

4. Role-Based Perspectives

The same document is then analyzed from each configured role:

  • DevOps : Infrastructure, hosting, logging, monitoring, deployment compliance
  • Designer : Human-centered design, UX, UI, accessibility standards
  • Developer : Backend implementation, business logic, technical controls
  • Project Manager : Tracking, requirements and gap analysis, deadlines, audit obligations
  • QA Engineer : Test plans, acceptance criteria, verification and conformance evidence
  • Security Engineer : Security controls, encryption, access management, incident response, privacy

Roles are data, not code. Each one is a row describing who the reviewer is and what they care about when reading a standards document, so a healthcare company can swap in a Clinical Director where a software shop has a Security Engineer.

5. Documents That Are Too Big

Some standards refuse to fit in a context window. NIST 800-53 runs to 1.6 million characters (roughly 400,000 tokens). The old approach was truncation, which meant summarizing the first quarter of the document and pretending that was the document. Now the pipeline splits oversized documents into parts at logical boundaries, summarizes each part, and merges the partial summaries into a single digest that every other prompt consumes. The digest is cached like any other artifact, so it is generated once per document.

Your Company, Your Roles

The shipped configuration describes a federal IT contractor, because that is who we are. But the tool is built for the summaries to be written for a specific business, so the company description is data, not a hardcoded prompt.

Every summary is generated against a company profile: what the business builds, hosts, or operates; its delivery stack; its compliance posture; the roles on its teams. The same document produces different summaries for a dental-clinic network than for a defense contractor, because the model is judging relevance against a different business.

To tailor it, write a few paragraphs about your company and run a subcommand that converts it into a structured profile and suggests the right review roles. A clinic gets clinical and administrative roles; a software shop gets engineering roles. Both are written to gitignored config files after you confirm them, and rebuilding only regenerates artifacts whose inputs actually changed.

The Source Library

The tool currently tracks 158 documents across 19 categories, spanning the major areas of U.S. federal web and IT standards:

  • Websites & Digital Services : Digital Government Strategy, OMB M-17-06, E-Government Act, Section 508, WCAG 2.2, Plain Writing Act, 21st Century IDEA
  • NIST : the RMF suite (800-37, 800-53, 800-53A), digital identity (800-63), media sanitization, PIV credentials, media and cloud guidance
  • Security & Privacy : FISMA, Privacy Act of 1974, Clinger-Cohen Act, FIPS 140-3/199/200/201, Section 889 supply-chain prohibitions, HSPD-12, the HTTPS-Only Standard
  • FedRAMP : System Security Plan, Security Assessment Report, Contingency Plan, Continuous Monitoring, Penetration Testing, Authority to Operate
  • CISA & OMB : Binding Operational Directives, zero-trust memoranda, records-management transitions, Trusted Internet Connections
  • Department of State & Department of Defense : Foreign Affairs Manual data governance and security policies, cyber workforce manuals
  • Artificial Intelligence : Executive Order 14110, OMB M-24-10, the NIST AI Risk Management Framework
  • Plus : a German-language sister corpus (BSI, GDPR, EU AI Act, OZG) processed through the same pipeline

Each source is a real document at a real URL, with a validation script that HEAD-checks every link for rot. The tool fetches, parses, and summarizes them on demand.

Context: {company_profile}. Objective: ensure that our team understands relevant ideas and requirements from the provided Government Standards Document, and how they apply to our specific business.

GovDoc Explainer, system context prompt (v2)

The system context is specific on purpose. The LLM is not asked to summarize the document in the abstract. It is asked to summarize it for the business described in the profile, and that profile is user data, not a hardcoded paragraph. That framing changes what the model extracts and how it translates regulatory language into project-relevant guidance.

Search That Understands the Question

Reading 158 summaries is still work, so the generated site includes hybrid search. A keyword index (Pagefind) catches exact tokens (acronyms, memo numbers, section identifiers like M-22-09). A semantic index built with a compact embedding model catches paraphrase: rules about locking down federal websites finds FISMA even though FISMA never says those words. Both run entirely in the browser, and the two result sets are fused with reciprocal rank fusion: documents both channels agree on surface first.

Local and Private

Government standards documents are public, but your project's context around them is not. The tool supports local inference end to end: Ollama in Docker, or, in our current setup, llama.cpp's llama-server running a quantized Gemma 4 E4B on a Mac. Any OpenAI-compatible local server works; a couple of lines in llm.txt point the whole pipeline at it, including the context-window-sized thresholds the digest pipeline needs. The embeddings that power search were always local (a compact MiniLM model), so a fully local build never sends a document or a prompt to anyone.

# Start a local server (or: docker compose up -d for Ollama)
llama-server -m ./gemma-4-E4B-it-Q4_K_XL.gguf --port 8080

# Point config/llm.txt at it, then generate the analysis
npm run build

# Browse and search the output
npm run serve   # → http://localhost:1414

Why We Built This

We built similar translation layers before: a faceted search tool for pandemicoversight.gov (PRAC), multi-layer caching and security authorization work on USA.gov, and a FedRAMP-compliant Drupal 11 hosting architecture for NOAA's PMEL. In every case the first step was the same: someone had to read the standards and turn them into requirements the team could execute.

Here's where projects stall; compliance requirements turn into assumptions, assumptions become gaps that surface during authorization or, worse, at audit. GovDoc Explainer automates that translation so the team starts with a shared, role-specific understanding before the first line of code.

The project is open source and available at github.com/ednark/govdoc-explainer. It works with OpenAI, Anthropic, Ollama, or any OpenAI-compatible local server. If you are building government websites and spending too much time parsing regulatory documents, get in touch. We are interested in feedback on which standards categories, company profiles, and role perspectives would be most useful to add next.