Platform Methodology & Technical Documentation

A technical reference for the data sources, algorithms, and analytical methods underlying the CensusGo platform — for researchers, legal professionals, and analysts who cite this work.

Platform: CensusGo (censusgo.com) Data vintage: ACS 2024 5-Year Estimates Updated: April 2026 Version: 3.0
Cite as: CensusGo Platform Methodology Documentation, Version 3.0 (2026). censusgo.com/methodology
Section 1

Overview

CensusGo is a demographic intelligence platform built on the U.S. Census Bureau's public data infrastructure. It is designed to make the full depth of American Community Survey (ACS) and decennial census data accessible to five distinct professional audiences: academic researchers, journalists, redistricting attorneys, urban planners, and members of the public new to census data.

Three core technical systems distinguish CensusGo from standard census data portals:

The Census Intelligence Engine (Version 3) — a five-stage natural-language search pipeline that translates user queries into ranked ACS variable codes across 16,717 indexed variables. The engine's architecture deliberately separates deterministic Python logic from probabilistic AI inference, using a curated vocabulary dictionary to handle approximately 90% of real-world queries at zero computational cost and reserving AI only for the creative long tail.

The VTD Demographic Computation Engine — a methodology for producing Voting Age Population (VAP) and Citizen Voting Age Population (CVAP) estimates at the Voting Tabulation District (VTD) level by combining the P.L. 94-171 Redistricting Data Files with the Census Bureau's CVAP Special Tabulation and Block Assignment infrastructure. This methodology is consistent with the demographic analysis accepted by federal courts in Section 2 Voting Rights Act litigation.

Live API Architecture — all demographic data on CensusGo is retrieved in real time from the Census Bureau's public API (api.census.gov), ensuring users always see the most current published data without lag, caching artifacts, or data warehousing costs.

Section 2

Data Sources & Vintages

CensusGo uses only official U.S. Census Bureau data products. All data are retrieved from Census Bureau APIs and FTP distribution systems. No third-party data intermediaries are used.

2.1 American Community Survey 5-Year Estimates

The primary data source for all demographic, economic, and housing profiles on CensusGo is the ACS 5-Year Estimates, currently at the 2024 vintage (covering the period 2020–2024, published December 2025). The ACS 5-year product pools approximately five years of monthly survey responses — roughly 17.5 million households — to produce statistically reliable estimates at geographies from the national level down to the census tract and block group.

The 5-year product is preferred over the 1-year product for CensusGo's primary tools because it provides coverage of all geographies — including small counties, rural places, and census tracts — where the 1-year product's minimum population threshold of 65,000 produces no data. The tradeoff is that 5-year estimates reflect a multi-year average rather than a single point in time; this is appropriate for the structural demographic analysis CensusGo is designed to support.

DATA SOURCE
ROLE IN CENSUSGO
ACS 5-Year Estimates2024 vintage (2020–2024)
All state, county, place, tract, and block group profiles; racial demographic pages; housing analysis; income and poverty data
ACS 1-Year Estimates2023 vintage (reference year 2023)
Year-over-year trend comparisons for states and large metros (65,000+ population threshold applies)
P.L. 94-171 Redistricting Data2020 Decennial Census
Block-level VAP by race and Hispanic origin; block-to-VTD aggregation for redistricting analysis
CVAP Special Tabulation2016–2020 ACS 5-Year
Block-group-level citizenship-adjusted VAP; input to VTD-level CVAP disaggregation pipeline
Block Assignment Files2020 Decennial Census
Authoritative block-to-VTD crosswalk for aggregation and geographic assignment

2.2 Database Architecture for Search

The Census Intelligence Engine indexes two ACS metadata tables in a MySQL relational database with full-text search capability. The census_metadata table contains one record per ACS table (~1,199 rows) including the table identifier, human-readable title, and universe description. The census_variables table contains one record per indexed ACS variable (~16,717 rows after filtering margin-of-error suffixes), linked to its parent table. Both tables carry MySQL FULLTEXT indexes enabling sub-second boolean-mode keyword retrieval across the full variable inventory.

Section 3

Census Intelligence Engine (Version 3)

The Census Bureau's ACS contains thousands of variables identified by opaque alphanumeric codes (e.g., B19013B_001E) whose labels are written in formal Census vocabulary that ordinary users do not speak. A researcher seeking data on "Chinese household income" has no reason to know this variable lives in the table MEDIAN HOUSEHOLD INCOME IN THE PAST 12 MONTHS — ASIAN ALONE (CHINESE ALONE). The Census Intelligence Engine bridges this vocabulary gap.

