A settlement agent posts a payment, a coverage agent applies an exclusion, an estimation agent prices a repair — and when a file reviewer asks within whose authority the payment was made, the honest answer in most estates is a service principal that held the same entitlement at every hop. The companion teardown to this piece, The adjuster of record is a service account, and the examiner now has a worksheet, walks the evidence that the question has an owner in market conduct examination and no field in the stack. I am going to take that as established. What follows is the design I would build against it.

The reason to build it in this sector first is not that carriers are the largest buyers of anything. It is that insurance is the only place where the answer already exists for the human case, in a form the business runs on daily, and where the examination instrument that will ask for the machine case is being written down in public while there is still time to build against it.

The design target is a worksheet, not a diagram

Most agent-governance material produces an architecture for an audience that will ask for records. In insurance that mismatch is about to become concrete in a way it is not anywhere else, and it changes what the design is aiming at.

The NAIC AI Systems Evaluation Tool is an examination instrument: structured material state examiners use to evaluate an insurer's governance of AI systems, developed under the NAIC's Big Data and Artificial Intelligence (H) Working Group. A twelve-state examiner pilot runs January through September 2026. The instrument reached version 4.0, discussed in a public session on 1 June 2026 — four versions inside a pilot, which tells you the questions are being sharpened against what examiners actually find. Consideration for adoption is expected at the Fall 2026 National Meeting. Expected is the correct verb and I will not improve on it; the failure analysis below takes seriously that it might not happen.

Two disciplines before anything is built on that. I am describing the Tool's function from the NAIC's own public committee material about the pilot, not its internal question text, which is pilot-stage work product — nothing in this piece quotes it, paraphrases it at question level, or imitates its phrasing. And the argument does not depend on any particular question surviving to the adopted version. It depends only on the kind of instrument it is, which is publicly established: a structured, examiner-facing set of questions with fields.

A field is a different design constraint from a walkthrough. In a supervisory walkthrough, a control narrative paragraph can do work. Somebody reads it aloud, somebody else asks a follow-up, and the conversation closes the gap between what was written and what happened. A worksheet removes the conversation. It has a blank, and the blank wants a name, a date, a limit, a reference. Prose is what fills the margins of an exam script, not the blanks. That single fact is why this design is shaped around projection rather than around architecture: the deliverable is not a defensible system, it is a record that lands in the blanks without re-keying and without narrative.

FIGURE 1 · THE SPINE OF THE CONSTRUCTION The grant narrows as it descends, and it starts at a name. ROOT GRANT · A HUMAN DECISION THAT OCCURRED R. Iyer, claims manager · authority to $250,000 (illustrative) authorises the platform for claim C-2214 · decision record bound into the grant mint + attenuate orchestrator grant · cap $25,000 · claim C-2214 · purpose: settlement names its parent · expires with the task · narrower than the root in amount, scope and time attenuate settlement-agent grant · cap $11,200 (the approved estimate) · single use names its parent · usable only against POST /claims/C-2214/payments present VERIFIED WHERE THE PAYMENT LANDS the payments endpoint evaluates the whole chain, not the bearer: amount within every bound · chain terminates in a person · then execute file grant receipt written into the claim file a structured note beside the payment it evidences — where examiners already look ABOVE ANY BOUND? a payment exceeding its grant does not fail silently — it raises a referral event to the named human above it, exactly as the human schedule already works. the referral is itself a recorded grant: request, approver, timestamp, decision Every settlement is inside a named person’s authority, or it produced a referral — the sentence the carrier already says about its adjusters.

Every claim number, dollar figure, role name and authority limit in this piece and in its figures is a constructed illustration, assembled from the structure of an industry-standard settlement-authority schedule. No carrier's actual schedule, limits, role titles, claim, policyholder or deployment is depicted, and no part of this piece describes client work.

Four premises carried, and two this sector forces

