Agencies apply published rules to whole populations, and every person affected is entitled to know why. Helixor applies those rules the same way for everyone, records which criteria decided each case, and can run entirely on site when data isn't allowed to leave.
These are examples, not a complete list. A decision usually fits when it has written criteria, pulls from several systems, happens often, and someone may later ask why it went the way it did. Pick one to jump to it.
A benefits application brings household composition, income from several sources, assets, residency, work history and prior benefit records, often pulled from different agency systems. Caseworkers apply eligibility rules from a policy manual that changes with every legislative session. Similar households can get different answers from different offices.
The published criteria become a pack, and each rule change becomes a new version with an effective date. Every application comes back eligible, ineligible, or refer to a caseworker, with the criteria that decided it. Appeals, overrides and corrections are captured as outcomes, so the next version can be checked against real cases before it goes live.
{
"case_id": "BN-2026-448120",
"receipt": "hx_proof_7c20e1f94ab3d65c08e2f1a9",
"pack": "state.snap_eligibility 2026-07-01",
"action": "ineligible",
"rules": ["ELIG-GROSS-INCOME-130"],
"input_sha256": "b04f...19d3",
"remedy": ["gross_monthly_income <= 2888 for household_size 3"],
"logged_at": "2026-09-28T11:15:48Z"
}When an application is refused, the letter often cites a policy section and little else. People appeal because they can't tell what went wrong, and staff spend time reconstructing a decision someone else made.
Because the decision is a set of fired rules, the explanation is already there: which criterion failed, by how much, and what would change the outcome. That goes straight into the notice in plain language. Fewer people appeal just to find out why.
Inspectorates decide which restaurants, sites or facilities to visit based on risk scores, past findings, complaints, statutory frequencies and inspector availability. Planning happens in spreadsheets, travel eats the day, and high-risk sites can slip through when someone is out.
Statutory frequencies, risk rules, conflicts and working hours go into the pack. The solver builds each inspector's schedule and route for the period, putting the riskiest sites first and cutting travel. When someone is out, it repairs the plan instead of starting over. Findings and missed deadlines feed the next version of the risk rules. The pack holds the hard rules and the goal. The solver searches for the best plan that satisfies every hard rule, working from the same typed state the decision core uses. If no plan can satisfy them all, it tells you so instead of quietly breaking one. The solvers are built for GPUs, and that's where large plans solve fastest. Solvers are in Preview today.
| Decision | What Helixor decides |
|---|---|
| Case triage | Assign priority and team, with reasoning for unclear cases. |
| Grant application screening | Check completeness and basic eligibility before reviewers score. |
| Workload | Pattern |
|---|---|
| Sites without internet access | Air-gapped, with the core deployed locally as in patterns 1, 2 or 3 |
| Pack and license delivery | Cross the boundary once, compile on site, no remote calls |
| Reasoning and learning | Hybrid escalation for approved data only |
Build a golden set of worked examples from published guidance with the expected outcome for each. Every new pack version has to reproduce them before it goes live. Keep the receipt and pack version on every decision for your retention schedule.
Go deeper on helixor.dev: Industry guide ↗ • Deployment patterns ↗ • Core concepts ↗ • Receipts ↗
Bring a written policy and a handful of past cases. We'll turn it into a pack and run it next to your current process so you can compare.