⚙️
Core Design Principle Python controls logic. A curated vocabulary dictionary handles common queries. AI handles only the unknown long tail. This hierarchy keeps the engine fast, deterministic, auditable, and nearly free to operate — while preserving the flexibility to handle creative or novel user vocabulary.

3.1 Five-Stage Pipeline Architecture

Stage 0
Input Validation
5-layer security guard
Stage 1
Concept Extraction
Python, not AI
Stage 2
Concept Expansion
Dictionary + AI long tail
Stage 3
Candidate Retrieval
MySQL FULLTEXT
Stage 4
Concept Scoring
Collective matching

3.2 Stage 0 — Input Validation

Before any database access occurs, every query passes through a five-layer guard system. The layers are applied in sequence and reject inputs that are too long, contain disallowed characters, exhibit pathological word patterns, contain SQL reserved words, or produce zero meaningful concepts after noise removal. None of the rejection layers produce messages that reveal internal system structure. The guard system was designed with the dual goal of blocking malicious inputs without creating a fingerprinting surface for adversarial probing.

3.3 Stage 1 — Concept Extraction

Concept extraction is performed entirely by Python. Each word in the validated query is evaluated against a KNOWN_NOISE set — a vocabulary of high-frequency ACS structural words that appear in too many database records to carry discriminating power. Words in this set include grammatical particles, quantitative census structural terms (total, estimate, percent), temporal words, and occupational omnibus terms.

The KNOWN_NOISE set is maintained empirically: a companion analysis script scans all variable labels and table titles in the database, identifies words appearing in more than 40% of records, and flags them as candidates for inclusion. This data-driven approach prevents both over-pruning (removing genuine search concepts) and under-pruning (retaining terms so ubiquitous they match everything and nothing). Each surviving word after noise removal constitutes one concept.

🔑
Key Architectural Decision Python, not AI, decides what counts as a concept. This means the concept list is fully deterministic, auditable, and immune to AI hallucination. The engine's behavior on any given query is completely reproducible and explainable to a user or a court.

3.4 Stage 2 — Concept Expansion

User vocabulary rarely matches Census Bureau vocabulary exactly. A user who types "elderly" must be mapped to the terms elderly, senior, older, aged, retirement that actually appear in ACS labels. The expansion system uses a three-tier hierarchy:

Tier B — CENSUS_SYNONYMS Dictionary. A curated mapping from user vocabulary to Census vocabulary. The dictionary covers the most common demographic, economic, and housing concepts users search for, including ethnic group names, policy concepts, and colloquial terms. A critical design property: the original user word is always included in the expanded term list regardless of what the dictionary adds. Expansion is strictly additive — the system never substitutes Census vocabulary for user vocabulary, only augments it. This prevents dictionary coverage from inadvertently suppressing exact-match hits in the database.

Tier C — AI Inference (long tail only). For any concept word not in the dictionary, the AI model is queried for Census-relevant synonyms. The AI is explicitly instructed to return only terms that appear in Census data — not general-purpose synonyms. The dictionary handles approximately 90% of real-world queries; AI handles the creative long tail. This architecture keeps AI API costs negligible under normal usage volumes.

3.5 Stage 3 — Candidate Retrieval

MySQL FULLTEXT search in BOOLEAN MODE retrieves raw variable candidates from the database. Each expanded concept term becomes a wildcard search token. Two parallel queries run against the variable label index and the table title index. Results are merged and deduplicated by variable identifier. A configurable per-concept candidate cap prevents runaway queries on common terms from flooding the downstream scoring stage.

3.6 Stage 4 — Concept Scoring & the Collective Matching Principle

Results are ranked by how many of the user's original concepts are satisfied, not by a black-box relevance score. This produces rankings the user can visually verify and audit.

💡
The Collective Matching Innovation A variable satisfies a concept if that concept's expanded terms appear anywhere in the combined text of the variable's label and its parent table title — not just the label alone. A variable labeled "Female: 25 to 34 years" under the table "MEDIAN HOUSEHOLD INCOME — CHINESE ALONE" correctly matches the query chinese female income: "chinese" and "income" are satisfied by the table title; "female" by the variable label. Without collective matching, this variable would score zero because its label alone mentions neither "chinese" nor "income." This design substantially improves recall for ACS variables whose labels are intentionally narrow because the contextual meaning lives in the table title.
match_score(variable) = concepts_matched / total_concepts
where combined_text = variable_label + " " + parent_table_title
and a concept is matched if any expanded term appears in combined_text

