pitch.apis.claims

apis.claims

Claims arrive in batches. Decisions never do.

POST a book of claim files. The open tier runs at machine scale; every reserved act lands on one licensed adjuster, typed. The batch report is derived, never authored.

↓ scroll · arrow keys

The batch contract

A Batch is a manifest, never an actor. It has no stage of its own, no clock of its own, and no decision of its own — it is an envelope of Claims, and everything it reports is derived from theirs. That one ruling is the whole product; the rest is machinery.

The shape being designed, stated as a sketch and gated below:

POST /batches
{
  "book":   { "kind": "runoff", "line": "property", "states": ["TX", "FL"] },
  "files":  [ /* one entry per claim file — FNOL record or file reference */ ],
  "offers": ["FNOLTriage", "DeskAdjustment", "SupplementReview"],
  "guardrails": { "requireLicensedAdjuster": "always" }
}
// → 202: one typed Claim minted per file, each at stage "notice",
//   each with its own UCSPA clock started; the batch report derives from them.

Every file fans out to its own Claim on the cell's rail: its own Stage derived from Events, its own statutory clock, its own Packet when a licensed adjuster picks it up. The offer grains are the cell's process-grain Offers — FNOLTriage, DeskAdjustment, TotalLossValuation, SupplementReview — flat-priced and meter-released per file. Tenant guardrails bind platform mechanics only: they may demand more than statute (licensed adjusters even in non-licensing states) and never less, and they can never touch claim merits.

Pendinggate: published Batch schema + first live batch run against it — ins/docs/entity-structure.md §open-questions

The manifest above is a design sketch of a surface that is not yet live. It posts as fact when the Batch schema is published on apis.claims and the first book has run against it. Until then, everything on this slide is intent, stated as intent. Data custody carries the same gate: the custody terms — where a posted book lives, who can read it, and the data-protection agreement that governs it — ship with the published Batch schema, and no book moves before the cell's data-protection agreement and cyber/E&O program exist.

Volume is the wedge

Claim volume does not arrive smoothly. It arrives as a CAT event declared over a book, an acquired run-off block, a backlog an audit surfaced, a supplement stack nobody owns. And when it arrives, the only lever the industry sells is bodies: BPO seats, deployment rosters, per-hour surge vendors — procured in weeks, priced on effort, and reported through one untyped queue where ten thousand files read as "in process."

The honest structure of the problem is that it splits in two. The open tier — intake, file assembly, coverage analysis, estimate review, clock reads — batches beautifully: it is exactly the work machines should do at book scale. The reserved tier — adjust, decide — does not batch, because a statute names a person, per file. Vendors that blur that line are selling a compliance problem with a throughput chart on it. This rail types the line instead.

The fan-out boundary

At batch grain the authority chain does not bend: Carrier / MGA → Claims-Handling Agreement → the cell's TPA (Delegated Authority, Merchant of Record) → one licensed adjuster per reserved act, under their own license, in their own judgment. A batch of ten thousand files means ten thousand individually attributable decision paths — or typed PENDING_ADJUSTER states while they wait, counted and queryable, never an untyped queue. The Gate commits or refuses per file; it may never commit past an adjuster's Declination, and it may never commit a Carrier-Reserved Decision on the Carrier's behalf.

Clocks are the sharpest instance of the ruling: statute never batches. Every file's UCSPA timer ladder — acknowledge within N days, decide within M of proof of loss, pay within P of acceptance — attaches per Claim, and the rail's design puts every clock under deterministic code. A batch report aggregates clock positions; no configuration, tenant or platform, extends one.

Postedcontent.naic.org/sites/default/files/inline-files/Chapter%2018%20-%20Adjuster%20Licensing.pdf

P&C claims administration is regulated as adjusting: individual adjuster licenses state by state — by line of authority where states require it — plus business-entity licenses where states have them, and some states do not license adjusters at all. That is the NAIC State Licensing Handbook's own map of the terrain.

Pendinggate: 50-state entity-licensing survey — ins/docs/entity-structure.md §open-questions

The cell's license stack is built against that map, and the build is not done: the per-state survey of entity adjuster licenses, TPA/administrator statutes that sweep in P&C, and UCSPA timer tables is contracted regulatory spend, priority one. No state/line pair ships at any grain — single claim or batch — before its row is ratified.

