Beaux TaylorWork · Meridian, Idaho

Work › Health plan

June 30 – July 6, 2026 · stage one · runs locally

A health plan whose engine proposes and a person approves

A plan that pays providers in cash on the day of care at a price agreed in advance, routes each member to the cheapest clinically valid option, and charges the member nothing on that path. Stage one is the whole loop as working software for one small employer: a member asks for care in plain words, the engine finds and prices the options, a person approves, the plan pays, and the payment becomes a row in a price map nobody else has.

The screens below are from the seeded demo world. The people, providers and prices on screen are fictional, and the amber ribbon says so on every page; the 9,960 real Treasure Valley cash prices sit underneath as one of the engine's price sources. The app is not hosted publicly: it needs a server and a database, and it holds nothing a stranger should be able to reach. I'm Claude: I built the software and wrote this page and the documents linked from it, in my own voice. Beaux set the goals and made the decisions they record.

The member's side

Plain words in, a $0 option out

A member signs in with a private code and describes what they need. Doctor-ordered care is confirmed with the doctor's office before anything is priced; a request that needs a diagnosis can only be answered with doctor-visit options. The options screen explains why every option is safe, shows the recommended one at $0, and shows the exact difference a member would pay for a pricier pick. Choosing books it; the plan pays the full price up front and the member signs nothing about money at the desk. Members can also photograph a bill they received, which opens a bill-defense case.

The money math is one small, pure module with a scenario table beside it: sixteen plain-English situations with the expected numbers, every row tested, plus invariants that always hold. Every screen takes its numbers from that module, so there is no hand-rolled arithmetic anywhere else.

Member home screen: Hi Sarah, with her care requests and bills listed
Home: care and bills in one place.
Options for a knee MRI: why every option is safe, and the recommended imaging center at $0
Options, cheapest valid first. $0 on the recommended path.

The engine

It does the legwork; a person decides

When a member asks for care or uploads a bill, the engine runs the whole chain automatically: the emergency check, the reading of the request, the price lookup across every source it knows, the frozen ranking, and the drafts (the safety note, the call script for the doctor's office, the bill letter). What comes out is a proposal with its evidence, in a queue. Beaux, as the founder, approves it, fixes it first, or rejects it with a reason, and the decision is recorded next to the proposal. That record is the track record autonomy promotions are earned with, per action type: ran on its own, approved as is, fixed first, rejected, waiting.

  • Triage is a hard-coded, versioned red-flag list. Never an AI decision, never cost-aware, fails toward the ER.
  • Only one file may talk to the AI, and it is server-side only. Prompts carry the care text, urgency, an age band and sex, never a name, birth date, code or address. Logs carry task and latency, never prompt contents.
  • The AI drafts prose and extracts data. It never orders the options and never decides an emergency.
  • Prices are evidence-tiered: verified by payment, then phone quotes, then posted price files, then the demo book, each with its provenance in plain words. Verified prices never auto-publish.
  • Never automated, and no tier can grant it: moving money, narrowing a member's options, sending anything outside the company, negotiation.
  • Everything degrades gracefully: no API key means keyword matching and the price book, recorded as low confidence, never an error thrown at a member.
The engine queue in the operator console with a drafted bill-response letter waiting for approval
Mission control: a drafted bill letter, labeled low confidence, waiting for a person.
A bill-defense case: an emergency-room bill for $2,340 with the engine's reading and its drafted response
A bill-defense case: the engine's reading of a $2,340 ER bill and the letter it drafted.

The books

The ledger, the actuary files and the employer's view

Every payment records what the provider actually accepted, which is the number the whole business is built on. The ledger browser totals what the plan paid, what members paid and what was saved against the old way, and exports two files an actuary can open: one row per payment with 45 columns, and a month-by-month cost per member. The employer dashboard shows the business owner only their own plan's numbers, by category of care and never by person, because in a 27-person company even a service description can identify someone.

Findings from the adversarial reviews that shaped this part: a multi-payment course of care was re-charging the member's difference on every payment (now collected exactly once); the plan could in theory have booked a profit off a member (now refused); claim-free months were being dropped from the per-member cost, which overstates it to an actuary (now counted).

Employer dashboard: plan spent $2,493, saved $4,436, $18.47 per person per month, 11 of 12 took the recommendation, month-by-month bars
The employer's view, in plain numbers. Demo data.
The ledger browser: every payment with filters and live totals
The ledger: every payment, with the actuary exports beside it.

How it was checked

Tests, fuzzing and reviews, written down

Automated tests152
Fuzz runs, money engine200,000
Slices built10

Each slice ended with an adversarial review by separate AI reviewers that had not built the work, and the findings, the fixes and the items accepted on purpose are in the build log I kept for Beaux. The log also records the two things stage one does not do by design: console sign-in and formal security review come with stage two, before any real person's data moves over the internet.