# Insurance Is June's Underwriting Pillar With A Unit Of Payment: The Premium Is Paid In Allocation From A Finite Pool, Pooling Is The Mechanism And Correlation Is What Breaks It, And Recoverability Decides What May Be Insured At All

**version** v0.33.62
**date** 26 August 2026
**from** Human (project lead)
**to** Architecture, Strategy, the RiskMandate team, Finance

**type** Architecture brief

*Third of 26 August. The repository was searched before anything was written and the underwriting framing was found to be ten weeks old rather than new, which changes what this document is for. The platform limits in the second worked example are checked against the vendor's documentation, and the cost allocation practices against the published framework. The insurance terminology is mapped in full, including the one place it genuinely does not apply, because a model borrowing a regulated industry's vocabulary will be challenged by the first reader who knows that industry. Limitation: the version number assumes one working-day increment since 20 August; no policy has been run, so the numbers are illustrative; and the correlation argument is structural, since no pool exists yet to measure.*

---

## What This Is

The insurance model for the risk product, placed against the corpus position it continues rather than replaces, and the mechanics that decide whether it works: **the framing is not new, because an architecture brief of 18 June filed under agentic permissions already established that accepting a risk is underwriting it insurance-style, that the risk exists the moment the permission is provisioned so the only variable is how long you accept it, that people engage only when they click accept because that is when accountability attaches, and that acceptance flows upward from user to board with each party underwriting, so what this adds is the unit of payment and a claim that settles without a person; the premium is real and is paid in allocation rather than in money, because the pool is finite by decision at the top and every policy issued consumes capacity no other team can have, which makes the scarcity the feature rather than a limitation since a budget nobody can exhaust produces no decisions, and which puts this closer to capital allocation than to insurance because premium and claim share a denomination; pooling is real and is the mechanism, since spreading draws across many teams and many agents makes a shared buffer far cheaper than the sum of every team's individual worst case, and the one thing it requires is that draws be roughly independent, which is where the real failure mode lives, because agent draws are unusually correlated through shared models, prompt templates, tooling and upstream dependencies, so a pool sized for independence is exhausted simultaneously by exactly the events that matter and every team stops on the same afternoon, which insurance handles with a reserve the ordinary mechanism cannot reach; moral hazard is present as in any insurance rather than disqualifying, and the standard control is experience rating, meaning a premium that rises after a draw, with one residual difference specific to agents, which is that the drawing party is indifferent to the loss so the rating has to land on the team whose allocation shrinks rather than on the agent that drew; the sharpest structural rule is that recoverability decides insurability, since commit counts are a reversible rate that resets while bytes committed into history are an irreversible stock paid by every clone forever, so a hard cap on file size is not the top of a buffer but the boundary of insurability; claims settle in milliseconds for a nameable reason, that all three questions an adjuster asks are known at the instant of the event because the event is the meter reading, which gives the constraint that a policy may only be written in units the system already counts; and the ledger this needs was specified on 6 August as generic on unit type from the first version, so commits and bytes are units three and four and no new machinery is required.** It is the third document of 26 August (cross-ref: the v0.33.40 underwriting brief, the v0.33.56 token gateway brief, the v0.33.62 permissions file brief, the v0.33.51 plug brief, and the v0.33.53 accepted-is-not-acceptable brief). New contributions: **the framing located in June and reduced to what it adds, the premium located in allocation, the terminology mapped with its one broken row, correlation identified as the failure mode with its reserve, experience rating placed on the team rather than the agent, recoverability established as the test of insurability, the millisecond claim turned into a constraint, and three risk zones.**

## This Continues June Rather Than Replacing It

The repository was searched before this was written and the framing is not new. **An architecture brief of 18 June, filed under agentic permissions, is built on exactly this analogy.**

The project lead, in June: **"because what we describe is reality, we are not describing the risk of something happening, we are asking them to accept it, to underwrite it. Maybe the analogy is insurance: you are underwriting the damage, the same way an underwriter underwrites the cost."**

