pitch.lossruns.claims

lossruns.claims

Every renewal demands the loss run. Now it has a schema.

The carrier-issued claims history on a policy — paid, reserved, incurred — as typed data. The reference and schema are live and keyless today; everything callable is roadmap, and says so.

↓ scroll · arrow keys

The document underwriters read first

A loss run is a point-in-time report from the carrier's claims system: every claim on a policy for a given term, valued as of one stated date. It moves markets because a new carrier prices the incumbent's report, never the insured's own account of their losses — so underwriters demand it at every renewal and every market submission, usually three to five years of history per line, brokers demand it to remarket the account, and buyers demand it in diligence.

Three numbers carry the report. Paid is money the carrier actually issued. Reserved is the carrier's accounting estimate of what remains to pay on an open claim — a reserve is carrier accounting, not a promise. Incurred is paid plus reserved, and it is the figure underwriting prices on. An open claim can move all three after the valuation date, which is why the market always asks for a freshly valued run.

Getting one is a rights question with a clock on it: the carrier produces it on written request from the insured or the producer of record, and many US states set a statutory production deadline — commonly cited as ten to thirty days, varying by state. The door carries that statement with the same caveat it belongs under: confirm your state's rule before relying on a number.

Postedlossruns.claims

The door serves today: the reference page defines the document in plain language, publishes the typed schema free and keyless, renders a specimen labeled fictional data, runs the early-access capture, and states its own status in the fine print — "there is no live parser or API behind this page yet."

One document, one typed schema

This is the shape a parsed loss run resolves to, whatever carrier produced it — the reference an answer engine can quote and an agent can build against:

// components.schemas.LossRun — served in /openapi.json today
{
  "carrier": "string",         // authoritative only from the carrier that held the policy
  "insured": "string",
  "policy_number": "string",
  "line_of_business": "string", // e.g. commercial_property, general_liability, workers_comp
  "term_start": "date", "term_end": "date",
  "valuation_date": "date",    // every figure is true as of this date only
  "claims": [{
    "claim_number": "string",
    "date_of_loss": "date",    // occurrence date, not report date
    "cause_of_loss": "string", // peril code: wind_hail, water_damage, theft …
    "status": "open | closed",
    "paid": "money", "reserved": "money",
    "incurred": "money",       // derived: paid + reserved — the number underwriting prices on
    "coverage": "string"       // coverage part the figures fall under, when the carrier splits them
  }],
  "totals": "object"           // paid, reserved, incurred, claim count, open count
}
Postedlossruns.claims/openapi.json

The schema is served, not sketched: /openapi.json answers today as an OpenAPI 3.1 stub carrying components.schemas.LossRun (with LossRunClaim and LossRunTotals), and every operation in it is tagged x-status: roadmap — the spec itself says nothing is callable yet.

Why this artifact is the wedge

Every commercial renewal, remarket, and diligence pass runs on this document — from every incumbent carrier, each in its own print format, delivered as PDFs into inboxes and rekeyed by hand at every hop. It is the classic insurtech wedge, and this estate takes it on purpose, for stated reasons:

  • Universal and renewal-critical — the document is demanded on a calendar, not discovered by marketing.
  • Unstructured by incumbency — every carrier's claims system prints its own; no standard machine shape exists to point a parser at.
  • Open-tier end to end — reading, parsing, and requesting a loss run is data work; no state reserves any of it, so this door ships value ahead of any license.
  • Native ground for this estate — the loss run is claims history, and claims are what the estate's licensed machinery administers. Prior-loss history feeds the claims loop as open Packet material.

Four verbs over one document — all roadmap, labeled

The typed surface being built over the document, exactly as the door lists it:

verbwhat it doesstatus
parsea loss-run PDF or AL3 file in, the typed schema out — header, claim rows, paid / reserved / incurred, totalsroadmap
normalizemany carriers' formats into the one shape above, so histories diff cleanly across marketsroadmap
requestdraft the loss-run request letter to the carrier, with the state's production deadline attachedroadmap
watchrenewal dates on file, so the request goes out before the market asks for the runsroadmap
Pendinggate: first operation in /openapi.json callable on the domain — its x-status tag flips with it

Nothing above is callable today. The spec is served; parse is typed in it and tagged x-status: roadmap; the other three verbs are filed ROADMAP on the door's /llms.txt and enter the spec as they are typed. This claim flips posted per operation, as each starts answering.

Pendinggate: request + watch callable, and a first real renewal's requests run end-to-end through them

The retrieval arc — the full chase, run by the rail — is intent, stated as intent: request letters drafted with the statutory clock attached, renewal watch that fires them early, and the produced documents landing back through parse into typed history. It posts as fact when a real renewal has run through it, with the record in evidence.