The general primitive rests on four statements, argued at length elsewhere and restated compactly here so that a reader who rejects one can say which.

  1. Carried, not ambient. A component acts on authority handed to it for a stated purpose, never on authority it happens to hold because of where its process is running.
  2. Every hop mints a weaker credential naming its parent. No new credential means no edge to record and no boundary to enforce. No named parent means a heap of grants with no ancestry, which answers who acted and never on whose authority.
  3. Verifiable without replay. What is presented at the boundary must be sufficient on its own — no issuer call, no telemetry join, no reconstruction after the fact.
  4. Monotone attenuation. A child cannot exceed its parent, because the only constructor available computes an intersection. Over-delegation stops being a mistake to avoid and becomes a state with no route to it.

Insurance adds two more, and they are the reason this design differs from its banking sibling rather than being a rename of it.

Five: the grant is denominated in the decision's own units, and its root is a rung of the settlement-authority schedule. Banking's version of this premise says the root must be a named natural person. Insurance says something stronger and more specific, because the sector already has the schedule: the root is not merely a person, it is a person at a rung, holding a monetary limit that exists independently of the agent and would still exist if the agent were switched off tomorrow. A grant is therefore denominated in dollars per claim rather than in endpoints, which matters because the examination question is denominated in dollars per claim. An entitlement that says the platform may call the payments API is a statement about capability. A grant that says this settlement, up to the approved estimate of eleven thousand two hundred dollars, derived from R. Iyer's two-hundred-and-fifty-thousand-dollar rung is a statement about a decision, in the units the decision was made in.

Six: the record projects, and projection is a first-class operation rather than a reporting afterthought. A grant receipt that lives only in an engineering trace has failed half its purpose. This sector's examiners read claim files, and are about to read worksheets, and do both under a patchwork of state adoption in which no two jurisdictions necessarily ask the same thing. So the record has to be one object with several renderings, computed rather than re-keyed: into a structured note beside the payment in the claim file, into whatever category set the examination instrument settles on, and into a per-state posture. Anything requiring a human to transcribe between those renderings will drift, and drift in an examination artefact is worse than absence, because absence is honest.

Now the strongest objection, at full strength, before the design rather than after it — because it is a good objection and the design does not defeat it.

You are proposing that a claims manager's personal authority sits at the head of a credential chain whose downstream hops are decided at runtime by a model. In a catastrophe surge that person is approving thousands of root grants a day, which means they are approving none of them. You have not created accountability. You have created a signature block with a claims manager's name on it, and you have made it look like evidence.

That is correct about the failure mode, and it reappears as failure mode one below rather than being answered away here. What I claim is narrower and I think it holds. In an ambient-authority system the broad grant is a configuration value: no author, no timestamp, no review, discoverable only by reading the deployment history of a file. In this design the broad grant is a signed root with a named person on it, a limit written in the same dollars the schedule already uses, and a date — which makes the breadth legible to anyone who thinks to put it beside the schedule. It does not prevent the wide grant. It converts the wide grant into a document. Most of what governance does, here and everywhere else, is convert absences into documents so that somebody can look at them later and ask why.

What the instruments already ask for, read as design input

It would be convenient to argue that the supervisory material was written for models and needs updating for agents. It does not, and reading the three instruments as specifications rather than as obligations is the fastest route to the design.

The Model Bulletin supplies the category set. The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers was adopted by the NAIC membership on 4 December 2023 and has been adopted in more than twenty jurisdictions by mid-2026. Even its title needs care: much of the adoption-period material circulates that rendering, while the NAIC's own page renders it …by Insurance Companies, and a reader who checks will notice which one you used. What it asks for is concrete and it is a category list, not a question list: a written program for the responsible use of AI systems, governance with defined roles, risk management and internal controls proportionate to the decision's consumer impact, oversight of third-party AI systems and data, and the expectation that all of it is producible on request. Those categories — accountable individual per lifecycle stage, inventory linkage, third-party oversight, decision-level provenance — are what this design projects into, precisely because they are the bulletin's own headings and not somebody's guess at a pilot instrument's wording.