That brief settled four things this model assumes without restating:

| Settled on 18 June | Consequence here |
|---|---|
| Accepting is underwriting, not predicting | The product does not forecast; it asks somebody to carry an exposure |
| **The risk exists the moment the permission is provisioned** | A policy is written against a grant that already exists, not against a possibility |
| The only variable is how long you accept it | Every policy has an expiry, and this is why |
| **People engage only when they click accept**, because accountability attaches there | A silently absorbed overage engages nobody |

> **June said what acceptance is. This says what it is denominated in, and that the claim can be settled without a person.**

And it inherits June's ladder. Acceptance flows upward with each level underwriting, so a policy denominated in tokens and commits is not a developer convenience: **it is the same object the board eventually signs, expressed in a unit a developer can spend.**

## The Premium Is Paid In Allocation

The pool is finite by decision at the top, and that decision is what creates the premium.

The project lead: **"there is a premium to be paid by the teams, because there is not an unlimited quantity of assets or tokens or whatever money it's been underwritten... and at the top, the company says, I'm okay to spend a million tokens on this, but I'm not willing to accept twenty billion tokens."**

```
   THE BOARD          fixes the pool. One million tokens, and not twenty billion
        |
        | which makes capacity finite
        v
   ALLOCATION         each policy issued consumes capacity nobody else can have
        |
        v
   THE PREMIUM        the opportunity cost of that allocation, paid at issue,
                      in the same currency the claim is paid in
```

**Premium and claim sharing a denomination is unusual and is what makes capital allocation a closer analogue than insurance proper.** A bank holds finite capital, allocates it to business lines, and a line consuming more leaves less for the others; the allocation is a commercial and political decision made visible, and the visibility is the control.

Which is the outcome the model is for. The project lead: **"we can only issue out ten policies. So now that becomes a commercial and a political decision inside the company, which is exactly the point. The point is to make it visible to the company who are using these resources."**

> **The scarcity is the feature, not a limitation to engineer away.** A budget nobody can exhaust produces no decisions. The moment there are ten policies and eleven teams, somebody has to choose, and that choice is the accountability the model exists to create.

## Pooling Is The Mechanism

**Not incidental to insurance. It is insurance.**

The project lead: **"when you spread the risk in a way across multiple parties, in this case, multiple teams deploying multiple agents, we are basically derisking the whole operation."**

That is the law of large numbers and it is why a buffer is affordable at all. Not every team spikes in the same week, so a pool sized for the estate's aggregate behaviour is far smaller than the sum of every team's individual worst case.

| | Per-team budgets | **A shared pool** |
|---|---|---|
| Sized for | Each team's worst week | **The estate's worst week** |
| Total capital required | The sum of the worst cases | **Much less** |
| Unused headroom | Stranded wherever it was not needed | **Available to whoever needs it** |
| Requires | Nothing | **Draws that are roughly independent** |

That last row is the next section, and it is also why a shared pool stopping the last agent of the day for what the first three spent is **the pool working** rather than a fairness defect. Per-agent silos would remove exactly the efficiency that makes the buffer possible.

## What Breaks A Pool Is Correlation

Pooling works when draws are roughly independent. **It fails on correlated perils**, which is why floods, pandemics and systemic financial events are the hard cases in real insurance, and why reinsurance and catastrophe limits exist.

**Agent draws are unusually correlated**, more so than almost any population an insurer would normally pool:

| Event | Correlation across teams |
|---|---|
| One team's agent has a bad afternoon | **Independent.** The pool absorbs it, as designed |
| A shared prompt template changes | **Correlated** across every team using it |
| A model version changes behaviour | **Correlated across the whole estate at once** |
| An upstream dependency breaks and every agent retries | **Correlated** |
| A new tool ships and everybody experiments | **Correlated** |

So a pool sized on an assumption of independence is exhausted simultaneously by precisely the events that matter most, and **every team stops on the same afternoon.** The failure is not one team overspending. It is every team spending normally on a day when normal changed.