Pendinggate: MCP endpoint callable at lossruns.claims/mcp with the planned tools

The MCP surface — parse_lossrun, get_lossrun_schema, draft_lossrun_request — is documented on the door before it exists, so nobody mistakes a plan for a product. It posts when the endpoint answers.

Where the reserved line is — and why it isn't here

No verb on this door is a reserved act. Reading a loss run, typing it, normalizing it, drafting the request the insured is entitled to make — open, data-tier work end to end; no state names a license anywhere in that path, and the door says so on the page. The acts a statute does reserve — the decision on a claim; approve or deny is a licensed adjuster's act, under their own license — live behind the reserved line at api.insure, where a claim waiting on a license is typed PENDING_ADJUSTER, never an untyped queue.

That boundary is why this door ships ahead of the cell's licensure while the license stack closes: nothing here waits on a license, and nothing here pretends to exercise one. Scale that blurs who decided is bad-faith machinery elsewhere in this estate's decks; this door stays entirely on the open side of the same line.

Postedapi.insure

The estate's demand rail serves: api.insure answers today with the open-vs-reserved capability contract stated on the page — the reserved line typed PENDING_ADJUSTER — and says candidly that it is early access.

The free tier is the discoverability

  • The reference, the schema, /llms.txt, and /openapi.json are free and keyless — no account to read anything on the door, robots allow-all. The door wants to be read, crawled, and quoted; that is the channel.
  • The parse surface, when callable, is designed to price flat per document parsed — never percent-of-premium, never percent-of-anything. Indemnity is never a fee base anywhere in this estate; here that rule is almost decorative, because the only dollars on this door are fields in someone else's document.
Postedlossruns.claims/llms.txt

The machine-readable kit serves: /llms.txt answers today in plain text — the definition, the schema, and the honest status of everything, including, in its own words, "there is no live parser or API behind this door yet."

Pendinggate: published priced surface + first live fee data

The fee shape above is design intent for a billing surface that is not live. No figure is published anywhere — page, spec, or this record — until real documents have priced it; the flat-per-document commitment posts as fact with the priced surface.

An artifact door of the api.insure estate

The door's own /llms.txt files it exactly that way. One insurance estate, entered at different grains: api.insure is the per-claim demand rail whose primary caller is an agent; gigs.claims is the supply door recruiting the licensed adjusters behind the reserved line; apis.claims is the batch surface being built for the team that arrives with a book; lossruns.claims is the artifact door — the claims-history document itself, typed. The live footer also names sibling artifact doors — acords.co and eobs.claims — whose records are not yet filed in this studio.

The long game, stated as design intent rather than fact: a book administered on the estate's rail emits its loss runs by construction — typed Claims are already the rows, so the document becomes a query instead of a chase. The artifact door is the outside-in half of that loop: it types the incumbent's documents while the rail earns the right to hold the books.

Postedgigs.claims

The cell's supply door serves: gigs.claims answers today, recruiting licensed adjusters and stating on the page that it is onboarding founding adjusters ahead of a live match queue.

How it goes to market

The motion is B2D, content-led: renewal-workflow builders, reached where they already evaluate — the schema, the semantics, the spec — because for this ICP the reference is the first meeting. The secondary reader is not human: the kit exists so agents and answer engines can quote the door verbatim, and being the shape they quote is the distribution. The only conversion on the page is the early-access capture; there is no paid or scaled acquisition.

One ICP, one motion, chosen explicitly: the builder and the document. The per-claim caller belongs to api.insure, the book-holder to apis.claims, the licensed adjuster to gigs.claims — this door cross-points rather than absorbs.

Where it stands

Postedlossruns.claims

Live today, keyless: the reference, the typed LossRun schema, the specimen labeled fictional data, /llms.txt, /openapi.json with every operation tagged roadmap, and the early-access capture. The page carries its own fine print — early access, nothing callable, statutory deadlines vary by state, nothing on the page is legal or coverage advice.

Pendinggate: entity assignment ratified — insurance-cell software side vs studio brand layer (this record's entityNote)

The door's operating home is an open filing question, tracked in this record's frontmatter. The live surface files itself as an api.insure-estate door; nothing public turns on the assignment, and this record carries it as pending rather than deciding it silently.

Founding team spans the demand rails, the substrate, and the regulated edge; a third co-founder currently leads AI at a public insurtech and joins at close.

Read the schema

The door serves today — lossruns.claims. The schema is free and keyless; early access is the one ask on the page.

If this was forwarded to you: lossruns.claims is the reference for the loss run — the carrier-issued claims history every commercial renewal waits on — published as a free, keyless typed schema, with the callable surface built in the open and labeled roadmap until it is real. Every claim above carries its own state and evidence. If you build renewal workflows on loss-run PDFs, read the schema and get early access. If you know who does: forward this.