The Evaluation Tool supplies the shape, and the shape is the constraint. The Tool is what expect regulators to ask becomes when it is turned into a document. What it establishes for a designer is not any particular question but a fact about the medium: examination is being standardised, which means the answer has to be standardisable. A carrier that can answer beautifully in a meeting and cannot fill a field has built for the wrong medium. Note also which way the pilot's iteration count cuts. Four versions between January and June is not instability; it is a sign that the questions are being tested against the records carriers can currently produce, and whatever is adopted will have been sharpened against exactly that.

Circular Letter No. 7 supplies the second axis, and it is the one that changes the object. New York's Insurance Circular Letter No. 7 (2024), issued 11 July 2024, addresses artificial intelligence systems and external consumer data and information sources — ECDIS — in insurance underwriting and pricing. Its structure is what transfers. It does not ask the insurer to assert that its data and models are fair; it asks the insurer to be able to demonstrate it, with assessment before use, testing appropriate to the use, senior oversight and documentation an examiner can follow — and it does not let reliance on a vendor discharge any of it. Demonstration rather than assertion is the whole distance between a record and a bridging paragraph. And because the letter's grammar is per decision, the lineage of an external source cannot live in a vendor contract or an annual review; it has to be attached to the thing that was created at the moment of the decision, which in this design is the grant.

Paraphrase discipline. The expectations attributed to Circular Letter No. 7 above — assessment before use, testing proportionate to the use, senior and board-level oversight, retained documentation, and third-party accountability that stays with the insurer — are characterisations of a short letter that should be read whole, not quotations. Where this piece needs the letter's exact words it does not supply them, deliberately. Read the text at dfs.ny.gov before relying on any characterisation, including this one.

The data model

A grant is the only thing that travels. It carries the rung it descends from, a monetary bound, a claim selector, the lineage entries accumulated on the way down, a pointer to its parent, and a seal binding it to the chain above. Four properties are load-bearing, and the third and fourth are the insurance ones.

  1. Widening is not an operation. The constructor returns an intersection. A cap can only fall, a claim selector can only narrow, an expiry can only come forward. Over-delegation is not refused at runtime; there is no function that would perform it.
  2. A child's seal is keyed by its parent's. Holding a child gives you the terminal value and no way to invert it, so a holder can extend the chain downward and cannot climb it. That makes the parent pointer structural rather than a claim the child chose to include.
  3. The rung travels on every link. Not looked up at verification time — carried. A payments endpoint with no access to the carrier's HR directory can still name the accountable individual and state the limit they hold, which is the difference between an artefact you can hand to a reviewer and one that needs a live integration to interpret.
  4. Exceeding a bound produces a referral, not a failure. This is the property that makes the design match the business rather than fight it. A request above the cap does not return an authorization error into a log nobody reads; it raises a referral to the named human above it, and the referral is itself a recorded grant — request, approver, timestamp, decision. That is exactly how the human schedule already works, which is the point.
Configuration

The record, the referral, and the three projections

Three files. The first is the data model, with the type discipline that makes a service principal unable to root a chain. The second is the monotone constructor and the referral path — the piece of the design that maps onto the schedule the carrier already runs. The third is projection, which is where this design differs from its banking sibling: one record rendered into a claim-file note, an examination category set drawn from the Model Bulletin's own headings, and a per-state posture. Cryptography, identifier generation and the clock are injected, because a delegation library must not choose a carrier's key management.

The fifth premise is enforced here and nowhere else. mintRoot takes an AuthorityRung, whose holder is a NaturalPerson and whose limit is a bigint of minor units. A ServicePrincipal cannot be passed to it — not because a check rejects it, but because the call does not typecheck. A runtime check is a control that gets relaxed under delivery pressure; a parameter type is a control someone has to rewrite the function to relax, which leaves a diff in a pull request.