Two responses, both borrowed from the industry the model borrows from.

**A reserve the ordinary mechanism cannot reach.** A tranche of the pool no automatic draw can touch, released only by a named person, for exactly the systemic case. That is a catastrophe layer, and it is the difference between a bad day and an estate-wide stop.

**And measure the correlation from the first week.** If draws across teams move together, the pool is not diversified and its effective size is far smaller than its nominal size. **That is computable and nobody will build it unless it is specified now**, because the metric everybody builds is remaining balance.

## The Terminology Maps, With One Row That Does Not

The memo asks for pure insurance terms. Done in full, because most of it maps and the exception is a design constraint rather than a quibble.

| Insurance term | Here | Sound? |
|---|---|---|
| Insured | The agent, or the session | Yes |
| Policyholder | The team that holds the allocation | Yes |
| Premium | The opportunity cost of the allocation, paid at issue | Yes |
| Sum insured, limit | The buffer | Yes |
| Excess, deductible | The normal allowance, below which nothing is drawn | Yes, and it is the better name |
| Peril, insured event | Exceeding the normal allowance | Yes |
| Exclusion | The hard cap on an irreversible loss | Yes |
| Claim | A draw on the buffer | Yes |
| Loss adjustment | Instant, because the units are already counted | Yes |
| Pooling | Across teams and agents | Yes |
| Aggregate limit | The shared pool | Yes |
| Reinstatement | The daily or weekly reset | Yes |
| Experience rating | A premium that rises after a draw | Yes, and it is the control |
| Catastrophe layer | The reserve the automatic mechanism cannot reach | Yes |
| **Insurer** | **Nobody external** | **The one row that does not apply** |
| Indemnity | The payout is permission to continue rather than compensation | Approximate |

**The absent external party is where regulation would otherwise sit**, which the project lead notes directly, and it is worth stating on any page that uses this vocabulary. Everything else is a real instrument doing real work.

## Moral Hazard Is Present, And Experience Rating Is The Control

Present in every insurance arrangement ever written and not disqualifying in any of them, because the industry has a standard answer.

**The memo names that answer.** The project lead: **"there should be a penalty... those spikes are a little bit outside the realm of acceptability"**, and separately, that a consequence of drawing is that **"your premium increases."**

That is experience rating. It requires no new mechanism, it uses the ledger that exists, and it makes the buffer costly to use without making it unavailable.

**One difference from ordinary insurance is specific to agents and decides where the rating lands.** In the ordinary case the insured wants to avoid the loss, because you do not want your house to burn. **Here the agent drawing on the policy is indifferent to the loss.** So the discipline cannot come from the insured's own preferences.

> **The rating has to land where a preference exists, which is the team whose allocation shrinks, not the agent that drew.**

Which is precisely the team-level accountability this model introduces, and it is why the premium and the hazard are one subject rather than two.

Two design consequences follow.

**A draw must be a recorded act rather than a silent overflow.** An agent told it may exceed when necessary treats the buffer as capacity, because from inside the loop there is no difference between capacity you may use and capacity you are expected to use.

| Mode | Behaviour | Verdict |
|---|---|---|
| Silent overflow | Proceeds, decrements, nobody told | **The buffer becomes the allowance** |
| **Recorded draw** | Proceeds, and an acceptance event is written, attributed and dated | **The default** |
| **Requested draw** | The agent must ask; a named party approves | Correct above a threshold |

**And the metric to surface is draw frequency rather than balance remaining.** A buffer drawn every day is normalisation of deviance, which this corpus already names alongside near-miss frequency as a leading indicator measurable before an incident. The correct response to a buffer drawn daily is **to raise the normal allowance and shrink the buffer**, not to enlarge the buffer, because that is what keeps the exceptional exceptional.

## A Draw Is An Acceptance Event

The formulation that makes this corpus-native rather than a borrowed metaphor:

> **A policy is a pre-approved risk acceptance with a limit and an expiry. Every draw on it is an acceptance event carrying a named acceptor, a timestamp and an amount.**

