ClaimLayer — an AI deployment case study by Akash Dixit

90-second reviewer path

Judge the work in three steps

No setup, no keys — the demo is the real app on synthetic data.

1 · Try a prepared decision

Open a claim in the demo and click Complete action. You'll see a dry-run of exactly what completing will do, with a required decision rationale, before anything commits.

Launch the demo ↗

2 · Inspect a model call

In the demo's Agents tab, open any decision: its inputs, output, confidence, tokens, latency, and the guardrails it tripped — every Claude call is on the record.

Open the demo → Agents ↗

3 · Read the proof

The architecture writeup, a guardrail enforced in code (no deny path), and the live-model eval gate that replays 13 golden documents through the real classifier in CI.

Architecture ↗ · guardrail ↗ · eval gate ↗

About this case study

For hiring teams

ClaimLayer is a public case study in deploying AI agents into a regulated, deadline-driven insurance workflow. If you're hiring for AI deployment, forward-deployed engineering, or applied-AI roles, this is a working sample of that job: domain requirements translated into agent boundaries, guardrails enforced in code, model behavior eval-gated in CI, every call audited — shipped end to end.

🏛️

Regulated workflow design

Designed regulated AI workflows for California workers' compensation claims — statutory deadlines, notices, benefits math, and audit obligations included.

🤝

Agent boundaries

Defined where the model stops: AI prepares the work; licensed humans make the consequential decisions — compensability, benefits, reserves, settlement.

🧪

Evals & live-model CI

A CI gate replays 13 golden claim documents through the pipeline with real Claude calls — classification, claim matching, and action routing asserted on every run. A live run caught the model over-applying a signal; the fix ships as deterministic code, pinned by tests.

🧭

Ownership of the hard calls

Owned the domain model, architecture, agent boundaries, guardrails, eval design, acceptance criteria, and review. Claude Code accelerated the implementation; the judgment about where AI belongs is the work on display.

🧱

Full-stack build

Built a full-stack demo on synthetic claims with statutory deadline logic, document intake, audit logs, and integration scaffolding.

🔍

Review-driven hardening

Hardened the project through review passes covering auth, migrations, stale approvals, idempotency, and public-copy truthfulness.

▶ Watch the demo View source ↗ Read architecture ↗

The problem & the design thesis

Execution, not prediction

Workers' comp claims are document-heavy, deadline-driven, and legally constrained: the work is timing, notices, reserves, human judgment, auditability, and defensible execution. Most AI in this space scores risk and stops. ClaimLayer's thesis: AI prepares the work, surfaces deadlines, drafts actions, and explains its rationale — licensed humans remain responsible for every compensability, benefit, reserve, and settlement decision — built around the assumption that a wrong automated decision has legal consequences.

⚙️

Agents that do the work

Every incoming document ingested, summarized, and reviewed in the context of its claim; compensability analyses drafted; treatment requests evaluated against MTUS; Medicare interests screened — before the adjuster opens the file.

🛡️

Guardrails in code, not prompts

The model physically cannot deny treatment, move a statutory deadline, write a reserve, or invent a statutory value. Hard limits live in the service layer, where no prompt injection can reach them.

🔌

A layer, not a replacement

Pluggable adapters sit on top of your retained system of record — ingesting claims, pushing diaries, documents, and notices back. No migration project required.

Before — react to paperwork

Medical reports pile into an inbox · work status reports wait to be read · legal documents get filed by hand · the adjuster works out what each one requires · notices and diaries typed one at a time.

After — decide, then it executes

Every document ingested, summarized, and reviewed in the context of its claim · required actions surfaced to the adjuster — including reserve adjustments · the adjuster works the queue · the AI handles everything after: decision documented, letters and notices sent, diaries completed, the next ones set, FROI/SROI state-report transactions built and queued for EDI submission — all auditable.

The operating contract: as long as the adjuster works the generated action queue, statutory deadlines are computed and tracked, the required notices and state-reporting transactions are drafted and queued, and nothing falls through unread. The adjuster's job becomes the two things that need a human: impactful decisions — with everything relevant presented, summarized, and organized — and taking care of people.

Platform

Everything a regulated claims operation needs

AI Agent

Compensability analysis

Score, priority, suggested reserves, red flags, and written rationale on every new claim — presented as a plain-language decision brief with the source documents and their AI summaries one click away. Accept or deny stays a licensed-human action.

AI Agent

MTUS treatment authorization

Every RFA reviewed against California treatment guidelines. The agent can only return auto_approve or physician_review — denial doesn't exist in its vocabulary.

AI Agent

Settlement pricing & MSA screening

