The decision
Is this member eligible for this benefit on this date, and what is their cost share?
Health plans and benefits
One eligibility answer, with the reason attached
Encode plan rules once and get the same determination every time, whether the question comes from a portal, a call center screen, or a batch file. Every answer carries the reason, and every plan year keeps its own version of the logic.
How it runs on AI Rule Engine
The question arrives
A portal, a call center screen, a claims process, or a nightly batch asks the same endpoint the same question and gets the same answer.
Plan rules evaluate as written
Enrollment status, effective and termination dates, waiting periods, service categories, network status, accumulators, and dependent rules run as explicit conditions authored from the plan document.
The engine works backwards from the answer
Ask for eligibility and cost share and only the rules that can establish those answers are evaluated. Nothing irrelevant to the question runs.
A determination comes back with its reason
Eligible, not eligible, or needs review, with the specific plan provision that produced it rather than a bare code.
Unanswerable questions say so
When no rule can establish the answer, you get a proof tree showing what was missing instead of a confident wrong answer.
What the auditor sees
Most automation records that a decision happened. This records why it happened, on logic you can prove was in force at the time.
The provision that decided it
The trace names the rules that fired and the values they matched, so a determination points back at the plan language it came from.
Plan year isolation
Each plan year is a published version. A determination for a service date in a prior year is explained by that year logic, not by the current one.
Why an answer is missing
Goal-driven evaluation produces a proof tree. When eligibility cannot be established, the tree shows which fact was absent, which is the difference between a real answer and a guess.
Tested before it goes live
Saved test cases run against the ruleset on every change, and a release can be gated on them passing. A new plan year is validated against known members before anyone relies on it.
Change history that holds up
Every edit to plan logic is on an append-only audit trail with the actor and address, retained per your plan and exportable.
Where the human stays
Determinations that fall outside the encoded rules route to a benefits analyst rather than defaulting either way. The analyst sees which conditions matched and which did not, answers the open question, and the run continues with their response recorded as part of the determination.
Where AI is used, and where it is not
The boundary is enforced by how the workflow is built, not by a policy document. AI turns text into facts. Rules you wrote decide what those facts mean.
AI is asked to
- Drafting a first pass of rules from a plan document, for a human to review and correct
- Turning a stored trace into a plain-language explanation for a member letter
- Classifying free-text service descriptions into benefit categories
AI is never asked to
- Determining eligibility
- Calculating cost share or applying an accumulator
- Interpreting plan language at run time
- Anything that appears in a determination sent to a member
What changes
One answer everywhere
Portal, call center, and claims all call the same rules, so the plan gives one answer regardless of who is asking.
Appeals answered from the record
The determination, the version, and the reasoning are already stored, so responding to an appeal is a lookup rather than an investigation.
New plan years without new code
A plan year is authored, tested against saved cases, and published. Adding a client does not mean adding a branch.
Fewer avoidable escalations
Cases that genuinely need a person are routed as such, and cases that do not stop consuming analyst time.
The objections you are about to raise
“Our administration system already does eligibility.”
It does, in code that only engineering can read and change. This is the same determination in logic an analyst can author, test, and version per plan year, called by your administration system rather than replacing it.
“Plan rules are too complicated for a rules engine.”
They are complicated in exactly the way a real inference engine handles: conclusions that depend on other conclusions. Rules re-fire as facts change, and when a fact is withdrawn, everything derived from it withdraws too rather than lingering.
“We cannot have AI deciding member benefits.”
It does not. AI helps you write and explain rules. The determination is made by rules a person authored and approved, and the trace shows which ones.
“Who supports this if something breaks at 2am?”
Premium Support adds business-hours coverage with a same-business-day P1 target and a named technical contact. We will not claim 24/7 that we cannot staff. On a dedicated deployment the platform is in your subscription, with your own monitoring around it.
Frequently asked questions
Can we author rules directly from the plan document?
The AI template generator can draft a ruleset from a description or document as a starting point. Treat it as a first draft: it is reviewed, corrected, tested, and approved before it can be published.
How do we keep prior plan years intact?
Each publish is a version, and runs are pinned to the version that produced them. Prior years remain readable and re-runnable.
Can this answer in real time for a portal?
Yes. The synchronous endpoint returns the determination inside the caller request. Goal-driven evaluation also means only the rules needed for the question are evaluated.
What happens when a member disputes a determination?
You open the run, read the trace, and see the rules and values that produced it, on the version in force for that service date.
Related decisions
Bring us one decision you make by hand
Pick the decision that costs your team the most time and the most argument. In one working session we will model it, run it against your own examples, and show you the trace it produces. If it is not a fit, we will say so.