Automate insurance eligibility enquiries in openIMIS
The same compiled browser workflow - insuree number in, coverage answer out - run six fresh times against openIMIS 25.10 with synthetic data. When read-only SQL confirmed the policy state, all three runs returned VERIFIED. When SQL returned Ineligible where the declared effect required Eligible, all three runs halted instead of trusting the screen.
This workflow runs today, end to end, against the named open-source reference application in the openadapt-flow repository. The steps below are the real demonstrated steps and the verification is the real oracle.
Published results — exactly as measured
- Trials
- 6
- Verified / expected halts
- 3 / 3
- Silent incorrect successes
- 0
- Model calls per run
- 0
- Duration
- 19.7 s mean
published mean runtime across the six fresh Standard-profile runs. Source: openIMIS Standard execution evidence campaign (live demo deep-dive). Measured on compiler 1.23.0; evidence manifest d163375358f1 referenced by the live demo.
Footage and evidence media
Runs on
openIMIS 25.10, browser surface, synthetic sample data bound to localhost. openIMIS exposes a GraphQL API that a real deployment should prefer; this demonstration stands in for commercial eligibility portals that expose no API.
The demonstrated steps
- 1Click the Insuree enquiry control
- 2Type the insuree number - parameterized per replay
- 3Press Enter to resolve the policyholder
- 4Search and select the demonstrated service option
- 5Read the eligibility result and confirm it against an independent read-only SQL query of the policy state
Parameters: insurance_no · service_code · as_of_date — recorded values are the defaults; every replay can override them.
How the outcome is verified
A Tier 1 independent system interface: the campaign queried openIMIS through a separate read-only SQL connection, so the browser that performed the task could not certify its own result. The workflow required at least Tier 3 evidence and received the stronger Tier 1 proof. On expired policies the SQL result contradicted the declared effect and every run halted with no blind retry of the consequential action.
- read-only SQL confirmation of policy, product, service, and effective-date state (Tier 1)
- identity gates on three consequential actions
- declared-effect check with explicit halt path
Questions about this template
Why did half the trials end in HALTED?
By design. Three trials ran against an expired policy: read-only SQL returned Ineligible where the declared effect required Eligible, so OpenAdapt refused the contradictory result, did not accept the browser screen as success, and did not retry the consequential action blindly. Zero over-halts were observed across the campaign.
Source: Expired-policy trial results
What evidence tier verified the eligible runs?
Tier 1, an independent system interface: a separate read-only SQL connection confirmed the policy, product, service, and effective-date state. The workflow only required Tier 3; it received the stronger proof.
Source: Evidence classification notes
How long does one enquiry take?
Mean runtime across the six published runs was 19.7 seconds; individual verified runs ranged from 12.7 to 20.3 seconds as published in the trial list.
Source: Campaign summary
Try it from the command line
The compiler and runtime are open source and MIT licensed. Healthy runs are local and make no model calls.
pip install 'openadapt[browser]'Installs the OpenAdapt launcher, compiler, and browser capability.
openadapt flow record --url http://localhost:8000/ --out rec && openadapt flow compile rec --out bundle --name eligibility-enquiryDemonstrate or reuse the recording, compile it into a deterministic bundle, then replay locally.
Put this workflow into production
Bring your version of this workflow and the record that proves its outcome. We'll map the deployment, verification, shadow run, and supervised rollout.