マーコール株式会社

May 1, 2026

The Legacy of 18F
18F was a digital service unit established in 2014 within the U.S. General Services Administration (GSA), bringing in private-sector talent and applying Silicon Valley–style agile practices to improve public services.

Named after GSA’s address—1800 F Street in Washington D.C. —18F functioned as an experimental team within government. Although it was dissolved following the 2025 change in administration, its outputs—such as Login.gov and the U.S. Web Design System—remain important pieces of digital infrastructure. Much of its work continues to be available as open source on GitHub.

Among its various initiatives, one in particular offers valuable insights: the Eligibility APIs Initiative.

Distributing Policy as Code
In the United States, major social programs such as SNAP and Medicaid are structured so that the federal government defines the core rules, while states are responsible for implementation.

Policy changes are typically distributed as documents or PDFs. Each state must interpret these changes and manually reflect them in its own systems. This process is inefficient and can lead to delays and implementation errors.

18F explored an approach along the following lines: representing eligibility rules in code and providing them as an API, so that states could reuse the logic in their own systems.

Launched in 2017, the initiative aimed to provide federal eligibility logic as source code via APIs, enabling states to incorporate it directly into their systems. It was also an experimental effort to improve the readability and portability of policy 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 Challenge was not Technology
Project records indicate that building the API was not the primary challenge.
A key challenge emerged from the states, with concerns about relying on a federal API for core eligibility decisions. In a decentralized system where states bear ultimate responsibility, there was no clear institutional answer to this issue.

The Shadow Software
This structural gap leads to so-called shadow software. The states and civic tech are having to interpret policy into code. As a result:

• Multiple unofficial implementations of the same policy emerge
• Interpretations diverge
• Implementation costs are repeatedly incurred

A Pivot to prescreeners
As the team was exploring possible solutions, the COVID-19 pandemic began. Government agencies became consumed with daily crisis response, losing the capacity to cooperate on experiments involving high-stakes system migration risks.

The project consequently shifted direction.
Instead of providing a centralized API for official decisions, the team shifted its focus to developing prescreeners—tools that allow individuals to estimate their own eligibility.
In other words, the focus moved from delivering authoritative decisions to providing reference information, reducing institutional risk.

Implementation Beyond Government
By releasing eligibility logic as open-source code, 18F enabled reuse beyond government.

NPOs and civic tech began building on it. For example, the Virginia Poverty Law Center (VPLC) adopted the code to help prevent benefit loss. In one case, two civic tech engineers developed a tool covering all 50 states and some territories, now supporting multiple benefit programs.

These outcomes exceeded the expectations of the original project team.

Not Incentives, but Responsibility
Mike Gintz, one of the core members of 18F at the time, noted that rather than attempting to offset adoption costs and risks through incentives, it is more effective to minimize the burden of adoption and enable users to experience immediate, clear value.

At the same time, he also observed that, given the nature of eligibility APIs, it was inherently difficult to take such an approach. This highlights the core challenge of the project.

Unresolved questions
The 18F Eligibility APIs initiative concluded in 2020, leaving three key questions:

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?

Lessons Learned from This Case
This endeavor by 18F was not a failure.
Its records of trial and error clearly demonstrate even today that the essence of digital transformation is rarely just about implementing technology. It is about how we design “responsibility” in projects involving multiple stakeholders.

References
English titles of Japanese sources are informal translations by the author.

1. 18F Eligibility APIs 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