Result diversification limits output to a maximum of 4 variables per parent table and 20 total results. This ensures users see breadth across the ACS variable inventory rather than depth within a single table. Results are color-coded by match ratio (green = all concepts matched; orange = partial; grey = low match) and display the matched concept tags so users can immediately verify why each variable was returned.

Section 4

VAP and CVAP at the VTD Level

Section 2 of the Voting Rights Act (as amended 1982) requires analysis of minority voting-age population at a geographic level finer than the county. The Supreme Court in Thornburg v. Gingles (1986) established that meaningful vote-dilution analysis requires accurate measurement of the minority voting-age population, and subsequent decisions — particularly Bartlett v. Strickland (2009) and Allen v. Milligan (2023) — have confirmed that CVAP is the preferred denominator for measuring the eligible electorate in a proposed district. This section describes the methodology CensusGo uses to produce VAP and CVAP at the Voting Tabulation District (VTD) level.

4.1 Data Sources for VTD Analysis

VTD-level demographic analysis draws on three official Census Bureau products: the P.L. 94-171 Redistricting Data Files (block-level VAP by race and Hispanic origin from the 2020 and 2010 decennial censuses), the CVAP Special Tabulation (block-group-level citizenship-adjusted VAP by race), and the Block Assignment Files (the Census Bureau's authoritative crosswalk from every census block to its corresponding VTD). The Block Relationship Files are additionally used for cross-decade comparisons.

4.2 Voting Age Population (VAP) — Direct Aggregation

Because the P.L. 94-171 Redistricting Data provide VAP at the individual Census block level, and because the Block Assignment Files provide an exact, non-overlapping mapping from every block to its VTD, computing VAP at the VTD level requires no estimation. It is a pure summation:

VAPVTD(race, VTD) = Σ VAPblock(race, b) for all blocks b assigned to VTD

Internal consistency check: Σ VAPVTD within each county = published county-level P.L. 94-171 total

Race and origin categories follow Census Bureau definitions: White alone; Black or African American alone; American Indian and Alaska Native alone; Asian alone; Native Hawaiian and Other Pacific Islander alone; Some Other Race alone; Two or More Races; Hispanic or Latino origin (any race); and Non-Hispanic sub-categories. The Hispanic-origin category is non-exclusive of the race categories, consistent with Census Bureau definitions.

4.3 Citizen Voting Age Population (CVAP) — Population-Weighted Disaggregation

CVAP is published by the Census Bureau only at the block group level — the finest geography for which sample-based citizenship estimates are statistically reliable. Because block groups are aggregations of Census blocks, and blocks are the unit mapped to VTDs, producing VTD-level CVAP requires a three-stage disaggregation and re-aggregation procedure.

Stage 1 — Block-Level Population Weights

For each Census block within a block group, the block's proportional share of the block group's total VAP is computed from the P.L. 94-171 data:

weight(block) = VAPblock / Σ VAP(b) for all blocks b in the same block group

Constraint: Σ weight(b) = 1.0 within each block group (verified to ±0.0001)

Blocks in block groups with zero total VAP receive a weight of zero. This condition affects a negligible fraction of block groups — primarily uninhabited institutional or geographic areas — and introduces no measurable bias in VTD-level totals.

Stage 2 — Block-Level CVAP Estimation

CVAPest(block, race) = CVAP(block group, race) × weight(block)

Block-level CVAP estimates are retained as floating-point values through the subsequent aggregation step. Premature rounding at the block level introduces systematic error that compounds across large VTDs containing many blocks; rounding is deferred until after VTD-level aggregation.

Stage 3 — VTD-Level Re-Aggregation

CVAPVTD(VTD, race) = Σ CVAPest(block, race) for all blocks assigned to VTD

Final values rounded to nearest integer after aggregation

4.4 Cross-Decade Alignment

When comparing 2010 demographic data to 2020 VTD geographies — a standard requirement in redistricting litigation examining population change over the decade — block boundaries must be reconciled. The Census Bureau publishes Block Relationship Files quantifying land-area overlap between every 2010 block and every 2020 block. For each 2010 block spanning multiple 2020 blocks, 2010 population is distributed proportionally to the land-area overlap:

Pop2010-on-2020 = Pop2010 block × (Areaoverlap / Area2010 block)

The area-weighting assumption is the standard approach in the redistricting demography literature and has been accepted by federal courts. It is preferable to ignoring boundary changes, which would introduce systematic error in areas of high growth or significant boundary revision.

4.5 Validation Procedures

The following internal consistency checks are applied at each stage:

CheckCriterionAction if Failed
VAP county recovery Sum of VTD-level VAP within each county must equal the published P.L. 94-171 county-level figure exactly Data loading or aggregation error — halt and investigate before use
CVAP weight-sum Sum of block weights within each block group must equal 1.0 ± 0.0001 Zero-VAP block groups documented and tracked separately
CVAP county recovery Re-aggregated VTD CVAP to county level must recover published county CVAP within 0.5% of county total Divergences above threshold flagged for investigation
Race consistency Sum of single-race CVAP categories consistent with total CVAP per VTD; Hispanic-origin categories non-exclusive of race Definitional conflict — review Census Bureau race/origin coding guidance
⚖️
Federal Court Acceptance The methodology described in Section 4 is consistent with the analytical approach credited by federal courts in Section 2 Voting Rights Act litigation. VTD-level CVAP analysis using population-weighted block disaggregation has been accepted in Allen v. Milligan, 599 U.S. 1 (2023); Singleton v. Merrill, 582 F. Supp. 3d 924 (N.D. Ala. 2022); and NAACP v. McCrory, 831 F.3d 204 (4th Cir. 2016), among other proceedings. The use of CVAP as the preferred Gingles denominator reflects the holding in Bartlett v. Strickland, 556 U.S. 1 (2009), and is consistent with U.S. Department of Justice Voting Section practice.
Section 5

Platform Architecture & User Tools

CensusGo organizes its tools into five professional pathways and a suite of standalone analytical applications. All demographic data is retrieved live from api.census.gov; no data warehousing or stale caches are used for the primary data tools.

5.1 Five Professional Pathways

🔬

For Researchers

Semantic variable search, bulk ACS data explorer, reproducible citation outputs, and multi-geography comparison tools. The Census Live Loader AI interface enables natural-language data retrieval formatted for academic use.

📰

For Journalists

Live state profiles with donut charts, national diversity rankings (Herfindahl index), racial demographic deep-dives (four dedicated national profiles), county and city-level demographic lookup, and a live place search covering ~29,000 incorporated places and CDPs.

⚖️

For Attorneys

VRA history and Gingles framework documentation, CVAP choropleth maps, VAP and CVAP variable tools, and a professional analysis suite covering RPV, effectiveness analysis, packing analysis, EI, RxC, and regression methodologies.

🏙️

For Urban Planners

Census tract profile lookup (sortable across all tracts in any county), housing market deep-dive with tenure and vacancy analysis, population age pyramid by any state or the nation, and TIGER/GIS resource integration guidance.

📚

New to Census

Interactive survey-type comparison (Decennial vs. ACS 5-Year vs. ACS 1-Year vs. CVAP), illustrated geographic hierarchy (Nation → Block), and a narrative history of the U.S. Census from 1790 through the 2020 multiracial category expansion.

5.2 Diversity Index Methodology

State diversity rankings on CensusGo use a modified Herfindahl-Hirschman Index (HHI) adapted for demographic diversity. For each state, racial and ethnic proportions are computed for four mutually non-overlapping groups derived from ACS Table B02001 (race) and B03003 (Hispanic origin): Non-Hispanic White alone, Black or African American alone, Hispanic or Latino (any race), and Asian alone. The diversity score is:

Diversity Score = 1 − Σ pi² for i in {NH White, Black, Hispanic, Asian}

Range: 0 (perfectly homogeneous) → ~0.75 (maximally diverse across four groups)
Source variables: B02001_002E, B02001_003E, B03003_003E, B02001_005E

This formulation is equivalent to the probability that two randomly selected individuals from the same geography belong to different groups. It is widely used in demographic diversity measurement (Ottaviano & Peri, 2006; Alesina et al., 2003) and has the desirable property of being intuitive and bounded.

5.3 Racial Demographic National Profiles

CensusGo provides four dedicated national demographic profiles — Black Americans, Hispanic Americans, Asian Americans, and White Americans — each drawing on race- and ethnicity-specific ACS tables: B19013B/D/I/H (race-specific median household income), B17001B/D/I/H (race-specific poverty), B25003B/D/I/H (race-specific housing tenure), and B02015 (detailed Asian sub-group breakdown). All profiles use ACS 2024 5-Year Estimates via live API calls. State rankings and all-state comparative charts are computed client-side from the full 50-state API response.

Section 6

Limitations & Known Constraints

⚠️
ACS Estimates Carry Margins of Error All ACS 5-year estimates are sample-based and carry margins of error reflecting the survey's sampling design. Unlike decennial census data (a full enumeration), ACS estimates at small geographies (tracts, block groups, small counties) can have substantial uncertainty. Margins of error are published alongside all ACS estimates by the Census Bureau. Users engaged in professional or legal work are strongly encouraged to report margins of error alongside point estimates.

CVAP proportional allocation assumption. The block-level CVAP disaggregation assumes citizens are distributed within each block group in proportion to the total VAP. This assumption is well-supported on average but may introduce estimation error in block groups spanning socioeconomically or demographically heterogeneous areas. The magnitude of this error is generally small relative to VTD-level totals.

ACS vintage alignment for CVAP. The CVAP Special Tabulation currently integrated is the 2016–2020 vintage. Users requiring the most current CVAP vintage should note that special tabulations are published on a different schedule than the annual ACS release.

Search engine single-language. The Census Intelligence Engine processes English-language queries only. Multi-word Census concepts (e.g., "foreign born") are currently treated as two independent concepts rather than a single phrase; phrase-level matching is on the development roadmap.

Block-level data. Block-level demographic data from the 2020 decennial census is currently being migrated to the CensusGo database. Tract- and block-group-level data are fully available via the live ACS API; block-level data will be available through the CensusGo database upon completion of the migration process.

Spatial / GIS integration. CensusGo currently delivers tabular demographic data. Geographic boundary files (TIGER/Line shapefiles) for spatial analysis and GIS workflows are not natively served by CensusGo. The Census Bureau's TIGERweb REST API (tigerweb.geo.census.gov) is the recommended complement for planners and analysts requiring spatial layers.

Section 7

References

Legal Cases

  • Supreme CourtAllen v. Milligan, 599 U.S. 1 (2023).
  • Supreme CourtBartlett v. Strickland, 556 U.S. 1 (2009).
  • Supreme CourtThornburg v. Gingles, 478 U.S. 30 (1986).
  • Supreme CourtCity of Mobile v. Bolden, 446 U.S. 55 (1980).
  • 4th CircuitNAACP v. McCrory, 831 F.3d 204 (4th Cir. 2016).
  • N.D. AlabamaSingleton v. Merrill, 582 F. Supp. 3d 924 (N.D. Ala. 2022).

Census Bureau Data Products

  • U.S. Census Bureau. 2020 Census P.L. 94-171 Redistricting Data File. U.S. Department of Commerce. Available at census.gov.
  • U.S. Census Bureau. Citizen Voting Age Population (CVAP) Special Tabulation from the 2016–2020 5-Year American Community Survey. Redistricting Data Office. Available at census.gov.
  • U.S. Census Bureau. 2010 to 2020 Census Block Relationship Files. Geography Division. Available at census.gov.
  • U.S. Census Bureau. American Community Survey 5-Year Estimates, 2024 Vintage. Available via Census Data API at api.census.gov.

Methodological Literature

  • Alesina, A., Devleeschauwer, A., Easterly, W., Kurlat, S., & Wacziarg, R. (2003). Fractionalization. Journal of Economic Growth, 8(2), 155–194.
  • Engstrom, R. L. (1985). Racial vote dilution: Supreme Court interpretations of Section 5 and Section 2 of the Voting Rights Act. Southern University Law Review, 11, 97–132.
  • King, G. (1997). A Solution to the Ecological Inference Problem: Reconstructing Individual Behavior from Aggregate Data. Princeton University Press.
  • Kousser, J. M. (1999). Colorblind Injustice: Minority Voting Rights and the Undoing of the Second Reconstruction. University of North Carolina Press.
  • Ottaviano, G. I. P., & Peri, G. (2006). The economic value of cultural diversity: evidence from US cities. Journal of Economic Geography, 6(1), 9–44.
How to Cite This Page CensusGo. (2026). Platform Methodology & Technical Documentation, Version 3.0. Retrieved from https://www.censusgo.com/censusgo/default/methodology