src/settlement-grant.ts
/** A person of record. Not a login, not a role, not a service account. */
export interface NaturalPerson {
  readonly kind: "natural-person";
  readonly personnelId: string;
  readonly legalName: string;
}

/** One rung of the settlement-authority schedule. Exists independently of any agent, and
 *  would still exist if every agent were switched off tomorrow. That independence is what
 *  makes it a legitimate root: it was not invented to make the chain terminate. */
export interface AuthorityRung {
  readonly holder: NaturalPerson;
  readonly scheduleRef: string;          // the schedule version this rung was read from
  /** Per-claim settlement limit in minor units. bigint: no float touches a payment. */
  readonly limitMinorUnits: bigint;
  readonly currency: string;
}

/** Everything that is not a person. Present so the type system can refuse it as a root. */
export interface ServicePrincipal {
  readonly kind: "service";
  readonly id: string;
}

export type Subject = ServicePrincipal | { readonly kind: "agent"; readonly component: string };

/** Where an external source entered the chain. Attached to the grant, never to a log line,
 *  because Circular Letter No. 7's grammar is per decision and a log line is per call. */
export interface LineageEntry {
  readonly sourceId: string;
  readonly vendor: string;
  readonly contractRef: string;
  /** The assessment that cleared this source for use in decisions of this class. */
  readonly assessmentRef: string;
  readonly retrievedAtIso: string;
}

export type Bound =
  | { readonly kind: "amount-cap"; readonly currency: string; readonly minorUnits: bigint }
  | { readonly kind: "claim"; readonly claimId: string }
  | { readonly kind: "expires-at"; readonly epochMillis: number }
  | { readonly kind: "single-use" }
  | { readonly kind: "endpoint"; readonly method: string; readonly path: string };

export interface ClaimGrant {
  readonly id: string;
  /** null only at the root. A child's seal depends on its parent's, so this cannot lie. */
  readonly parentId: string | null;
  /** Carried on every link rather than looked up, so a verifier needs no directory. */
  readonly rung: AuthorityRung;
  readonly issuer: NaturalPerson | Subject;
  readonly subject: Subject;
  readonly bounds: readonly Bound[];
  readonly lineage: readonly LineageEntry[];
  readonly issuedAtEpochMillis: number;
  /** Terminal MAC of the chain, base64url. */
  readonly seal: string;
}

/** A bound was hit and a human was asked. This is the object the schedule already produces
 *  for people; the design's claim is only that the machine path should produce the same one. */
export interface ReferralEvent {
  readonly id: string;
  readonly grantId: string;
  readonly claimId: string;
  readonly requestedMinorUnits: bigint;
  readonly boundMinorUnits: bigint;
  readonly referredTo: NaturalPerson;
  readonly raisedAtIso: string;
  readonly decision: "approved" | "declined" | "open";
  readonly decidedAtIso: string | null;
}

export interface Env {
  readonly mac: (key: Uint8Array, message: Uint8Array) => Uint8Array;
  readonly newId: () => string;
  readonly nowEpochMillis: () => number;
}

Encoding, the MAC implementation and the property tests are omitted for length rather than because they are trivial: canonical serialisation in particular is security-relevant, because two encodings of the same logical grant differing by a byte produce two different seals, and a verifier that accepts either has a malleability bug rather than a formatting inconsistency. The AdoptionPosture union is a structural characterisation of how model bulletins are adopted, not a census: no jurisdiction is assigned a posture anywhere in this package, and a carrier populating it must do so from its own filed-state analysis.

The projection principle, and why state variance is a design input