C&R offers priced with written rationale, gated by a deterministic Medicare-interest screen that runs before the model ever sees the file — and a settlement package that refuses to generate until the MSA document is verified on the claim.

Engine

Statutory benefits engine

TD at two-thirds AWW with the 104-week cap, PD rating and advances, waiting periods, and calendar- vs business-day deadlines per code section — version-pinned to DWC sources.

Engine

Notices, diaries & WCIS-ready FROI/SROI

Server-side PDF generation for statutory notices, penalty diaries that cannot be snoozed, and a WCIS-ready state-reporting pipeline: as the claim moves — created, benefits start, rates change, benefits suspend or resume — the matching FROI/SROI EDI transactions build and enqueue themselves, deadline-tracked and acknowledgment-reconciled. Transmission runs through the customer’s DWC trading-partner credentials; the demo simulates the submission and acknowledgment loop end to end.

Trust

AI decision audit trail

Every model call logged with its input snapshot, raw output, tokens, latency, guardrails triggered, and human-override status — queryable in the in-app Agents console.

How it works

From injury to resolution

Claim arrives

A first report of injury lands and the documents start coming — mail, fax scans, email attachments, uploads. ClaimLayer starts every statutory clock from receipt.

Prepare

Every incoming document — uploaded PDF, scanned fax, email attachment — is ingested, summarized, and reviewed in the context of the claim. The actions it requires, reserve adjustments included, surface on the adjuster's queue with rationale attached.

Decide

The adjuster works the queue: every consequential call, made with everything relevant presented, summarized, and organized. The AI recommends; the licensed human decides.

Execute & prove

The AI handles everything after the decision: documents it, sends the letters and notices, completes the diaries, sets the next ones, and builds and queues the FROI/SROI state-report transactions — every step audit-logged.

Safety architecture

Regulated AI design — the model boxed in by code

Human approval for every consequential decision, guardrails encoded in code rather than policy copy, and deterministic statutory math the model can read but never write.

No auto-deny pathway exists anywhere in the systemDenials are a licensed-human-only action by construction — the output schema doesn't include one.

Reserve changes require a licensed adjuster's approvalThe AI may suggest reserves; nothing is written to the financial system of record until an adjuster approves it.

Deterministic MSA screen gates every settlementMedicare-interest screening is never left to the model's discretion.

Statutory values are never model-generatedRating schedules, fee schedules, and caps come from version-controlled DWC publications.

Penalty diaries cannot be snoozedStatutory deadlines use the correct calendar/business-day basis per the governing code section.

Adversarially tested guardrailsThe test suite actively tries to push agents past their bounds — and asserts the guardrails hold.

Model behavior is regression-tested with real callsA CI gate replays 13 golden documents through classification → claim match → action routing; a misroute fails the build.

See it in the source: the RFA guardrail (no deny path), the live-model eval gate, and the schema-contract test. Every model call is audit-logged — input snapshot, output, guardrails triggered, human-override status — queryable in the in-app Agents console. Everything here runs on synthetic demo data: ClaimLayer is a reference implementation with integration scaffolding, not a production system filing real notices.

Working with ClaimLayer

Built around the adjuster's decision surface

One queue, one drawer, one contract — everything else in the product exists to feed it.

The adjuster

Works the queue — the AI handles everything after

Incoming documents — uploaded PDFs, scanned faxes, email attachments — are ingested, summarized, and reviewed in the context of the claim; the actions they require, reserve adjustments included, surface on the queue
Each item opens as a plain-language brief: what to decide, why, what in the claim led here — everything relevant presented, summarized, and organized, with the originals one click away
After the decision, the AI does the follow-up: documents it, sends the letters and notices, completes the diary, sets the next ones, builds and queues the FROI/SROI state-report transactions — all of it logged and auditable
What's left for the human is exactly what should be: the impactful decisions, and taking care of the people on the claim

vs. the usual claims systemLegacy systems are passive ledgers: the adjuster reads raw PDFs, recalls the code section, drafts each notice, calendars deadlines, and keys state reports by hand. Here the contract is simple — work the queue and the deadlines are computed, the notices drafted, the state-reporting transactions built, queued, and reconciled.

The decision surface

What the adjuster actually touches

The queue — ranked prepared actions with statutory deadlines computed
The drawer — decision brief, source documents with AI summaries, benefits, reserves worksheet, related claims, diaries
The audit trail — every model call, guardrail, and human override, queryable
Integrations — adapters over the retained system of record; nothing migrates

scope noteWorker and employer self-service surfaces exist in the application; the product wedge — and this site — is the adjuster decision surface.

