The programs don't talk to each other. We're building the layer that does.

Government benefit programs weren't built to interoperate. Each one has its own eligibility rules, its own application, and — in almost every case — no open data or API a screening tool can query directly. Efforts like NYC's ACCESS-NYC rules engine, PolicyEngine, and OpenFisca have each proven that eligibility logic can be modeled as code. What none of them share is a common intake: every project re-asks the same questions about a person's life, then answers them against just its own program.

Overlapping eligibility, non-overlapping paperwork

Someone who qualifies for SNAP is often already close to qualifying for Medicaid, EITC, or LIHEAP — the income thresholds overlap far more than the applications do. Each program still asks for its own paperwork, on its own portal, on its own timeline. The red tape isn't incidental to the fragmentation — it's a direct structural byproduct of programs that were never designed to talk to each other, or to a shared front door.

Decoupling intake from eligibility

OpenHand's bet is that the two halves of this problem don't need to stay coupled: understanding what a person's situation actually is, and deciding whether a specific program's rule applies to that situation. Separate those, and a single conversation can be evaluated against as many programs' rules as have been modeled — without asking that person anything new for each one.

Where this stands today

Today, that means three programs: SNAP, Medicaid/CHIP, and EITC. The point of this page isn't that OpenHand already covers everything — it's that the architecture is built to extend. Adding a fourth program means modeling that program's rules, not rebuilding the intake.

The engine is built to extend. If you work with eligibility rules for a program not covered yet — or want to help model one — the repo is where that happens.