That satisfies the test settled on 28 July, that a risk is a statement able to carry a named acceptor and an interval, and it means the policy is not a new object type. **It is a standing acceptance, and a draw is an instance of it.**

**The acceptor of a draw is the policyholder, not the agent.** The agent spends; the team carries. Which is the grant and mandate asymmetry priced rather than solved: the party exercising the authority is still not the party bearing the exposure, and the insurance framing makes that visible and chargeable rather than making it go away.

## Three Risk Zones

| Zone | Where | The risk that lives there | Owned by |
|---|---|---|---|
| **Below cover** | Within the normal allowance | Ordinary operating risk | The team, routinely |
| **Drawing on cover** | Between allowance and limit | The exposure drawn, and its rating consequence | The policyholder, per draw, dated |
| **Outside cover** | Beyond the limit, or excluded | **Operating without authorisation at all** | **Nobody, until somebody accepts it** |

**The third zone is not a larger version of the second.** An agent past its limit is not over-insured; it is uninsured, and the corpus's own rule applies unchanged: an unaccepted risk defaults to critical and escalates without anybody escalating it. So crossing that boundary should **escalate, not only refuse.**

## Recoverability Decides What May Be Insured

**You can insure the reversible. You must not insure the irreversible.** Recoverability has been a first-class dimension here since the plug work of July, and the 2 August worked example demonstrated why: the money was refundable and the applicant who went elsewhere was not.

Applied to the memo's two worked examples:

| | **Commits per day** | **Bytes committed into history** |
|---|---|---|
| Kind of quantity | A rate | **A stock** |
| Resets | Daily | **Never** |
| Reversible | Yes, by revert | **No, without rewriting history others hold** |
| Who pays | The repository, briefly | **Everyone who clones or fetches, indefinitely** |
| Insurable | **Yes** | **No** |
| Instrument | A budget with a buffer | **An exclusion** |

The vendor's documentation supports the second column: the recommended maximum file size is one megabyte, the hard limit is one hundred, the recommended repository size is ten gigabytes, and **large repositories slow fetch operations and increase clone times for developers and continuous integration.**

> **A hard cap on commit size is not the top of the buffer. It is the boundary of insurability.** An exclusion exists for exactly the losses that cannot be indemnified, and a permanent cost imposed on third parties is that kind of loss.

The memo's figures sit well inside the platform's published ones, and the policy should **reference those published numbers rather than restate them**, so it does not drift when they change.

## Milliseconds, Because The Event Is The Meter Reading

An insurance claim is slow because three things are contested: whether the loss occurred, whether it was covered, and how much. **Here all three are known at the instant of the event, because the event is the meter reading.** The commit either is the eleventh today or it is not.

> **A policy may only be written in units the system already meters.** If nobody can name the counter, the claim needs a judgement, and a judgement is not settleable in milliseconds.

That kills an entire family of well-meaning policies, and it is the same finding reached on 20 August about mandates, where a mandate is decidable when it constrains an operation the system already sees. **The test for any proposed policy is to ask what increments.**

## The Ledger Exists, And Allocation Is What Chargeback Cannot Do

The token gateway work of 6 August specified an append-and-settle ledger with no reservation: usage is appended, the balance is derived rather than maintained, **it is permitted to go negative**, and the cutoff is a policy decision rather than a mechanism. That brief also recorded, in this corpus's own words, that **the negative threshold is an accepted risk with a stated level, a named owner and a review interval**, which is this model's policy object described ten weeks early. And it required the ledger be **generic on unit type from the first version**, with tokens first and vault size close behind.

| Unit | Status |
|---|---|
| Tokens | Specified 6 August, first unit |
| Vault bytes | Named 6 August as next |
| **Commits** | **Unit three. No new machinery** |
| **Bytes into history** | **Unit four, with an exclusion rather than a limit** |

**And the obvious objection, that large organisations already do this and call it chargeback, does not hold.** The published framework distinguishes showback, which exposes cost at any granularity and is described as always required, from chargeback, which formally integrates cost into accounting so each profit-and-loss owner bears responsibility for what it consumes and is described as not always required.

