Ting | Devpost

Inspiration

Every October, employees face the same three questions about dental work: What will I owe? When should I do it? Which plan should I pick next year? The answers are buried in benefits summaries full of terms like coinsurance, frequency limits and annual maximums. Most people guess. They do expensive work in December when their annual maximum is almost gone, or leave covered cleanings and FSA dollars unused when the year resets.

The codeLinc challenge asked for an AI tool to simplify dental benefits. We didn't want another chatbot that sounds confident about numbers it made up. We wanted a tool that gives decisions, where every dollar is calculated by tested code and the AI only explains it.

What it does

Ting answers the three questions for one person's real plan and real treatment plan.

What will I owe? Describe the work, say it aloud, or snap a photo of the dentist's treatment plan. Ting reads it into procedures, asking only questions whose answers change the bill. It then shows a step-by-step breakdown: dentist's fee → network discount → deductible → coinsurance → annual maximum → what you pay. Each step comes with a plain-English sentence that's checked against the engine's numbers. The amount the plan pays is proved against the plan's rules with Automated Reasoning. One toggle compares in-network and out-of-network costs, including the balance bill most people don't expect.

When should I do it? Ting tries every way to schedule the work across plan years and offers Cheapest, Balanced and Fastest options. For example, moving crowns to January after the annual maximum resets saves [$…]. You can drag any procedure across Dec 31 and watch the cost re-price instantly. Urgent work is locked, because the dentist decides what can wait. The schedule follows plan fine print such as waiting periods, frequency limits, the rate paid for white fillings on back teeth, and MaxRewards rollover timing. A gauge tracks each year's annual maximum.

It stays current. When a claim is processed, the explanation of benefits (EOB) arrives live, updates the ledger, and is checked against Ting's estimate. If the plan paid less than expected, Ting drafts a message to the carrier. If the dentist's bill asks for more than the EOB says the member owes, Ting flags it. Year-end reminders (in the app, as calendar files, and as digest emails with no health details) say how much of the maximum and FSA are about to expire.

Which plan next year? At open enrollment, Ting compares the plan options for the coming year, recommends an FSA amount, and shows the tipping point where the bigger plan pays for itself. It sums everything up in one Enrollment Card: the plan, the FSA amount, what to do before Dec 31, what waits until January, and the expected savings.

Also built:

employer sign-in with a consent screen and delete-my-data

an employer view with aggregates only (groups under 20 hidden)

a printable summary to share with the dentist

a benefits-summary compiler that turns a plan PDF into rules

Spanish explanations

a dentist finder priced by your own costs

SmileStreak, an opt-in, rewards-only program that uses smart-toothbrush data (Oral-B over Bluetooth, or a DIY ESP32 clip) to earn credits. Your premium never goes up.

How we built it

One engine at the center. A pure TypeScript engine (no DOM or AWS imports) handles everything that involves money: processing claims in date order the way the carrier would, the plan-year optimizer, plan comparison, FSA math, and applying claims. The same code runs in the browser and in AWS Lambda, so the demo and the backend can't disagree.

"The AI translates, tested code decides."

Amazon Bedrock turns descriptions into procedure codes, fills gaps when compiling plan documents (using only verified quotes), and writes plain-language explanations, digests and appeal drafts. Every sentence that contains an amount is checked against the engine before it's shown.

Automated Reasoning proves the plan-pays amount against rules built from the benefits summary. Amazon Textract reads treatment plans and bills. A Step Functions workflow handles document ingestion, with duplicate detection and a check against hidden instructions aimed at the AI.

AWS backend in one CDK stack: API Gateway and Lambda, DynamoDB, Cognito (employer sign-in through OIDC), EventBridge for the live claims feed over WebSocket, and EventBridge Scheduler with SES for reminders and digests.

Frontend: React, Vite, Tailwind, Zustand and React Query, with zod schemas at every boundary. It also runs entirely in the browser on demo data: local versions stand in for each AWS service (tesseract.js for OCR, pdf.js, template explanations) behind the same interfaces.

Method: we wrote the spec first (docs/features.md), then built the engine with hand-calculated test cases, then the UI, then AWS. We have [~150] automated tests, a [23]-check production smoke test, and an intake accuracy scorecard.

Challenges we ran into

Keeping the AI away from the math. Language models write convincing dollar amounts that can be wrong. We had to design every AI output so the numbers come from the engine and the model only supplies the words, then verify that each sentence's numbers match before showing it.

Encoding real plan fine print. Frequency limits, waiting periods, the white-filling rule on back teeth, deductibles that reset, and rollover deposits that don't arrive until spring all change when a procedure should happen. Getting the optimizer to respect all of them, and stay fast enough to re-price on every drag, took most of our engine time. The practical limit is about 12 procedures.

Two codebases, one product. We built the engine and the frontend in parallel lanes and had to merge two apps into one that runs on the core engine end to end.

Plan documents never say everything. Our compiler treats a missing rule as a question for the user, never a default. That was harder than guessing, and more trustworthy.

Scope. Judges kept suggesting great ideas. We learned to build them behind the same engine, so new features didn't fork the logic.

Accomplishments that we're proud of

It works end to end, live on AWS. A claim event arrives on stage and the plan updates in seconds.

Every amount on screen comes from tested code, and the plan-pays amount carries a formal proof.

The intake scored 28 of 30 (93%) on our accuracy set. We published our caveat with it: we tuned the prompt once on the same set, so a held-out test is next.

Security was designed in, not bolted on:

employer sign-in
employers see only groups of 20 or more
reminder emails contain no health details
delete-my-data
uploaded documents screened for injected instructions before any model reads them

The plan-year optimizer and the drag-to-re-price timeline: you can see exactly why moving one crown saves money.

What we learned

For financial decisions, trust beats eloquence. The right split is AI for language, tested code for numbers, and proofs where the stakes are high.

Plain language is a feature you design, not a tone you add: a breakdown with one sentence per step beats a paragraph of explanation.

Benefits rules are full of timing (resets, waiting periods, deposit dates), and timing is where people lose the most money.

Building local versions of every cloud service behind one interface let us demo at any time and move to AWS without changing the UI.

What's next for Ting

Pilot: connect the carrier's real claims feed and provider directory (under a BAA), replace demo fees with the carrier's fee schedule, and run a held-out accuracy test.

Measure recovered value with one employer group: unused maximum and FSA dollars actually used before they expire.

Family optimizer: decide whose procedures go in which year across a household. Integrate with the carrier's dental app and enrollment portal, and extend the same engine to vision and life coverage.

Move the Winnow decision model to a GPU and calibrate it on dental documents.