Every behavior described above is implemented and demonstrated in the interactive demo, on synthetic data.

Screenshots

The product, as it actually runs

Captured live from the application on demo data. Click any screenshot to enlarge.

Adjuster console with ranked action queue — **Adjuster console**Ranked action queue with AI priority, reserves, and deadlines

Claim file with AI compensability analysis — **The decision loop**Approve, edit, or decline — with the full aftermath shown before you commit

TD benefit periods timeline — **Benefits tracking**TD periods against the 104-week statutory cap

AI decision audit trail — **Agents console**Every model call logged — overrides, guardrails, latency

RFA treatment authorization center — **RFA center**MTUS evaluation — auto-approve or physician review only

Legacy integrations console — **Integrations**Adapters over your retained system of record

In-app architecture playbook — **Architecture view**The system documents itself — agents, guardrails, lifecycle

About the builder

Built by Akash Dixit — claims professional, AI-native builder

I'm a California workers' compensation claims professional with a decade in the field. I designed and architected ClaimLayer and own every consequential call in it — the domain model, the agent boundaries, the deterministic guardrails, the eval design, and the acceptance criteria. Claude Code, Anthropic's AI coding agent, accelerated the implementation; deciding what to build and where the model must not be trusted is the work, and it's what this project demonstrates.

My role. I defined the workflow, product requirements, agent boundaries, safety rules, statutory logic, demo dataset, acceptance criteria, and test expectations — including the eval gate that replays golden documents through the live model in CI — then reviewed the implementation, corrected architecture, hardened edge cases, and iterated from code-review feedback. Domain architect, product lead, and QA reviewer on one head count.

Domain workflow design · AI agent boundary design · Human-in-the-loop decision architecture · Model evals & CI gating · Test & acceptance criteria · Demo data & product narrative · Review-driven hardening

ClaimLayer is both an active project and a public worked example of a question I think matters: how do you get real leverage from AI agents in an environment where a wrong automated decision has legal consequences? The answer it takes: agents execute, humans decide, code enforces the boundary, and everything is logged.

The result is a concrete, reviewable artifact — prompts, guardrails, statutory math, and the full automated test suite (1,300+ tests), open for inspection on GitHub — showing how regulated AI deployment can be designed, tested, explained, and bounded in code.

BuilderAkash Dixit

Background10 yrs · CA workers' compensation

AIAnthropic Claude · 5 agents + 1 deterministic gate

StackNode / Express · React · PostgreSQL

Tests1,300+ · backend, frontend, schema contract

Evals13 golden documents · live-model CI gate

Audit trailEvery model call, queryable

StatusReference implementation · demo data

Sourcegithub.com/aksiomatixx/ClaimLayer

The ask

Review ClaimLayer as an AI deployment artifact

ClaimLayer is not a production claims administrator. It is a public, synthetic-data reference implementation showing how AI agents can be designed around regulated insurance workflows with the model bounded in code. Watch it run, read how it's built, and judge the work directly.

Evaluating ClaimLayer for a California TPA or self-insured team? There's a limited-time founding pilot →

View GitHub ↗ Read the README Read architecture ↗ ▶ Watch the demo

📬 Emailakashdixit@gmail.com

💼 LinkedInlinkedin.com/in/akash-dixit

🖱 Interactive demoLaunch it in your browser — the real application, no install, no keys. A synthetic book spanning the whole lifecycle — intake, TD payments, MMI solicitation, PD rating, litigation, settlement — with every document openable as a real PDF. Prefer a guided walkthrough? Email me and I'll set one up.

AI agents for workers' comp claims.
A licensed human at every decision.

Judge the work in three steps

1 · Try a prepared decision

2 · Inspect a model call

3 · Read the proof

For hiring teams

Regulated workflow design

Agent boundaries

Evals & live-model CI

Ownership of the hard calls

Full-stack build

Review-driven hardening

See the whole claim lifecycle, end to end

Execution, not prediction

Agents that do the work

Guardrails in code, not prompts

A layer, not a replacement

Everything a regulated claims operation needs

Compensability analysis

MTUS treatment authorization

Settlement pricing & MSA screening

Statutory benefits engine

Notices, diaries & WCIS-ready FROI/SROI

AI decision audit trail

From injury to resolution

Claim arrives

Prepare

Decide

Execute & prove

Regulated AI design — the model boxed in by code

Built around the adjuster's decision surface

Works the queue — the AI handles everything after

What the adjuster actually touches

The product, as it actually runs

Built by Akash Dixit — claims professional, AI-native builder

Review ClaimLayer as an AI deployment artifact