| Model | Timing | Can it refuse? |
|---|---|---|
| Showback | After the fact | **No.** It informs |
| Chargeback | After the fact, into the accounts | **No.** You discover you overspent |
| **Policy allocation** | **Before the fact, and finite** | **Yes** |

> **Only an allocation that can be exhausted can say no.** Showback informs, chargeback bills, and neither stops anything.

## Time Is A Currency, And The Rate Table Is The Hard Part

The memo generalises the unit correctly. The project lead: **"whether that is actually reflective money, whether it's tokens, whether it's bandwidth, whether it's time. Ultimately, everything costs money. Even time is a currency."**

The ledger already accommodates it. **The hard part is the rate table**, because a single internal currency forces somebody to price a commit against a token against a megabyte against an hour, and that conversion is a judgement rather than a measurement.

**Whatever is underpriced gets consumed**, since agents optimise against the cheapest path. So the rate table is a policy instrument rather than an accounting detail, and it needs an owner and a review interval like every other accepted parameter here, with dated changes, because a rate change silently reprices every policy in the estate.

## A Vulnerability Is A Repricing Event

The project lead: **"same thing when a vulnerability is discovered. Does it change a policy? Does it change what's possible? And then do we need to reflect on it, or do you just lose your right of operation for that?"**

All three are real insurance responses and should be named as three:

| Response | When |
|---|---|
| **Repricing** | The exposure is larger than it was; the premium for that class rises |
| **Coverage change** | A new exclusion, because something became uninsurable |
| **Suspension** | Cover withdrawn pending remediation; the right of operation is lost |

**And this is where the two threads of today meet.** A vulnerability changes what is possible, which is the definition of the grant, and the grant is generated by measurement, dated, and re-run to answer the drift question.

> **That drift feed is the event stream that reprices policies.** A control that stopped existing is a grant that grew, and a grant that grew is a policy that is now underpriced.

Nothing new is needed to build it: the measurement produces the diff, the diff produces the trigger, and the three responses are a decision by whoever owns the pool.

## What This Does Not Try To Be

- **Not a new model.** June established underwriting; this adds the unit and the automatic claim.
- **Not regulated insurance.** There is no external insurer, which is where regulation would sit.
- **Not applicable to irreversible costs.** Those get exclusions, and a hard cap is one.
- **Not a new ledger.** The append-and-settle ledger of 6 August was made generic for exactly this.
- **Not a rate table.** The units are settled; their relative prices are a judgement nobody has made.

## Honest Tensions

| Tension | Note |
|---------|------|
| The premium as allocation | It makes consumption visible and political, and it means the loudest team gets the largest policy unless somebody governs the allocation itself |
| Pooling for efficiency | It makes the buffer affordable and it couples every team's fate to every other team's worst day |
| A catastrophe reserve | It survives the correlated event and it is capital held idle, which is the first thing an efficiency review removes |
| Experience rating | It is the standard control and it penalises the team that reported honestly more than the one that avoided drawing by doing less |
| Recorded rather than requested draws | It preserves the speed the model needs and most acceptances then happen without anybody reading them at the time |
| Borrowing a regulated vocabulary | It is precise and evocative and there is no insurer, so the disclosure has to travel with the pitch |

## Open Questions

