pitch.apis.insure
The functions an insurance system calls.
FNOL structuring, claims-file extraction, deterministic claims math, statutory-clock tracking — called mid-flow by your systems and agents, at posted rates, with a receipt for every call. The licence, the Delegated Authority, the Decision, and the file stay with you.
↓ scroll · arrow keys
Every claim moves through the same stages — notice, acknowledge, investigate, evaluate, decide, pay — and between the licensed moments sits the bulk of the work: structure the first notice of loss into a typed record, extract the estimates and reports into fields a system can act on, compute the depreciation math and the statutory clocks, chase what the file is still missing. Today that work is claims staff plus a negotiated vendor stack wired into a core suite — each vendor behind its own contract, priced in a procurement cycle, none of it readable by the system actually doing the calling.
That was tolerable when humans drove the flow. It breaks now, because the caller is increasingly a machine: a claims core, an intake pipeline, an agent acting for either. A machine cannot sit through procurement. A price it cannot read at call time does not exist for it — and in claims the stakes are sharper than in most industries, because the file it is working on is the exhibit in any bad-faith suit. Opaque vendor logs are not just an audit nuisance here; they are discovery.
The contract is small enough to state in full. discover the catalog — typed schemas, posted rates, versions. describe one function's contract. estimate a call before making it — the estimate is binding for the quoted inputs. structure a first notice of loss — call transcript, email, portal submission — into a typed FNOL record: date of loss, peril, location, coverage line, and the clock it starts. extract claims-file documents — estimates, ACORD forms, police reports, correspondence — into structured, typed records. compute deterministic claims math: actual-cash-value and depreciation arithmetic, total-loss threshold tests per state, statutory-deadline computation under each state's Unfair Claims Settlement Practices Act — versioned so the same inputs always reproduce the same figures. lookup reservation and licensing posture: which acts a state reserves, which licence and Line of Authority an act requires, per state and line. track what a file is missing, what is stale, which statutory clock is inside its window. inspect the receipts.
// illustrative product mechanics, not results
POST /invoke
{
"function": "compute.ucspa-clock@v4",
"program": "homeowners-tx-2026",
"inputs": { "state": "TX", "event": "proof_of_loss_received", "on": "2026-07-14" }
}
// every call returns a receipt:
{
"receipt": {
"function": "compute.ucspa-clock@v4",
"program": "homeowners-tx-2026",
"credential": "org:carrier/systems/claims-core-prod",
"rate": "cited from the public card",
"outcome": "ok"
}
}
Nothing changes silently underneath an open claim file: every function version carries a published deprecation schedule, and a receipt cites the exact version and the posted rate it was billed at. Receipts are designed to be the one record a compliance team, a finance team, and a market-conduct examiner can all reconcile from.
And no reserved verb is on this rail. It does not adjust, settle, decide, deny, bind, or negotiate — those verbs belong to the caller's own licensed Adjusters and Producers, and the rail's outputs are typed as inputs to their judgment, never as substitutes for it.
Everything the state cares about. The licences and the Delegated Authority. The Decision — approve or deny is the outcome of a licensed Adjuster's act, and this rail never performs it. The Claim File, which remains the caller's record, assembled in the caller's systems. The Loss Fund and every Indemnity payment — no claim money touches this rail, ever, and no rate on the card is scaled to indemnity, reserve, or claim outcome, because outcome-scaled economics on claims work are how bad-faith exhibits get made.
That boundary is the design, not a limitation. A rail that tried to absorb the licensed steps would need to become what its customers already are; a rail that supplies functions into licensed flows is infrastructure to all of them at once — including to carriers and TPAs who compete with each other. Neutrality is what the boundary buys.
Where claim data goes is a contract term, not an appendix. Extraction and structuring mean nonpublic personal information — protected under GLBA and the state insurance information-practices acts — crosses into the rail mid-flow, so the rail is built to be read as the licence-holder's service provider. Data is program-scoped like the credential that carries it, processed to execute the invoked function and produce its receipt, and never used to train models. Retention is bounded by the program's stated retention window, and subprocessors are disclosed on a published list before they touch a program's data — not discovered in an exam.
Who bears it when a function is wrong is a term, too. A deterministic function can still carry a defect — a mis-ratified clock row, an arithmetic bug — and in this vertical a blown statutory deadline is not a support ticket, it is an exhibit. So the liability design is stated with the rest of the contract: every output is warranted against the function's published, versioned contract; the receipt trail that lets an examiner reproduce a figure is the same trail that scopes a defect to every affected call, so notice to affected programs runs on the receipts, not on discovery; and the rail's warranty and liability terms publish with the catalog — one set of terms at one posted card, not negotiated per customer after the first incident. What never transfers is the claims-handling duty itself: the caller's licensed staff own the Decision, and the rail's liability attaches to its functions conforming to their contract, never to claim outcomes.
A rail that sells statutory-deadline math into bad-faith-discoverable flows and carries no professional-liability program has not finished stating its terms. This deck says so out loud: the published warranty language and a bound technology E&O program are both gates, and the completeness promise below is not claimed as met until they close.
The control posture — access, retention, subprocessor management — is asserted as an audited fact when the SOC 2 Type I report is published, not before. Until then it is a design commitment, written into the contract where a compliance team can hold the rail to it.
The statutory tables under the clock and posture functions — each state's claims-handling deadlines, each state's reserved-act and licensing rows — are contracted regulatory work shared with the estate's insurance cell, and no state's function ships before its row is ratified. A clock function whose table is wrong is worse than no function; this gate exists so that can't happen quietly.
The estate draws this boundary as two brands on purpose, and each points at the other.
apis.insure — the plural — serves the licence-holder. You are a carrier, MGA, or licensed TPA; you hold the Delegated Authority and employ or engage the licensed people; your systems call functions mid-flow and your flow keeps the file. Brand layer, software economics, no licensed supply on its books.
api.insure — the singular — is the cell, for callers who don't hold the
edge. An agent or product whose workflow reaches a reserved act hands the
work to a licensed operating entity — a TPA under Claims-Handling
Agreements, with licensed adjusters on the network through gigs.claims —
and a reserved call returns a typed PENDING_ADJUSTER state until a
licensed human completes the act. Regulated-cell layer, take-rate
economics, the licence stack owned inside the entity.
The singular sibling serves: api.insure is live as the demand rail of the insurance cell, with the cell's entity formation and licensure carried as open pending gates on its own deck — stated there, not restated here.
One industry, two ICPs, two motions, two brands — and one screen for routing between them: do you hold the licence? If yes, this rail. If no, the cell. Neither brand pretends to be the other, and the estate's own cell is designed to be this rail's customer at the same posted card an external TPA pays.
| name | unit | covers |
|---|---|---|
| FNOL structuring | per invocation | notice in any form → typed FNOL record, coverage line, clock start |
| Extraction | per invocation | estimates · ACORD forms · reports · correspondence → typed records |
| Deterministic claims math | per invocation | ACV/depreciation arithmetic · total-loss threshold tests · statutory-clock computation, reproducible per version |
| Reservation & posture lookup | per invocation | reserved acts · required licence and Line of Authority, per state and line |
| Lifecycle tracking | per invocation | missing · stale · inside-a-statutory-window, across a claim file |
Insurance claims runs on negotiated vendor programs, which is exactly why this rail refuses one. The caller is a system, so the price has to be readable at call time by the thing deciding whether to call. One card means a two-adjuster TPA pays what a national carrier pays — list price IS the arm's-length price, and third parties paying it are what makes that true. Every receipt cites the posted rate, so finance closes its books against the same public card compliance audits agent spend against. And no rate is ever scaled to indemnity, reserve, or outcome: the meter charges the call, not the claim. The cell's outcome-released billing — no decision, no charge — belongs to the cell; this rail's promise is the opposite discipline, priced per invocation and capped before the first call.
Per-invocation rates by function class. The structure is fixed — metered, classed by compute and latency profile, program-scoped; the figures publish when the card is live, and no figure is asserted before then.
Machine payment over x402 rails is the designed path for agent callers. Until the first payment clears there, payment is by funded program balance drawn down per receipt.
"Carriers buy suites, not rails." True, and the rail is not built to displace the core — the core is where the file lives; the rail is what the flow calls mid-step. The wedge is the caller the suites were not built for: when the thing deciding whether to invoke is an agent inside the carrier's own stack, it needs a posted price, a typed contract, and a receipt — none of which a negotiated vendor program exposes at call time. The bet is that the buying pattern follows the calling pattern.
That bet is stated as a bet. It is claimed as fact when the first licence-holder's production flow calls this rail alongside its existing core — not before.
"Claims demand is a CAT spike, not a curve." Also true — catastrophe events concentrate a year of volume into weeks. A metered rail is built for exactly that shape: there are no seats to provision and no minimums to renegotiate, the bill rides volume in both directions, and surge on the demand side is compute on this side — not licensed-adjuster recruiting, which is the cell's hard problem, deliberately not this brand's. In the quiet months the same catalog serves the steady work: lifecycle tracking, posture lookups, the clock math that never stops running on open files.
Primary motion is B2A2B: the rail serves a business customer through its systems and agents — a carrier's claims core or an MGA's intake pipeline calling mid-flow on its own behalf. Secondary is A2A: external agents transacting with the rail directly, machine to machine, payment included. The channel matches the motion — machine-readable discovery at the apex domain and position in the agent-discovery namespace, because a rail whose caller is a system is found the way systems look, not the way buyers browse.
A2A is the least proven motion in the estate and the largest one if it lands. It is claimed when the first external machine payment clears, not before.
The functions on this rail — structuring, extraction, deterministic math, lookups, tracking — are precisely the work that migrates Human → Agentic → Generative → Code, and on this rail the migration runs to completion, because no reserved act is on it. The statutory floor in insurance is real, but it sits with the licence-holder — which here is the customer — and with the estate's cell, which owns its floor on purpose. This brand carries no licensed-supply cost, so its economics are software economics on a mostly fixed-cost platform, and margin improves with volume at an unchanged public card.
Calling-system count, invocation volume, and revenue. Not presentable until the reporting basis resolves; no figure appears in this deck before then.
in the agent-discovery layer, insurance functions should resolve to apis.insure the way lending functions resolve to apis.finance — the plural domain is the shelf position for machine callers, and the singular is already the cell
a licence-holder that has been through one market-conduct exam reconciling versioned receipts against one public card does not re-verify a new vendor for sport — the audit trail is the switching cost
posted rates let the rail serve competing carriers, MGAs, and TPAs simultaneously — a negotiated-price vendor structurally cannot be the neutral default for a whole industry
per-state statutory tables — clocks, reserved acts, licensing posture — are slow, shared regulatory work, ratified row by row with the cell; a competitor starts that survey from zero
The regulatory terrain under the posture functions is real and uneven: adjuster licensing is per state and line of authority, with entity-level licences in some states — and roughly a third of states do not license adjusters at all. The NAIC State Licensing Handbook is the map the tables are built against, which is why a per-state lookup is a function worth posting rates for.
Stated plainly: this deck precedes the brand's public surfaces. apis.insure is a G4 projection of the studio's G3 stack — the function runtime (functions.do), API layer (apis.do), and workflow layer (workflows.do) — and the brand-specific surfaces are designed, not shipped. Every amber below is deliberate: the deck is built before the catalog, and says so.
The catalog — typed schemas, posted rates, latency classes, versions — is the primary surface, designed so a system never needs an HTML page to find, price, or call a function. It is claimed when a machine can fetch it cold.
The rail is built to the Agent eXperience Protocol posture — discoverable, priceable, callable by machine. Conformance is claimed only when a cold conformance run is published.
The claim that matters: an external carrier's, MGA's, or TPA's production flow, calling under its own program-scoped credential against a funded budget, reconciling from receipts. It posts when it has happened, with the receipt discipline as the evidence.
Bring one claims flow — the first catalog is tuned against design partners' files.
If this was forwarded to you: apis.insure is the demand rail of insurance functions — FNOL structuring, claims-file extraction, deterministic claims math, licensing-posture lookup, and statutory-clock tracking, called mid-flow by a carrier's, MGA's, or TPA's own systems and agents at posted public rates, with a receipt for every call. The licence, the Delegated Authority, the Decision, and the file stay with the licence-holder; if you need the licensed act itself performed, that is the sibling brand — api.insure, the cell. Every claim above carries its own state and evidence — including the ones not yet earned. If you run a claims platform: read the contract. If you know who does: forward this.