The problem
One expired income record can trigger several document requests. One changed rule can alter a set of application checks. A coordinator needs to see what depends on that evidence, what can be requested together, and what still needs a person's judgment.
ClaimWeave is a working evidence-coordination prototype for benefits intake teams and the developers supporting them. Its central question is simple: what is the smallest useful next request, and what changes when the evidence or policy changes?
Try it in two minutes
Open the live demo: https://yasminetriguii.github.io/claimweave/
- Choose Repair & regression, then Try 120-day time shift. Six stale checks map to two synthetic collection steps. Inspect exactly which fields, programs, and freshness requirements each step supports.
- Reset the demo. Choose Policy regression bench and run the proposed $2,000 housing cap. The same 12 synthetic cases run through 36 before/after program comparisons. Three housing outcomes change; missing, expired, and withdrawn evidence remains in review.
- Download the reproducible report to inspect the fixture inputs, both policies, and every check trace.
- In Evidence workspace, withdraw housing consent. Housing exports stop while unrelated program checks continue.
What it does
Coordinate evidence across programs. A visible map connects income, residency, and enrollment evidence to three fictional programs. Every check shows its requirement, supporting records, freshness limit, and reason.
Plan a refresh once. An exact subset search finds the minimum number of collection options covering the currently missing or stale fields in the displayed four-option catalog. The example's campus statement combines income and enrollment. This is an explicit fabricated assumption, not an integration or a real agency acceptance rule. Conflicting records and unmet rules are left for human review; absent consent becomes an applicant decision before collection.
Test policy changes reproducibly. A 12-case regression bench evaluates unchanged inputs against original and proposed policy versions. Downloaded reports include the full inputs and results. These are developer-authored regression fixtures, not estimates of population impact or model accuracy.
Share only what is needed. A current-consent gate and field allowlist build minimal JSON packets. Source account numbers, street addresses, and unrelated fields are excluded. Withdrawal blocks future in-app exports; it cannot retract a previously downloaded file.
Inspiration and originality
YC's “Plaid for Government Benefits” request motivated the problem exploration. Public research showed that reusable verification, evidence graphs, and readiness tools already exist. ClaimWeave focuses on their coordination consequences: cross-program collection planning plus a reproducible policy regression workspace. It does not claim to be the first evidence tool or to replace source-verification providers.
Research notes and the closest-work comparison are in the GitHub docs folder. No competitor code or assets were copied.
How it was built
The browser UI and automated tests share a pure, dependency-free JavaScript engine. The planner exhaustively enumerates catalog subsets rather than using an opaque score. Dates are explicit inputs, making freshness and consent behavior repeatable. GitHub Actions runs the tests, validates the build, prepares the portable HTML demo, and publishes the static assets through GitHub Pages.
No account, API key, installation, or paid service is needed to try the live app. State remains in browser memory. Imports accept bounded, validated synthetic JSON.
Account backend
The source also includes a Node 24 and SQLite account backend: username/password signup and login, private saved workspaces, expiring server-side sessions, logout and other-session revocation, and revision-checked updates. The server independently recomputes consent and evidence checks before generating a saved-workspace packet. Passwords use salted scrypt; session tokens are hashed in storage. Ownership checks, exact-origin write protection, request limits, and authentication throttles are tested. The public GitHub Pages demo is static, so hosted sign-in is not yet available there. No external account providers are connected.
Challenges and verification
The difficult cases are missing information, conflicting records, expired evidence, and withdrawn consent. None should silently become a confident eligibility result. Another challenge was ensuring that the collection planner never treats a lack of consent as permission to collect more data.
The project has 41 passing automated tests, including minimum-cover behavior with and without the multi-field catalog option, uncovered fields, consent scope, expiration boundaries, conflicts, export minimization, no-op policy changes, and preserved review states. The deployed UI was checked for consent withdrawal, conflicting evidence, the refresh plan, and the policy comparison flow. These checks do not establish production security, full accessibility, or real-world impact.
Scope, contributions, and next steps
All programs, applicant records, sources, and policies are fictional. There are no live payroll or government connectors, actual eligibility decisions, identity verification, OCR, cryptographic source proofs, or runtime AI. The next step is to validate the workflow with intake coordinators and policy-system developers, then build program-specific source-acceptance rules and integration tests.
New implementation was created during the hackathon period, beginning November 8, 2026. Yasmine provided the product direction and requested the feature expansion. OpenAI Codex assisted research, implementation, interface design, tests, deployment, and documentation. No claim is made that Yasmine manually wrote all the code. The app's runtime logic is deterministic JavaScript, not a trained AI model.
