マーコール株式会社

May 1, 2026

18F: Modernizing Public Services through Open Digital Innovation
Established in 2014 within the General Services Administration (GSA), 18F operated as a government-internal consultancy designed to bridge institutional silos through cross-agency synergy. Its name, “18F,” was derived from the GSA’s headquarters at 1800 F Street in Washington, D.C.

The organization was defined by two radical principles: an experimental mindset that favored rapid prototyping over rigid bureaucracy, and a commitment to openness—making all code and research public by default. Although 18F was dissolved following the 2025 change in administration, its impact remains foundational. By injecting tech-sector agility into the federal government, 18F built enduring standards such as Login.gov and the U.S. Web Design System (USWDS).

The Challenge of “Coding” the System
Among the many efforts to modernize governance, the Eligibility APIs Initiative stands out as a dense case study in “Rules as Code” (RaC). RaC is a methodology where rules are either co-drafted simultaneously in natural language and machine-executable code, or existing texts are translated into code to enable direct interpretation by computers. 18F’s initiative sought to code the determination criteria for critical social safety net programs.

In the U.S., major social programs like SNAP (Supplemental Nutrition Assistance Program) and Medicaid are federally funded, but the rules are communicated to states primarily via static PDFs or paper manuals. The actual operation, eligibility screening, and system management are left to state and local governments. Consequently, whenever federal policy changes, every state must spend significant time and capital to manually update their system logic. This fragmented process is not only inefficient but carries serious risks, such as benefit delays caused by implementation errors.

Launched in 2017, this initiative aimed to create a system where the federal government would provide the rules’ source code as an API, allowing states to integrate it directly into their own systems. It was a bold attempt to increase the readability and versatility of institutional rules.

Ground-Level Focus and Collaboration with Civic Tech
18F collaborated closely with social program experts. They took a user-centric approach, including field studies in hurricane-struck Florida, to examine the raw journey from application to disbursement.

18F also partnered with civic tech communities such as Code for America, building a collaborative framework that traversed the public and private sectors. Detailed records—including onboarding processes and weekly progress reports—remain accessible on GitHub even today, allowing for deep verification of the project’s trajectory and commitment to radical openness.

The Pivot: The Wall of Decentralization
Technical hurdles were not the primary obstacle; records indicate that building the API itself was relatively straightforward. Instead, the project hit a structural wall within the federal system of governance. Several states expressed concern that a centralized API would necessitate delegating core eligibility determination logic to the federal government, which they viewed as a problematic encroachment on their roles as the programs’ primary operators. This tension regarding operational autonomy was exacerbated by the onset of the COVID-19 pandemic. Government agencies became consumed with daily crisis response, losing the capacity to cooperate on experiments involving high-stakes system migration risks.

As a result, the project pivoted. Rather than delivering a centralized federal API, 18F developed a prototype “pre-screener”—a tool for citizens to estimate their own eligibility. They shifted their goal to publishing the logic as open-source JavaScript, allowing various agencies and organizations to freely verify, modify, and utilize it.

Beyond Technical Issues
With federal rules trapped in static PDFs, civic tech groups and non-profits had to independently interpret and code complex regulations from scratch, resulted in multiple “shadow software” of the same rules, leading to duplicated effort and inconsistent interpretations.

By releasing eligibility logic as open source, 18F demonstrated that the federal government could qualitatively supplement existing activities by providing machine-readable logic. It proved that a public-private ecosystem could be strengthened to deliver highly reliable information to citizens, even if it wasn’t an “official” federal distribution of the rules.

Lessons Learned and Enduring Questions
While the project concluded in 2020, it left behind several critical questions that remain relevant for multi-stakeholder digital initiatives:

1. How can governments provide logic while respecting the operational autonomy of the local governments?
2. Can adopting organizations see enough incentives to outweigh the risks of system migration?
3. Who should be held responsible for the outcomes of decisions made by code?

When contacted for this report, former project member Mike Gintz shared an indispensable insight: rather than trying to overcome the costs and risks of adoption through incentives, it is crucial to minimize the initial burden so that users can immediately realize clear value. However, he also noted that the inherent nature of the Eligibility APIs made such an approach difficult.

This highlights that in projects involving multiple stakeholders, the fundamental issue is often not the technological challenges, but rather the allocation of responsibility.

References
1. 18F Eligibility API Initiative — GitHub
2. Beeck Center for Social Impact + Innovation, “Rules as Code Demo Day” (Demo 1: 18F Eligibility APIs Initiative)
3. 18F Guides
4. 18F Official GitHub
5. “Overview of Initiatives for the Digitalisation of Legislative Affairs” (May 2025, Digital Agency)
6. Virginia Poverty Law Center SNAP Calculator
7. SNAPScreener.com

#CivicTech #DigitalGovernment #RulesAsCode #18F #Agile #EligibilityAPI