XVI. The Technical Rules Will Determine the Real Census
Throughout this guide, the same problem appears repeatedly. A broad Census commitment can produce very different outcomes depending on the specifications used to implement it.
“In-office enumeration will be used after contact attempts” sounds reassuring until the number and quality of those attempts are defined. “Administrative data must be sufficient” provides little protection until Census defines sufficient for what purpose. “Multilingual assistance will be available” leaves open which languages, response modes, and geographic areas will receive it.
Baseline 1 is not designed to answer all of these questions. Census describes it as a high-level, mid-decade snapshot and says the design will mature through research, testing, and subsequent baselines. Specific census operations are expected to be identified in Baseline 2, currently planned for summer 2027, with more detailed operational plans later in the decade.
That iterative process is sensible. Census should not lock in detailed rules before testing them. But iteration creates a transparency problem if the public sees only the high-level plan while the specifications needed to build systems and procure services are developed internally.
The questions in this chapter are therefore not criticisms of Baseline 1 for being Baseline 1. They are questions about what lies underneath it, when those materials will become available, and how outside experts and affected communities can engage before the design becomes difficult to change.
A. Examples of Consequential Specifications
The technical decisions beneath the Operational Plan are numerous, but several are particularly important because they determine who receives direct enumeration, whose information is accepted from outside sources, and how errors are resolved.
Response-Sufficiency Rules
Census needs rules for determining whether a response contains enough information to be considered usable. A questionnaire could contain a complete household roster but leave some characteristics unanswered. Another could contain only a partial roster. Census must decide which missing information triggers follow-up and which can be supplied through administrative records, editing, or imputation.
“Sufficient” should therefore be defined separately for the population count and for important characteristics. Evidence strong enough to establish that four people live at an address may not be strong enough to determine their race, ethnicity, relationship, or other characteristics.
Contact-Strategy Rules
The Operational Plan describes a more targeted contact strategy, but detailed rules will determine the number, timing, and type of attempts households receive.
Those specifications could include when visits occur, how many unsuccessful attempts precede proxy contact, whether another visit is required after a language barrier is identified, and when a household can move from fieldwork to administrative enumeration.
Small differences in those rules could affect millions of cases. They should be treated as major methodological decisions, not merely field-management settings.
Administrative-Data Thresholds
Census must establish when administrative records are reliable enough to count a housing unit or person without direct confirmation.
A threshold might depend on agreement among multiple sources, recency, address quality, the number of people linked to an address, or confidence generated by a model. Census may also need different thresholds for determining occupancy, household size, person placement, and individual characteristics.
Advocates should seek the underlying validation evidence and understand how often each threshold produces incorrect decisions for different populations.
Rules for Ending Fieldwork
Closely related to the contact strategy is the point at which Census determines that further fieldwork is unlikely to improve the result.
That decision matters because it defines whether in-office enumeration is genuinely a backstop. A system that requires several meaningful attempts before ending fieldwork is fundamentally different from one that permits a case to close administratively after a single unsuccessful visit.
The rule should also account for why contact failed. A locked apartment building, absence during working hours, need for a bilingual enumerator, and repeated refusal are not equivalent situations.
Primary-Selection Algorithms
Census may receive several responses or records describing the same address or person. Response Processing must determine which information becomes the primary version used in the final census.
The result could depend on whether the response included a Census ID, when it arrived, how completely it was filled out, whether it matches administrative records, or the confidence assigned to the source.
These rules matter particularly when a resident’s direct response conflicts with an administrative record or when members of a complex household provide different rosters. Census should explain when direct respondent information receives priority and when another source can override it.
Person and Address Matching Thresholds
Matching is central to the 2030 design. Census will match non-ID responses to addresses, link administrative records to people and housing units, identify possible duplicates, build the Person Characteristic Frame, and compare records in Coverage Estimation.
Every matching system must decide how much similarity is enough. A high threshold may fail to link records that actually describe the same person. A lower threshold may incorrectly combine different people.
Those errors can vary across populations because names, addresses, household structures, and patterns of mobility differ. Census should publish validation results, uncertainty measures, and the circumstances in which a human reviewer must examine an uncertain match.
Duplicate Resolution
Finding a possible duplicate is not the same as knowing which record is correct. A child may legitimately appear in information submitted by two parents. A college student may be reported both at school and at home. Two people with similar names may share an address.
Census needs rules for determining when records describe the same person, where that person should be counted, and which source supplies their characteristics. Those rules should preserve uncertainty long enough to investigate legitimate complexity rather than treating every apparent duplication as an error to remove.
Quality-Assurance Sampling
Quality assurance will also depend on technical specifications. Census must decide which cases receive reinterviews or additional review, which automated anomalies trigger intervention, and how large a sample is needed to detect errors.
A quality-control system designed primarily to detect employee fraud may miss systematic methodological errors. Sampling should also be capable of detecting problems associated with administrative enumeration, matching, language barriers, address types, and particular populations.
Language Selection
The Operational Plan commits to a Language Program but does not yet determine the final languages, modes, or geographic thresholds for assistance.
The technical rules will determine whether a language receives a full questionnaire, telephone response, translated guide, bilingual mailing, field support, or some combination. They will also determine how Census identifies new or locally concentrated language needs that national data may not capture well.
Given the Commerce English-language DAO, these decisions now involve both methodological and policy questions.
Paper-Mailing and Bilingual-Material Rules
Census must decide which households receive paper questionnaires automatically, which receive internet-first invitations, where bilingual mailings are sent, and when paper is mailed after nonresponse.
These decisions can substantially influence self-response. A rule based heavily on historic internet response may repeatedly direct some communities toward digital modes even when distrust, changing demographics, or current broadband conditions suggest another strategy.
Census should publish the variables, thresholds, and evaluation criteria used to assign these contact strategies.
Why advocates should care
The language of the Operational Plan establishes the possibilities. These lower-level rules determine which possibility a particular household actually experiences.
B. Why Baseline 1 Cannot Resolve These Concerns
Baseline 1 intentionally remains at a high level. Census describes it as a “high-level, narrative description” and a mid-decade snapshot of work underway or planned. It organizes the census around operational areas and activities rather than providing final specifications for each production operation.
This reflects Census’s iterative design process. Research and small-scale testing informed Baseline 1. The 2026 Census Test will examine operational viability, and later testing and integration will inform subsequent versions. The current plan says specific operations will be identified in Baseline 2, planned for summer 2027.
Later detailed operational plans should go further. The 2030 Operations Strategy and Roadmap says the design process will produce detailed operational plans as the design matures. It also explains that high-level business requirements are translated into lower-level operational requirements, which in turn drive operational and IT solutions and inform requests for proposals.
That sequence is important for advocates. Waiting for a final detailed operational plan may be too late for some issues. An operational requirement may already have shaped a procurement strategy, system architecture, or software build before it appears in an easily accessible public document.
The right response is not to demand that Census finalize every technical rule immediately. It is to seek progressive transparency: as important rules become stable enough to drive development or procurement, Census should disclose them, explain the evidence behind them, and identify which remain open to change.
Central transparency question
At what point between a high-level commitment and a final production system will Census make consequential specifications available for outside review?
C. Research Reports That Should Already Inform Baseline 1
Baseline 1 was not created from a blank slate. Census spent the Design Selection Phase conducting more than 50 research projects across five Enhancement Areas. In December 2024, the Bureau announced that those early projects had concluded and that experts and decennial program leaders had reviewed more than 500 preliminary recommendations. They selected recommendations for further research, testing, or possible incorporation into the 2030 design.
That creates an important accountability question: how did this body of research translate into Baseline 1?
The Operational Plan often identifies the general direction resulting from earlier research, but a reader cannot necessarily trace a particular design decision back through the underlying findings, recommendations, review process, and final disposition.
Advocates should ask:
Which Design Selection Phase projects were completed before Baseline 1 was approved?
What reports, analyses, or briefing materials documented their findings?
Which recommendations were accepted for Baseline 1, which were deferred for testing, and which were rejected?
What evidence supported those decisions?
Who participated in the meetings where recommendations were reviewed?
When technical staff disagreed, how were those disagreements resolved?
The last question is especially important. A research project may conclude that an approach improves quality but increases cost. Another office may identify technical limitations. Program leadership may ultimately select a different design. All of those judgments can be reasonable, but the public should be able to understand the chain from evidence to decision.
The Baseline 1 document provides some information about its formal review. Its document log identifies review by the 2030 Census Executive Guidance Group and the 2030 Census Portfolio Management Governing Board, representing senior Census leadership and several participating divisions and offices. It also shows that an internal version was baselined in December 2024 and that the plan was subsequently revised before public release.
That is useful governance information, but it does not substitute for a research-to-design crosswalk. Census should publish a document showing how major recommendations from the Design Selection Phase were handled: adopted, adopted with modification, deferred for testing, or rejected, with enough explanation to understand why.
The existing 2030 Memorandum Series provides an obvious place for that documentation. Census says the series is intended to record major program and policy decisions as well as reports from research, testing, evaluations, and assessments.
Advocacy priority
Ask Census to make the connection between research and design visible, not merely to state that Baseline 1 was “informed by” research.
D. Internal Documents Worth Seeking
The Operational Plan itself identifies an internal layer of program architecture, requirements, agreements, testing, and management that sits beneath the public narrative plan. These materials may provide a much clearer picture of how broad design concepts are being converted into operational rules.
Program Architecture
Census describes Program Architecture as the process for documenting the business needs, structures, and relationships underlying the 2030 Census. It is intended to show how census components interact and provide the foundation for solution architecture and IT systems.
Architecture documents may therefore reveal dependencies that are difficult to see in the Operational Plan, such as how the Person Characteristic Frame feeds In-Office Enumeration or how a response-processing rule triggers additional fieldwork.
Advocates should seek the portions that can be released without exposing protected security or procurement information.
Business and Operational Requirements
Requirements may be among the most consequential documents in the entire program. The Operations Strategy explains that Census translates high-level business requirements into lower-level operational requirements and that those requirements drive operational and IT solutions and inform requests for proposals.
A requirement might specify that a system must support a particular number of contact attempts, retain a particular field, calculate a confidence score, or allow a worker to add an address. Once such a requirement drives software development, changing it can become expensive.
Advocates should seek requirements tied to the specific decisions identified throughout this guide.
Detailed Specifications and Decision Memoranda
Detailed specifications may define thresholds, algorithms, workflows, exception handling, and data exchanges that never appear in a narrative plan.
Internal decision memoranda can provide the reasoning behind them: the alternatives considered, research results, cost or schedule constraints, and approval process.
The 2030 Memorandum Series is supposed to capture major program and policy decisions, but advocates should not assume that every consequential technical choice will automatically meet the Bureau’s threshold for public inclusion.
Risk Registers
Program and operational risk records can reveal where Census itself believes the design is vulnerable. Relevant risks may concern data-source availability, recruitment, language capacity, system development, procurement delays, privacy, schedule compression, or dependence on another Census component.
The value of these records is not that every identified risk will occur. Mature program management should identify risks early. They can help advocates distinguish concerns Census is already addressing from problems that may not yet have received sufficient attention.
Memoranda of Agreement
Baseline 1 establishes a formal process for managing agreements among Census components that provide products or services to the 2030 program. These Memoranda of Agreement are intended to define roles, responsibilities, requirements, and delivery expectations.
They may be particularly useful where the decennial census relies on enterprise services such as demographic and geographic frames, administrative data infrastructure, IT systems, or other capabilities managed outside the immediate 2030 Census Program.
Test-Readiness Reviews
Before major tests and production operations, Census must determine whether systems, staff, data, and procedures are ready. Baseline 1 describes readiness, path, exception, solution-level, and user-acceptance testing as part of Program Architecture and Integration.
Readiness materials can show whether known deficiencies were accepted before a test or operation began, which problems remained unresolved, and what contingency plans existed.
These documents will be particularly important for the 2026 Census Test and the 2028 Dress Rehearsal.
Data-Source Quality Assessments
As administrative and supplemental data become more central, advocates should seek the assessments Census uses to decide that a source is fit for a particular purpose.
The useful question is not simply whether Census has access to a dataset. It is whether the source is sufficiently complete, current, and accurate for the decision Census intends to make with it.
A source may perform well nationally but poorly for young children, recent movers, particular racial or ethnic groups, tribal communities, or people experiencing housing instability. Quality assessments should include those differential results.
Documents worth prioritizing
Program architecture and requirements, decision memoranda, risk records, intercomponent agreements, readiness reviews, and data-source assessments can reveal the operational choices that a high-level plan cannot.
E. FOIA Strategy
FOIA can help fill important gaps, but broad requests for “all records relating to the 2030 Census” are unlikely to be the most useful approach. They can generate enormous searches, lengthy processing, duplicative material, and predictable disputes over exemptions.
A stronger strategy is to connect requests to specific decisions and the dates by which those decisions must be made.
For example, rather than requesting all records about In-Office Enumeration, advocates might first seek the current requirements and decision memoranda defining administrative-enumeration eligibility. A later request could seek validation results used to set a particular threshold. After the 2026 Test, another could seek the test findings and documents supporting changes to the rule.
The same approach can be applied throughout the census:
Identify the decision. What specific rule, threshold, model, data source, or operational choice matters?
Identify the decision point. When must Census settle it for a test, procurement, software build, or production milestone?
Request the records that show the evidence and decision. Target requirements, assessments, briefing materials, recommendations, approval records, and final specifications rather than every email mentioning the topic.
Follow the decision over time. File narrower subsequent requests when testing changes the design or a new baseline is adopted.
Requests can also be sequenced around the 2026 Census Test, Baseline 2, the 2028 Dress Rehearsal, and the final production design. A document that is legitimately sensitive during an active procurement may become releasable later. A requirement that is preliminary today may become final after a test.
Advocates should coordinate requests where possible. Several organizations independently requesting overlapping records can consume agency resources without producing substantially different information. A shared repository of released documents can also make it easier to identify gaps and avoid repeating earlier requests.
FOIA should complement, not replace, demands for proactive disclosure. Major research findings, operational requirements, methodological decisions, and test results should not require a records request when they can be published without compromising respondent confidentiality, cybersecurity, or procurement integrity.
The ultimate objective is not to accumulate internal documents. It is to obtain the information necessary to participate before the decision becomes effectively irreversible.
Advocacy strategy
Build a decision calendar and attach targeted records requests to it. Ask for the evidence, requirements, and approvals behind a specific consequential decision while there is still time to use what the records reveal.
F. Worst-Case Scenario
Census continues to release high-level plans that contain reassuring commitments: direct response remains the priority, administrative data are used only when sufficiently reliable, fieldwork is targeted efficiently, quality is monitored continuously, and historically undercounted populations remain a major concern.
Beneath those commitments, however, the operational rules become progressively more specific. Models receive thresholds. Contact strategies receive stopping rules. Data sources are approved. Matching algorithms are calibrated. Requirements are handed to system developers and contractors.
Most of those decisions receive little public visibility.
By the time an outside researcher learns that one unsuccessful field visit can lead to administrative enumeration, or that a matching threshold performs poorly for a particular population, the rule is embedded in an integrated production system. Changing it would require rewriting software, modifying contracts, retraining workers, repeating security testing, and potentially delaying other parts of the census.
Census can then reasonably say that a late change poses serious operational risk. The problem is that the public never had a meaningful opportunity to raise the issue when the change was still operationally easy.
Testing does not necessarily solve the problem if the underlying specifications and results remain difficult to obtain. Census may report that a test was successful overall while advocates cannot see whether a particular rule performed poorly for small populations. Recommendations may be considered internally without a public record showing which were rejected or why.
By 2028 or 2029, the broad architecture and most underlying systems are effectively fixed. Public engagement continues, but increasingly it concerns how to explain and implement decisions rather than whether to make them.
Worst-case scenario
Census publicly describes the broad design while consequential thresholds, rules, and algorithms are developed internally. When those details finally become visible, contracts are executed, systems are built, and changing the design is characterized as too costly, risky, or late.
Why advocates should care
Transparency after a decision is useful for accountability. Transparency before a decision is what makes participation possible. Advocates should focus on the point when an operational choice becomes specific enough to shape requirements and systems but remains early enough to change.
Where to Look: See sections 1.5, “An Iterative Approach to Maturing the Operational Design,” and 4.1.1, “Program Management,” of the 2030 Census Operational Plan. They explain the progression from Baseline 1 to later operational designs and describe Program Architecture, requirements, internal agreements, testing, and readiness processes that sit beneath the public plan.
The 2030 Census Operations Strategy and Roadmap provides more detail on how business requirements become operational and IT requirements and how detailed operational plans and architectural materials fit into the design process. The 2030 Census Research Project Explorer and Research and Testing materials identify the research that should inform those decisions.
Finally, monitor the 2030 Census Memorandum Series, which Census says will document major program and policy decisions and reports from research, testing, evaluations, and assessments. Gaps between the decisions described there and the rules needed to implement the census can help identify where targeted requests for additional documentation may be most useful.
****