| Question | Notes |
|----------|-------|
| Who governs the allocation between teams? | The scarcity is the feature and nothing here says who arbitrates it |
| How large is the catastrophe reserve? | Idle capital, and its size is the difference between a bad day and an estate-wide stop |
| How is correlation measured before a pool exists? | It can be estimated from existing usage, and nobody has looked |
| What is the rating period? | Too short and one bad week is punitive; too long and the signal arrives after it matters |
| Who owns the rate table? | It is a policy instrument and it will be treated as an accounting detail |
| Does a repricing require re-acceptance? | June says acceptance has an interval, so a repriced policy is arguably a new one |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 18 Jun | `v0.33.40__arch-brief__sg-send-risk-acceptance-underwriting-flows-upward-cross-domain-the-risk-already-exists.md` | The underwriting pillar this continues, including the risk existing at provisioning and acceptance flowing upward |
| 6 Aug | `v0.33.56__arch-brief__sg-send-token-gateway-resale-prohibited-in-line-forced-append-and-settle.md` | The append-and-settle ledger with negative balances and a policy cutoff, generic on unit type, needed here unchanged |
| 26 Aug | `v0.33.62__dev-brief__the-permissions-file-exists-and-the-mandate-file-does-not-generate-the-grant-by-measurement-adopt-cedar.md` | The hook as enforcement point, and the drift feed that reprices a policy |
| 24 Jul | `v0.33.51__strategy-brief__sg-send-who-can-pull-the-plug-ability-to-stop-an-ai-system-fractal-maturity-model-detection-authority-blast-radius-reversibility-intersect-in-time.md` | Recoverability as a first-class dimension, which decides what may be insured |
| 28 Jul | `v0.33.53__strategy-brief__sg-send-accepted-is-not-acceptable-orthogonal-axes-appetite-renamed-article-9-mandates-judgement-without-defining-it.md` | The test that a risk carries a named acceptor and an interval, which a draw satisfies |
| 2 Aug | `v0.33.55__arch-brief__sg-send-end-to-end-worked-example-article-26-5-creditworthiness-agent-fact-to-board.md` | The unaccepted risk escalating without an escalator, which the third zone inherits |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The underwriting framing is from 18 June and is filed under agentic permissions, so this continues it rather than replacing it |
| 2 | What is added is the unit of payment and a claim that settles without a person |
| 3 | The premium is the opportunity cost of an allocation from a finite pool, paid at issue |
| 4 | Premium and claim share a denomination, which makes capital allocation a closer analogue than insurance |
| 5 | The scarcity is the feature, because a pool nobody can exhaust produces no decisions |
| 6 | Pooling makes a shared buffer far cheaper than the sum of every team's worst case |
| 7 | Pooling assumes independence, and agent draws are correlated through shared models, templates and dependencies |
| 8 | So the pool fails by exhausting at once, and the control is a reserve the automatic mechanism cannot reach |
| 9 | Moral hazard is managed by experience rating, and the rating must land on the team because the agent is indifferent |
| 10 | A draw is an acceptance event whose acceptor is the policyholder, not the agent that spent |
| 11 | Recoverability decides insurability, so a hard cap on an irreversible cost is an exclusion rather than a limit |
| 12 | Claims settle instantly because the event is the meter reading, so a policy may only use units the system already counts |

---

## Sources

- The vendor's published repository limits, giving a recommended maximum file size of one megabyte, a hard limit of one hundred megabytes, a recommended on-disk repository size of ten gigabytes, and stating that large repositories slow fetch operations and increase clone times for developers and continuous integration: https://docs.github.com/en/repositories/creating-and-managing-repositories/repository-limits
- The published cost management framework distinguishing showback, which exposes costs at any granularity and is described as always required in the practice, from chargeback, which formally integrates costs into accounting so that each profit-and-loss owner bears financial responsibility for what it consumes and which is described as not always required: https://www.finops.org/framework/capabilities/invoicing-chargeback/
- The 18 June underwriting brief establishing that accepting is underwriting rather than predicting, that the risk exists the moment the permission is provisioned, that accountability attaches at the click, and that acceptance flows upward with each level underwriting; the 6 August ledger specification with appended usage, a derived balance permitted to go negative, a cutoff as per-customer policy, the negative threshold described as an accepted risk with a stated level, a named owner and a review interval, and a requirement that the ledger be generic on unit type from the first version; and the prior corpus treatment of error budgets as a roll rate made explicit and planned for, alongside near-miss frequency and normalisation of deviance as leading indicators measurable before an incident: the project repository, cloned and searched on 20 and 26 August 2026, with the documents named in the relationship table above

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).