Why Canopy?

Georgia’s eligibility and enrollment functions are administered by the Georgia Department of Human Services (DHS) under interagency agreements with the Department of Community Health (DCH), the Department of Public Health (DPH), and the Department of Early Care and Learning (DECAL). DHS caseworkers make eligibility determinations for Medicaid, CHIP, SNAP, TANF, WIC, and the Child Care Assistance Program (CAPS) — across programs that belong, legally, to four different state agencies.

The system DHS uses to do this — Georgia Gateway — was designed and built in 2017 by a single vendor and has been operated, maintained, and extended by that same vendor ever since. It is inflexible, expensive to modify, and architecturally unsuited to the modular, interoperable future that federal Medicaid IT standards now require. The cost of layering additional functionality onto its underlying architecture has become prohibitive.

More fundamentally, the conventional integrated eligibility model — one platform, one vendor, shared data — cannot simultaneously satisfy the legal data use requirements of all the programs it serves. Federal data sources carry statutory restrictions that require program-level isolation. An architecture designed around shared data is an architecture in permanent tension with the law.

Canopy exists to do better: to build a system that is legally correct by design, agency-controlled, open source, and built to last.

Canopy is an open-source integrated eligibility system built by Georgia DHS, licensed under the GNU Affero General Public License version 3 (AGPLv3).

It is the companion system to CRAIG — DHS’s open-source CCWIS platform for child welfare case management — and shares CRAIG’s foundational architecture: Rust, Axum, Keycloak, PostgreSQL, RabbitMQ, and a shared-rules-engine pattern with declarative eligibility logic expressed as versioned ruleset files.

Canopy administers:

The original conception of Canopy — before design work began in earnest — assumed a conventional integrated eligibility architecture: one system, shared data model, programs as modules within a single platform. This is the model Georgia Gateway uses. It is also, essentially, the model that the State of Georgia currently proposes to replace Gateway with.

The design team’s analysis of federal data use requirements produced an insight that changed the architecture fundamentally.

Each federal data source available to eligibility systems carries statutory restrictions on authorized use. IRS Federal Tax Information, governed by IRC §6103 and audited under IRS Publication 1075, may be used for TANF eligibility but not SNAP. SSA SOLQ/BINDEX data is shared under a Computer Matching Agreement that specifies authorized programs. USDA IEVS data is authorized for SNAP administration under 7 USC §2025(e) and explicitly prohibited from use for other programs. Medicaid data carries HIPAA’s minimum necessary standard.

These restrictions cannot be satisfied by database access controls alone. A single database administrator with superuser access can, by definition, access all tables. IRS Publication 1075 requires that FTI access be logged at the individual access level, with audit logs maintained independently and available for IRS on-site inspection. A shared schema — even with row-level security, even with column-level encryption — cannot satisfy Pub 1075 without subjecting the entire shared system to IRS audit authority.

The implication was clear: each program must be an independent service with its own database. Not for architectural elegance. Not for modularity’s sake. Because the law requires it.

Once the design team accepted program service isolation as a legal constraint, the rest of the architecture followed:

If program services are isolated, what does the eligibility orchestrator communicate with them? It cannot query their databases. It can only ask them questions and receive answers. The answer to "is this household eligible for SNAP?" is a determination — a signed, tamper-evident object that records the outcome without exposing the data that produced it.

If program services return determinations rather than data, the eligibility orchestrator is not the brain of the system — it is the coordinator. Each program service is a black box: it receives an application context, applies its rules, queries its legally authorized data sources, and returns a signed determination. The orchestrator assembles determinations across programs, applies the federal eligibility hierarchy, and presents a combined result to the applicant.

This pattern — isolated program services communicating via signed determinations — is architecturally superior to the integrated model for reasons that extend well beyond legal compliance:

The integrated eligibility model treats integration as shared data. Canopy treats integration as shared outcomes.

Canopy is AGPLv3 for the same reason CRAIG is AGPLv3: the license is a competitive moat against proprietary exploitation of publicly funded software.

Under the AGPLv3, any organization that deploys Canopy — including a systems integrator building a product on top of it — must release their modifications under the same license. A vendor cannot fork Canopy, add proprietary modifications, and sell it back to states as a closed product. The modifications must be public.

This matters because the IES vendor market operates exactly this way today. States pay hundreds of millions of dollars for systems built partly on open standards and prior public investment, then find themselves locked in to the vendor who owns the proprietary layer. The AGPLv3 prevents this.

At the same time, the license does not prevent commercial participation:

What an integrator may not do is take Canopy’s source code, modify it, and deploy it as a proprietary product. The public investment that produced Canopy remains public.

Georgia DHS is Georgia’s eligibility and enrollment agency. DHS caseworkers make eligibility determinations. DHS staff manage caseloads. DHS supervisors ensure timeliness and accuracy. DHS absorbs the operational consequences of every system design decision made about the eligibility system.

It follows that DHS should lead the eligibility modernization with this prototype — not as a subordinate participant in another agency’s technology program, but as the agency of record for eligibility and enrollment. Canopy is the expression of that leadership: a system designed by the agency that lives with it, for the applicants it serves.

Canopy is designed for:

Canopy and CRAIG are companion systems built on the same architectural foundation.

CRAIG handles child welfare case management — intake, investigation, placement, ICPC, financial claiming, AFCARS/NCANDS reporting — for DFCS.

Canopy handles eligibility and enrollment — application intake, determination, enrollment, renewal, notices, federal reporting — for the Office of Family Independence and its partner agencies.

They share infrastructure patterns (Axum, Keycloak, PostgreSQL, RabbitMQ, zen-engine), coding conventions, deployment tooling, and licensing. They do not share databases or domain models — child welfare case data and eligibility data are distinct domains with distinct federal requirements.

Together they represent Georgia DHS’s long-term strategy: a state-owned, open-source human services technology stack that eliminates vendor lock-in, satisfies federal compliance requirements by design, and can be offered to other states as a public good rather than a proprietary product.