The problem
Classic adjudication leans hard on rules configuration. Benefit mapping, fee schedules, clinical edits: standing up a new plan can eat months, and the work drifts from the contracts themselves.
I sat with claims ops and plan configuration folks on that pain. AI can reason over plan language, but only if people trust it. They need confidence, exceptions, and source text. Nobody wants a black box that silently denies.
Research
- SME interviews (claims / plan ops)
- Competitive and rules-engine teardown
- Task analysis of adjudication stages
- Trust / failure-mode workshops
- Wizard-of-Oz and mock-first prototypes
Research was about trust, not model demos. With claims and plan stakeholders I mapped today’s path: where rules engines create multi-month onboarding, where operators lose the thread on exceptions, and what would make them reject an AI assist (black-box denials, missing source text, no human gate).
We treated the eight stages as real work and stress-tested UI concepts on mock pipelines before every AWS stage was live. That way we could learn the language for confidence, review queues, and document grounding without waiting on production agents.
What I owned
Product design for the Vue 3 / Quasar ops shell: pipeline, claims list and detail, review queue, agents, knowledge base, payments, and encounters. I partnered with platform engineering on the agent-first stack (Step Functions, Lambda, Bedrock / Nova Pro, RAG over plan docs).
Approach
Let people watch the pipeline, open the source, and take over when confidence is low—no silent auto-deny.
Hypothesis: if sources and human gates are obvious, ops will use the agents. Goal: high automation with no silent auto-deny, and a UI that stays stable as stubs flip to production.
- One operational path: people shouldn’t guess which screen owns the next action across pipeline, list, detail, and review.
- Trust surfaces: confidence, audit flags, and human review that never quietly finalizes high-risk outcomes.
- Document-grounded decisions: link agent output back to plan language, not opaque rule IDs alone.
- Mock-first delivery: a full local API contract so design and eng could iterate without waiting for every AWS stage to light up.


The 8-stage pipeline
Intake/Parse → Eligibility → Benefit Adjudication → Pricing → Clinical Edits → Audit → Payment → Encounter Submission. Benefit adjudication uses RAG over plan documents. Later stages can run deterministic stubs while fee schedules and CMS tables load. Operators keep the same shell either way.
Illustrative distribution from pilot batches: goal is high automation with explicit human gates, with no silent auto-deny.
Order-of-magnitude less config before first useful run
Directional comparison used with stakeholders; actuals depend on plan complexity and data quality.


Results
- A coherent ops shell for a greenfield AI claims platform.
- Reusable trust patterns: sources, review queues, no silent audit.
- Design and eng shipping in parallel via mock contracts and staged agents.
Why this still matters
In regulated claims work, people need to see where an answer came from and when a human has to step in. I still design agent products around visible sources, review queues, and no silent auto-deny—trust is the product, not the model demo.
Stack
Vue 3 · Quasar 2 · Pinia · Vite · Express mock API · AWS Step Functions · Lambda · Bedrock (Nova Pro) · DynamoDB · S3 · API Gateway