FIGURE 2 · THE PROJECTION PRINCIPLE One record. Every rendering an examiner could ask for. THE DECISION RECORD grant chain for one settlement • the named root and its schedule rung • the bound at every hop, in dollars • third-party hops, and what crossed • data lineage: which sources entered • referral events, if any bound was hit created at decision time — never reconstructed afterwards project project project THE CLAIM FILE a structured note beside the payment it evidences readable by a file reviewer with no engineering context: who authorised, within what limit, on which basis THE EXAMINATION WORKSHEET • accountable individual, per lifecycle stage • AI system inventory linkage • third-party systems and data oversight • decision-level data lineage categories from the Model Bulletin’s own headings — not the Evaluation Tool’s question text, which is pilot-stage work product THE STATE POSTURE • bulletin adopted verbatim — full category set applies • adopted modified — per-state deltas tracked, not guessed • not adopted — underlying claims-practice law still binds New York’s Circular Letter No. 7 (2024) runs on its own track: demonstration, per decision, vendor reliance excluded A national carrier builds one record to the union of what any state can ask, and projects it per state. The strictest examination sets the shape.

The usual way a national carrier reasons about a patchwork is as a compliance burden to be minimised: find the states that ask least, build to them, handle the rest by exception. That reasoning is exactly inverted for an examination artefact, and the inversion is the most useful thing in this piece.

An examination is not an average. A carrier writing in forty jurisdictions is not examined by the mean of forty postures; it is examined by whichever one is looking, and the result of that examination is the result. So the record has to be built to the union of what any state in the footprint can ask, and rendered down per state — which is cheap, because subsetting a record you already hold is a projection, while widening a record you did not build is a rebuild.

Variance raises the effective bar rather than lowering it. The Model Bulletin has been adopted in more than twenty jurisdictions, which means a majority of the market operates under it and a substantial minority does not. The comfortable reading is that the minority is headroom. It is not, for two reasons. Adopting states issue the bulletin as guidance interpreting law already on their books — unfair trade practices, unfair claims settlement practices, market conduct examination authority — and that underlying law binds in the non-adopting states too; the bulletin tells insurers what the regulator will look for, it does not create the thing being looked for. And New York's Circular Letter No. 7 runs on its own track entirely, with a demonstration standard that is in force now rather than expected in the autumn. A carrier that built to the twenty and skipped New York has built to the wrong union.

One honest limit on the projection code above. It renders the Model Bulletin's own category headings, which is a defensible choice because the bulletin is published and adopted. It does not render the Evaluation Tool's fields, because those are not published and imitating them would be both a fabrication and a poor engineering bet: the pilot has already moved through four versions. What the design guarantees is that the underlying record contains the material the categories are about — a named individual, a chain the inventory can be joined to, the third-party hops, and per-decision lineage. Mapping that material into whatever fields are finally adopted is an afternoon's work if the material exists and an impossibility if it does not, which is the only claim about the Tool this design actually needs.

Lineage rides on the grant, or it does not exist

FIGURE 3 · ECDIS LINEAGE, PER DECISION The lineage travels with the grant, or it does not exist. BOUND AT THE MOMENT OF USE external data source vendor + contract reference testing reference on file retrieval hop writes a lineage entry: source id, vendor, testing ref, timestamp the decision record authority chain + lineage entries, one object, made at decision time per-decision demonstration which data entered this settlement, from which source, under which testing THE PREVAILING PATTERN external data source the same source, the same vendor retrieval hop content enters the context window as conversation state state is consumed the linkage between source and settlement evaporates with it system-level assertion only “we use these sources, tested annually” — not the letter’s grammar New York asks the question per decision. Only a record made per decision can answer it.

The second axis is where insurance forces a change to the object rather than to the reporting around it, and it comes from New York.

Circular Letter No. 7's demand is per use: for this outcome, what external data entered it, from which source, and what assessment supports its use. In a conventional retrieval-augmented chain that linkage exists only as conversation state. A retrieval hop pulls a third-party score, a property-characteristics record or a contractor-pricing feed into the context window; the model consumes it; the state is discarded; and what survives is a system-level assertion — we use these sources and we test them — which is not the letter's grammar. The carrier is left demonstrating at the level of the system when the question was asked at the level of the decision.