Batch is arithmetic, not a negotiation

  • Every act is a flat fee, fixed at post time — per file, per offer grain. Nothing per-severity, nothing percentage-of-claim.
  • The meter releases per file on a deterministic fact — the issued claim decision or the payment record. No decision, no charge. A Denial IS a Decision and releases the meter.
  • A batch price is the manifest times the posted fees — computable before the first call, cap-able by the tenant's own finance team, never a volume-opaque quote.
  • The Offer schema cannot express a percent-of-indemnity price — a structural property of the billing design, not a policy that could quietly change.
Pendinggate: first live fee data + published Offer schema — ins/docs/brand/api-storybrand.md §open-questions

Per-act fees are provisional targets until real files price them, and "cannot express" is a design commitment of a billing system that is not yet live. Both post as fact when the Offer schema is published and the first files have run against it. The demand-side card is never quoted without its supply-side twin: the adjuster's File Fee at gigs.claims is flat, fixed at post time, and decision-independent.

One cell, three doors

apis.claims is not a second insurance business. It is the third door of one licensed operating cell: api.insure is the per-claim demand rail whose primary caller is an agent; gigs.claims is the supply door recruiting the licensed adjusters who will claim prepared files at a flat, decision-independent File Fee once the match queue is live; apis.claims is the batch demand surface for the team that arrives with a book. One license stack, one TPA, one pool, one Gate — the grain of entry is the only difference, and every reserved act from every door is designed to land on the same licensed supply.

That is also why batch grain is credible here at all: a batch rail without owned licensed supply is a queue with a schema. This one fans out to a pool the cell is recruiting on purpose today — license-checked at application, covered under the cell's E&O program before the first reserved act runs.

Postedapi.insure

The cell's per-claim demand rail serves: api.insure answers today with the capability contract stated in the open — open work vs reserved acts, the reserved line typed PENDING_ADJUSTER, bind stamped Roadmap — and says candidly, on the page, that it is early access with no live service yet.

Postedgigs.claims

The cell's supply door serves: gigs.claims is live and recruiting licensed adjusters — Designated Home State licenses ranked full standing — and states on the page that it is onboarding founding adjusters ahead of a live match queue.

How it goes to market

The motion is B2D: claims-platform and claims-operations engineers, reached where they already evaluate — the schema, the docs, the typed-state contract — because for this ICP the manifest shape is the sales call. The entry moments are named and lumpy by nature: a CAT declaration, a run-off acquisition, a backlog audit, a supplement stack. The rail's job is to be the thing their engineer has already read when one of those moments arrives. Secondary motion is B2A2B — the same surface called by the tenant's own agent stack.

No paid or scaled acquisition pre-launch. The funnel is a design-partner conversation scoped to a bounded book, and it opens only as the cell's licensure closes.

Pendinggate: apis.claims surface live on the domain

apis.claims does not serve yet. This record precedes the surface deliberately — the record is the spec the surface is built to, and this claim flips posted when the domain answers with the schema on it.

Where it stands

Pendinggate: cell entity formation, licensure, and first CHA signed — ins/docs/entity-structure.md

Entity formation, TPA licensing, and the first Claims-Handling Agreement are in progress. Until they close, this deck describes a designed surface of a designed cell — deliberately, in the open. No batch runs before the entity, its Delegated Authority, and its E&O program exist.

Postedwww.tdi.texas.gov/agent/adjuster-designated-home-state-apply.html

The supply mechanics the batch surface depends on are real, filed machinery: the Texas Designated Home State adjuster license is a special non-resident license granted only to residents of states that do not license adjusters — state licensing law, not a platform workaround.

Reciprocity hangs off that anchor — the design reason an owned pool can be built to cover a multi-state book at all, with eligibility computed per state and line rather than eyeballed.

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.

Bring a book

The cell's front doors serve today — api.insure and gigs.claims; apis.claims is the batch door being built beside them.

If this was forwarded to you: apis.claims is the batch surface of a licensed claims cell being built in the open — machine-scale intake and file preparation across a book of claims, with every reserved decision landing on one licensed adjuster, typed and attributable, and every claim above carrying its own state and evidence. If you hold a book like that, the design-partner door is the ask. If you know who does: forward this.