pitch.eobs.claims
An EOB is not a bill. It is data your agent can read.
The Explanation of Benefits as a typed schema — free and keyless today. The parse surface over it is roadmap, and labeled that way on every page.
↓ scroll · arrow keys
After a provider bills a health plan, the plan processes the claim and reports the outcome twice: the member gets the Explanation of Benefits — service line by service line, billed against allowed, plan paid against patient responsibility — and the provider gets the same outcome in machine form, the X12 835 electronic remittance advice. One processing outcome, two formats. That is the whole thesis in one sentence: under the letterhead, the EOB is already structured data.
The first thing the document says about itself is what it is not: this is not a bill. Any actual bill comes from the provider, and the EOB is the instrument to check that bill against — the plan's allowed amount is the negotiated contract number, not the sticker number, and the gap between billed and allowed is the first thing worth reading on every line.
The EOB is a defined, federally documented consumer instrument: CMS publishes its own guide, "How to read an explanation of benefits," under its medical-bill-rights materials.
Every reduction or non-payment on an EOB carries a code from a published, maintained industry code set: X12's Claim Adjustment Reason Codes (with the companion remark-code set) — e.g. CO-45 for a charge over the fee schedule, CO-97 for a service bundled into another. The codes are data, not prose — which is what makes "explain" a function instead of a phone call.
The buyer here is not the member holding the statement — it is the developer building what the member (or the provider) actually uses: patient-billing and benefits-navigation products, billing-integrity checks, advocacy and appeal workflows. For that builder the EOB is a daily irritation with a precise shape: the claim outcome was born structured, but the member-side copy ships as prose on letterhead, formatted differently by every plan.
So each product team rebuilds the same private parser, breaks it on the next template change, and re-derives a data structure the plan's own systems already held. Meanwhile the two numbers that drive every downstream action — what was allowed, and what the patient may owe — plus the appeal deadline, sit unreadable to code inside a PDF.
What serves today is the reference layer, and each piece carries its own evidence: the door, the machine-readable text, and the spec. Serving is a liveness fact about pages, not a claim that anything is callable — the same pages say so themselves.
eobs.claims serves: the reference page defines the EOB in plain language, renders a clearly labeled fictional specimen, and states on the page that it is early access with no live parser or API behind it yet.
/llms.txt serves, free and keyless: the door in plain text for agents and answer engines — the definition, the schema, and the honest status of every surface, including which verbs are roadmap.
/openapi.json serves: an OpenAPI 3.1 stub whose Eob schema — typed fields from payer to appeal_window — is real reference content, and in which every operation is tagged x-status: roadmap. The spec is a served document; nothing in it is callable, and it says so in its own description.
The surface being built over the schema is stated as intent, because that is what it is: parse (an EOB PDF or 835 remittance in, typed service lines out), reconcile (the EOB against the provider's bill, line by line, flagging anything billed beyond the allowed amounts), explain (a remark code into a plain-language sentence a member can act on), and draft (an appeal letter for an uncovered line, the plan's deadline attached, for a human to review and send).
None of these verbs decides a claim. The plan processes and decides the claim; this surface reads the paperwork that decision produces. Drafts are drafts — a human reviews and sends. Nothing on this door is medical, legal, or billing advice.
No verb is callable yet: there is no live parser, no live API, and the /mcp endpoint (planned tools: parse_eob, get_eob_schema, explain_remark_code) is roadmap. Each verb posts as fact the day the spec's own status tag flips — documented before it exists, so nobody mistakes a plan for a product.
A schema can be published in the open; a document cannot be casually accepted. A real EOB names a person, their member ID, and their care — so the callable surface is gated behind more than engineering, and the gates are stated rather than implied.
Custody before parsing: where a submitted document lives, who can read it, retention, and the health-data compliance posture — including business-associate terms where the customer's status requires them — ship with the first callable operation, and no document moves before they exist.
Pricing is unposted because it is unpriced: callable operations will meter flat per document — never a percentage of any amount the document reports, never contingent on claim outcome — and the working fee posts here the moment real documents price it: ▮▮▮posts when first live fee data resolves. The free-tier promise is already posted: the reference, the schema, and /llms.txt stay free and keyless.
eobs.claims is an artifact door of the api.insure estate, and the estate serves two registers with one typed-schema discipline: health revenue-cycle documents like the EOB on this door, and P&C claims documents on the sibling doors — the loss run at lossruns.claims, the loss-notice fields at acords.co. Same discipline, different vocabulary, separated by rule rather than habit — because blurring a health statement into a P&C claims workflow is how paperwork products quietly say wrong things.
The register boundary is also the regulatory boundary, stated plainly: reading, reconciling, and explaining an EOB is open document work — no reserved act, no license gate. The estate's P&C claims loop, which does contain reserved acts, lives behind the reserved line at api.insure with its own licensed machinery. This door never inherits that machinery and never pretends to need it.
The P&C sibling artifact door serves: lossruns.claims publishes the loss run as a typed schema in the property-and-casualty register.
The second P&C sibling serves: acords.co publishes loss-notice data fields under the same typed-document discipline.
The estate's substrate serves: api.insure answers today with its capability contract in the open and says candidly, on the page, that it is early access.
The motion is B2D: the RCM and benefits-tooling developer, reached where they already evaluate — the schema, the spec, the plain-text door — because for this ICP the schema is the sales call. Secondary motion is B2A: the same surfaces read by agents and answer engines directly, with the MCP endpoint on the roadmap. No paid or scaled acquisition pre-launch; the funnel is an early-access email and a design conversation about formats.
Pre-launch, stated as pre-launch. The reference layer is live and keyless; every callable verb is roadmap; the specimen on the door is fictional and labeled; and the two load-bearing gates — custody terms and the first callable operation — are worn openly on the slides above rather than buried in fine print.
This deck describes a designed surface over a live reference — deliberately, in the open. The record precedes the parser; the schema is the spec the parser is built to, and the ambers here flip one by one as the surface ships.
Founding team spans the estate's demand rails, the substrate, and the regulated edge; a third co-founder currently leads AI at a public insurtech and joins at close.
The reference is live at eobs.claims — the schema is free and keyless today.
If this was forwarded to you: eobs.claims is the reference for the Explanation of Benefits as typed data — a free, keyless schema that is live today, with the parse surface over it labeled roadmap until it is real. Every factual claim above carries its own state and evidence. If you build on health revenue-cycle documents, the early-access door is the ask. If you know who does: forward this.