The design's answer is one line in the data model and one habit in the runtime: a retrieval hop does not merely fetch, it attenuates, and the attenuation carries a lineage entry. Source identifier, vendor, contract reference, assessment reference, timestamp — bound into the grant at the moment of use, and carried downward with it, because the grant is already the thing that travels. By the time the settlement agent posts a payment, the chain it presents contains the complete list of external sources that entered the decision, ordered, dated, and each pointing at the assessment that cleared it.

The vendor-reliance clause is what makes this non-optional rather than tidy. If an insurer could satisfy the letter by pointing at the vendor's own assurances, an annual due-diligence file would be sufficient and none of this would be necessary. The letter does not allow that: the insurer remains responsible for demonstrating what the third party's data and model did in its decisions. Responsibility that does not attenuate, meeting a data flow that currently records nothing, produces exactly one workable design — the record of what crossed the boundary has to be made by the party that remains responsible, at the moment it crosses, on an object that survives the call.

There is a second-order benefit worth naming because it is the one that sells the work internally. A grant that refuses to mint when a selector names an external source with no assessment reference produces, as a by-product, a dated inventory of every source in use that nobody has assessed. That inventory is the single most useful artefact a governance function can be handed, and no carrier currently has one, because it can only be produced by something that sits in the path at the moment of use.

India is drafting, the Gulf has not written it, and banking is context

Three jurisdictional notes, because a global carrier will ask and because two of the three are usually got wrong.

India first, where the clock matters more than the text, because there is no text. IRDAI constituted a seven-member working group on artificial intelligence on 18 June 2026 with a three-month window to report. That window closes as the NAIC's examiner pilot ends — one regulator finishing an examination instrument, another beginning a framework, in the same quarter. For an Indian insurer or the Indian arm of a global carrier the consequence is the one this practice argues in banking: what the industry has demonstrably built by the time the group reports is the installed base the recommendations get written against. A claims chain whose authority record terminates in a service account is a poor exhibit. A chain where every settlement carries a named, bounded, dated grant is the exhibit a working group cites.

The Gulf, in one honest sentence: as of this writing I can verify no insurance-specific AI instrument in any GCC jurisdiction, this piece therefore cites none, and anyone who cites one to you should be asked for the document. The practical consequence for a carrier or reinsurer operating there is not that nothing binds — it is that what binds arrives through counterparties, group policy and reinsurance security committees, which tend to transmit exactly the NAIC- and DFS-shaped questions above. An absence of a local instrument is an absence of a local answer sheet, not an absence of the exam.

Banking, briefly, because insurance readers inside financial groups will meet it and because the mis-citation is common. On 17 April 2026 the banking agencies issued revised interagency model risk management guidance — Fed SR 26-2 / OCC Bulletin 2026-13 — and footnote 3 of the shared interagency document, not of the OCC's wrapper, places generative and agentic AI models outside its scope while returning responsibility for their governance to the institution. Read as a deferral rather than an exemption. None of it governs an insurance claims chain and this piece does not pretend otherwise. It matters here only because a bancassurance group now faces both postures at once — a deferral on one side of the house and an examination pilot on the other — and one architecture answers both, while the deferral excuses neither.

How this design fails

Seven failure modes, in rough order of how likely each is to be the thing that actually goes wrong.

One: the rung becomes a signature block, and catastrophe surge is when it happens. This is the objection quoted earlier and it is the most probable failure by a wide margin. In steady state a claims manager minting root grants for large or unusual losses is doing something recognisable. In a surge — a hailstorm, a hurricane, a freeze event — volume rises by an order of magnitude overnight and the pressure to mint one wide root per queue rather than one per claim is enormous and operationally rational. The design does not prevent it. What it does is make the wide root a dated document with a name and a limit on it, so that the ratio of authority granted at the root to authority actually exercised beneath it is computable. The mitigations are unglamorous: cap root validity in days rather than months, require re-issue rather than extension, and report that ratio weekly to the person whose name is on it. None is a control. All are ways of making the gap visible to somebody paid to look.

