Municipal decision data for systems that need to show their work.
GovData organizes municipal meetings, agenda items, attachments, motions, votes, people, and public bodies into a common data model. Teams can use free public search, paid API access with an issued key, and separately scoped extracts to test retrieval, evaluation, platform, and research workflows against real local-government records.
Keep source and derivation separate.
Originating government records are the source material. GovData normalization, extracted text, summaries, tags, matches, and classifications are derived outputs that can be incomplete or wrong. Consequential conclusions should be checked against the originating record.
Workflows with outcomes your team can test
The dataset supplies records, fields, and relationships. System design, evaluation, source review, and deployment controls determine whether a particular use case is fit for purpose.
RAG experiments with record context
Retrieve meetings, items, attachments, motions, and votes with available source context instead of treating every document as an unrelated text chunk.
- Filters by place, body, date, and topic
- Stable public identifiers where assigned
- Source links where retained and available
- Evaluation against human-reviewed questions
Tests for citation, timing, and stage
Build bounded evaluations around whether a system retrieved the right record, cited the correct source, and distinguished a proposal from a recorded action.
- Source-selection and citation checks
- Proposal versus outcome classification
- Temporal and as-of test design
- Out-of-coverage and insufficient-evidence cases
A common municipal record model
Use normalized fields and available relationships to reduce one-off integration work across selected jurisdictions and source systems.
- Meetings, items, people, bodies, and documents
- Schema and identifier review
- Paid API retrieval with an issued key for supported workflows
- Scoped extracts for feasibility work
Explore local policy and governance questions
Define a cohort, topic, and period, then inspect how available public records and derived classifications support or limit the research question.
- Cross-jurisdiction comparison
- Policy and decision chronology
- Voting and sponsorship records where available
- Documented assumptions and source limits
Originating records and GovData-derived fields are not the same thing
A responsible implementation keeps the source material, transformations, and model-generated fields distinguishable throughout retrieval and evaluation.
Originating public-record material
- Government-published meeting and agenda information
- Item text, minutes, packets, and attachments where available
- Recorded motions, outcomes, attendance, and votes where published
- Links to the originating portal or document where retained
Government records can be amended, incomplete, inconsistent, or removed. The originating source controls when a derived field conflicts with it.
GovData-derived data
- Normalized names, identifiers, entities, and relationships
- Extracted text and OCR output where processing succeeds
- Summaries, topic tags, matches, and classifications
- Observation timestamps and change metadata where maintained
Derived fields are research and retrieval aids. They are not official government determinations and should be validated for the intended use.
Jurisdiction and field coverage varies
The corpus spans 13,000+ indexed jurisdictions, but available entities, documents, dates, and update frequency differ by source and place.
Links depend on available source structure
Meeting, item, motion, vote, person, and attachment relationships are preserved or derived where the published records support them.
Not every document yields usable text
Machine-readable extraction and OCR are available for a subset of documents. Scans, tables, handwriting, and damaged files can produce gaps or errors.
No uniform historical window
Some sources extend back decades while others are recent or incomplete. Historical depth and point-in-time reconstruction must be checked for the selected cohort.
Measure behavior instead of assuming it
Structured records can make evaluation questions easier to formulate. They do not establish that a system cites correctly, reasons over time, or declines unsupported conclusions.
Did the system find the relevant record?
Define a reviewed query set and measure which meeting, item, attachment, or vote records were returned and which were missed.
Does the cited source support the statement?
Review the originating document, not only a normalized field or generated summary, and score support at the claim level.
Did the answer respect the requested date?
Test whether a system uses only records available within a defined period and handles later corrections or additions explicitly.
Does the system expose insufficient evidence?
Include sparse records, unavailable attachments, ambiguous outcomes, and uncovered jurisdictions in the evaluation set.
Start with what is available, scope everything else explicitly
Access channel, history depth, update method, commercial rights, support, and delivery schedule depend on the use case and written terms.
Available starting points
- Public LocalGovIndex search and record pages
- Paid API search and retrieval with an issued key under applicable terms
- Schema review and representative sample records
- Scoped CSV or JSON extracts that can be discussed for a defined project
Requires separate scoping or may be roadmap
- Bulk historical delivery and ongoing update feeds
- Parquet, object-storage delivery, and warehouse shares
- MCP tools, agent integrations, and production connectors
- Model-training rights, redistribution, and custom commercial delivery
Items in the second column may still be in packaging or on the roadmap. This page does not promise availability or a delivery schedule. Confirm channel, rights, coverage, support, and timing in writing before designing a production dependency.
Consequential use requires source review and domain judgment
Municipal records can support research and retrieval. They do not replace legal, financial, compliance, engineering, policy, or operational review.
Data review checklist
- Inspect the originating record for material conclusions
- Distinguish proposals and scheduled items from recorded outcomes
- Validate summaries, tags, matches, and classifications
- Document missing records, extraction failures, and coverage gaps
Rights and deployment checklist
- Define the intended retrieval, evaluation, research, or training use
- Review rights for source documents, derived data, and redistribution
- Set human-review and escalation requirements
- Test with representative failure cases before production use
A record being publicly accessible does not by itself settle every reuse, privacy, retention, attribution, or model-training question. Review the source, applicable law, and the written license for the intended deployment.
A temporal and citation evaluation example
This article illustrates a research problem and possible evaluation patterns. It does not demonstrate model performance or establish that a system will reproduce the analysis automatically.
Request schema, records, and coverage notes
Tell us whether the work is retrieval, evaluation, data-platform research, or a separate training-rights inquiry. We will identify a realistic sample and the access questions that still need scoping.
A useful feasibility package
- Schema overview and representative entity records
- Clear labeling of source fields and GovData-derived fields
- Source links and documents where available
- Coverage, extraction, history, and relationship limitations
- Current access options and separately scoped requirements
Principal: Darius Tajanko, Original Legistar Architect
Email: Email us
Phone: Call us
For faster scoping, include the intended task, jurisdictions or topics, evaluation method, required rights, expected volume, and whether the work is exploratory or intended for production.