Two: monotone does not mean safe. A narrower grant is not automatically a smaller exposure. A grant restricted to one claim and capped at the approved estimate, held by an agent in a loop, can pay the same claim repeatedly unless single-use is asserted and enforced; a fleet of such grants can produce an aggregate exposure no individual bound describes. Monotonicity caps what a delegate may do relative to its parent and says nothing about frequency, aggregation or correlation across sibling chains. Rate limiting, duplicate-payment detection and aggregate exposure are separate controls, and this design does not attempt them. It makes them expressible as bounds, which is a much weaker claim.

Three: the referral path can be defeated by making the bound generous. The referral is the design's best feature and its softest one. A referral only fires when a bound is hit, so a system that mints every grant at the estimate plus a comfortable margin will produce a beautiful record containing no referrals at all — and a record with no referrals looks identical, to a worksheet, whether it means the bounds were right or the bounds were meaningless. The only honest diagnostic is the referral rate itself, compared against the referral rate of the human claims population doing comparable work. If the machine path refers at a materially lower rate than the people it replaced, the bounds are decorative, and that comparison should be a standing report rather than an investigation someone launches after an examination goes badly.

Four: the record is discoverable, and in this sector that cuts both ways. A per-decision authority record with dollar bounds, named individuals, referral events and data lineage is exactly as useful to plaintiff's counsel in a bad-faith action as it is to an examiner. That is not a reason to avoid building it — a carrier that cannot answer the question in an examination will not enjoy answering it in a deposition either — but it is a reason to build it deliberately, with retention, privilege and disclosure decided by people who do that for a living before the first grant is minted rather than after the first subpoena. A design that improves your examination posture and degrades your litigation posture without anyone having weighed the two is a design that was shipped by engineers alone.

Five: the Tool may arrive weakened, late, or not at all. Adoption at the Fall 2026 National Meeting is an expectation, and pilots exist to change instruments. The Tool could be adopted without the accountability material this piece leans on; adoption could slip; states could adopt it as unevenly as they adopted the bulletin. What that would falsify is the timing argument. What it would not touch is the structural one: the settlement-authority schedule is the carrier's own control and the chain already fails against it, Circular Letter No. 7 is in force now, and the underlying claims-practice law binds in every state whether or not anything is adopted this autumn. A design justified only by an expected worksheet is a design with a single point of failure in somebody else's committee calendar.

Six: revocation and offline verification pull against each other. The third premise says a verifier needs nothing but the chain and a cached key. Revocation says a grant valid a moment ago must stop working now. Both cannot be absolutely true. The available compromises are all unsatisfying: short expiries, which trade revocation latency for issuance volume — and issuance volume in a surge is precisely when you least want it; a revocation epoch on the rung's key, which invalidates every descendant at once and is therefore the blunt outage the design was supposed to replace; and a distributed deny set, which reintroduces the dependency and fails open. Ship short expiries plus a rung epoch, write the revocation latency down as a number, and stop describing it as zero.

Seven: this covers authority, and says nothing about whether the settlement was right. A perfectly verified chain establishes that a payment was inside a named person's authority. It establishes nothing about whether the depreciation was correctly applied, whether the coverage reading was sound, whether the estimate reflected the loss, or whether the letter to the policyholder was accurate. Those are claims-quality questions and the file review that has always examined them still does. Presenting an authority record as an answer to claims quality would be exactly the overreach this sector is best at detecting, and a carrier that does it once will not be listened to twice.

What it costs

Three kinds: on the request, on the people who run it, and on the migration into a claims platform that already works and cannot stop.

On the request. Verification is a MAC and a canonical serialisation per link, plus a bound evaluation. Linear in depth, small constant, pure computation — no network, no lock. That is a property of the algorithm and I will assert it. A latency number is a different matter and I do not have one: this has not been measured under a representative workload. The measurement is specified — p50 and p99 across depths one to twelve, single core, with and without a possession proof — and the prediction under test is that verification stays below the deserialisation cost of the request body it rides on at every depth in that range. It is planned, not performed. Anyone who reads a figure into that sentence has read one I did not write.

On the people. This is the cost that gets left out of the business case, and in a carrier it is larger than in a bank because the schedule is a live operational artefact rather than a policy document. Somebody has to own the mapping from the settlement-authority schedule to root keys, and re-own it every time the schedule changes — which is every reorganisation, every acquisition, every catastrophe deployment where adjusters are borrowed across regions. Somebody has to be able to bump a rung epoch at two in the morning during a surge. The append-only store's retention is driven by claims and examination obligations rather than by storage cost, which in this sector means years and in some lines means much longer. And there is a new incident class — the chain does not verify — with its own runbook, its own first false positive (clock skew against an expiry bound, every time), and a fail-open-or-fail-closed decision that must be made deliberately by somebody senior rather than discovered during a hailstorm.

On the migration. A grant does nothing until something verifies it, and in a carrier the thing that would verify it is the payments path in a claims platform under change control measured in quarters. So the sequence runs backwards from what people expect. Emit and enforce nothing, letting the record fill until the actual delegation topology of a live claims workload is visible — including hops nobody knew existed. Then verify at one boundary you already own, logging failures and permitting the payment. Then flip that boundary closed, out of season rather than in surge. Then widen. Every step reverses except the last, and the payoff arrives at step one: a complete authority record with no enforcement attached already answers a question the estate previously could not answer at all, which is the entire examination argument delivered before any risk has been taken.

If you had a week

Build four things and deliberately skip the rest.

  1. The invariant, with its property test. ClaimGrant, attenuate, and two properties: a child's cap never exceeds its parent's at any depth, and a chain whose root issuer is not the rung holder never verifies. Two days at most, and the only part where being wrong is unrecoverable, because everything downstream assumes the invariant holds. Ship the test or you have an intention rather than a guarantee.
  2. One root grant, minted against a real rung, by the person who holds it. Not a fixture. Sit with whoever owns the settlement-authority schedule and write the bounds in the units they already use. That hour teaches more about deployability than the rest of the week, and the usual outcome is discovering a schedule condition the bound types cannot express — a per-line limit, a coverage-specific carve-out, a catastrophe-mode override — which is exactly what you want to find in week one rather than month six.
  3. Shadow emission from the handoff. Wherever your platform passes work between components, write an authority edge and a lineage entry, and nothing else: no verification, no enforcement, no blocking. Inside a week you will be looking at the real delegation topology and the real external-source list of a live claims workload, and no dashboard in the estate currently produces either.
  4. One cold projection. Take a single paid claim out of the shadow record, run toClaimFileNote and toExaminationCategories over it, and hand both to somebody in claims compliance who did not build the system. Ask them to answer, from those two artefacts alone and without asking you anything, who authorised the payment and within what limit. That is the examination, rehearsed under laboratory conditions. If it fails here, nothing else in this design is worth building yet.

Skip, deliberately: revocation infrastructure, possession binding, a bound language, any user interface, chain compaction, and the state-projection matrix. All six are real requirements of a real deployment, and all six are ways to consume a week without ever looking at the delegation topology. Look at it first. It changes what people think they are building more reliably than any design review does.

The closing argument is not a security argument. Attenuation caps exposure, which is worth something, and the failure analysis above should make clear how much and how little. The argument that carries in this sector is narrower and harder to dismiss. Twelve states are spending 2026 teaching examiners to ask these questions from a script, and the script has been revised four times against what carriers can currently produce. Whatever is adopted will have been sharpened against records that cannot answer. The interval before it is adopted is the only period in which what a carrier builds shapes what it is later scored against — and the carrier already owns the answer, in a schedule it has maintained for a century, for the people the agents replaced.