# The Claim Is The Draw: Money As A Metric, And A Push Budget Claude Can Run Today

**version** v0.33.84
**date** 2 September 2026
**from** Human (project lead)
**to** Strategy, the RiskMandate team, the registry site

**type** Strategy brief — memo 12, and the first memo that ships a working thing

*Produced from a voice memo of 2 September 2026, carried verbatim below and then read against the corpus by the site agent. Everything in the transcript is the project lead's; everything under the reading is the site agent's and is labelled as such. **This memo asked for something operational, so this brief is the first in the series with a build behind it**: `insurance/push-policy/`, a policy document, a checker, a ledger and a skill, run against this estate's own history before anything was written here. §6 is what it found.*

---

## What This Is

Two halves. **The first is a reframe: the money in an insurance policy is a metric, a stand-in for what the claim is actually used for — so in this model claims are paid in the resource itself: tokens, access grants, bandwidth, bytes — with the amount pre-approved, which is why claim decisions here settle in milliseconds where a carrier takes weeks; the abstraction layer between the money, the authorisation and the item is what makes the workflow efficient, and the memo argues that ordinary insurance would be faster too if what is insured, what triggers, what is paid and what is excluded were mapped as clearly.** The second half is a worked policy to operationalise now, through a skill, with Claude managing it: a developer's agent is normally authorised to push to its own branch five to ten times a day and to dev three times, with a pool of twenty (or fifty) and ten beyond that; and on size, fifty kilobytes per push is normal, no push may exceed three hundred, and a megabyte a day is the buffer — a draw from the pool is allowed, and when the pool is spent no agent may push until it refills. It is the second document of 2 September (cross-ref: v0.33.83 the resource pool, doctrine 07's policy as a statement, doctrine 10's per-action gate, GM-D93's excess-of-loss structure). New contributions: **the claim as the draw, the millisecond claim, and the first MVP.**

## The Memo, Verbatim

*Transcribed by otter.ai; carried whole, exactly as received. The first fragment is the transcript's own false start, kept because the rule is that the transcript is not edited.*

> **Unknown 0:21** policies and insurance model that we're using for voice debrief, and kind of start with the idea that if you think about it, the the money element of an insurance ultimately is sort of a metric, right? Because what we should be basically saying is, what is that money? money used for, right?
>
> **Dinis Cruz 0:08** Okay, so what I want to zoom in is on the idea of the insurance policies and insurance model that we're using for voice debrief, and kind of start with the idea that if you think about it, the the money element of an insurance ultimately is sort of a metric, right? Because what we should be basically saying is, what is that money? money used for What is the money used when you get the claim, right? So in a way, what is the claim money that we have? And in a way, what we're doing is we are kind of creating that abstraction layer. So we're basically saying that insurance money is paid using tokens, is paid using access grants, is paid using bandwidth, right? That's what we pay. Then what we're doing is we pre-approve the the amount that gets paid. So I think it'd be really interesting to map this out from a point of view of using pure insurance terms and definitions, including the fact that if you take into account, you know there is a financial cost for abuse of this. So there's a financial cost of tokens that get used as a financial cost of, for example, uploading more files with bigger size than they should be on GitHub, which is the example I'm going to talk next, because that is now a cost that is going to be paid continuously by every developer, every push, which basically will slow down the whole process, right, and ultimately bandwidth and time on money, right. So I think the analogy that we have is actually quite interesting. Also because we have we have this flow of of actually creating an abstraction layer between the money and the authorization, and the actual item, and in fact, I would argue that this actually makes everything much more smoothly because, if even on normal insurance, if you can have very clear mapping on what we are insuring, what are the events that trigger, and what are we paying for, and what's covered and what's not covered, in principle, you could have claim decisions made in minutes, right? Or even as we we get given here, claim decisions that are made in milliseconds, right? Seconds, right? Which is kind of the workflow that we're having. So I think what we're just doing is optimising the insurance workflow, based on this efficient claim. So, so that's I think a concept, and I think it's worth capturing in itself. And I think the second part of this is let's use two examples, which I can operationalize right now, and maybe let's try to do this end to end as a flow, because I think this is one of those cool examples that actually will have most of the piece of the puzzle in there, and will allow us to use it straight away with the agents that we have. Which is literally, I think, one of our key requirements is that we need to get to a mode where everybody that we show this can even really start using it, and the key of doing this is through a skill, right? So we need to create a skill that does that, and actually let, for now, let the agent Claude manage this because I actually think Claude will play this really well. So here's the concept, right? The concept is when I'm working, and I literally had this problem a couple of minutes ago, which is, I want to make sure when I work with my Claude agents, I give Claude, in a way, a budget, sort of an insurance policy, right, for pushing to pushing to the to the to their own branch, and pushing to the dev branch, and and the logic here is that I would probably say the developer is only normally authorised to push to his own branch, let's say five times a day, or 10 times a day, and push to the dev branch three times a day. But we have an insurance policy of, let's say, a bucket of 20 or or 50 commits for their branch, and maybe 10 for the for the dev branch, and what we're basically saying is that it's okay to for the agent to go over, but it then triggers the insurance policy, right? And the logic is when the insurance runs out, the developer now is acting out of so the agent is running out of policy and has to stop, cannot commit anymore, and where this becomes a much better example is the size of the files being committed. So what we're basically saying is that we let's have a policy, and of course this then has feedback loops and stuff like that. We learn right, but let's have a policy that says that normally most commits are authorised to Say 50k or 50k per pop, right? 50k per updates. But we have a megabyte of budget, and actually we also have a requirement that no commit should be more than, you know, 300k, right? For example, and that means that the we have this one megabyte buffer that could be used. It could be drawn from insurance policy as long as everything's operating normally. And but if we have an agent that wants to do more than 300 mega 300k, or after three or four agents use 250k each, then we don't have a policy anymore. And again, no agent can commit anymore. So let's map this out as a set of workflows because I think it can work really nicely end to end.

One transcription artefact, flagged rather than repaired: *"voice debrief"* in the opening sentence is almost certainly **the pivot brief**. And one discrepancy inside the memo itself, recorded rather than smoothed: the per-push maximum is *"300k"* in the memo and *"250k"* in the project lead's message of the day before; the policy takes the memo's figure and says so.

## The Reading — the site agent's, from here down

### 1 · The claim is the draw

The first half of the memo finishes a thought [doctrine 11](../insurance/the-resource-pool.html) started. That document said a token pool is *risk pooling in a currency that is not money*. The memo says what the currency *is*: **the money in a policy was always a proxy for what the claim buys, so pay the claim in the thing itself.**

Which makes the mechanics fall out in one move:

| In insurance | Here |
|---|---|
| A loss occurs | A push is over the normal band |
| A claim is filed | The check runs |
| The claim is adjusted | A subtraction: excess against pool |
| The claim is paid, in money | **The excess is drawn from the pool, and the push proceeds** |
| The claims file | The ledger |

> **A draw on the pool is a claim, paid in the resource, settled by the check itself.** There is no separate payment step because the payment *is* the permission to proceed.

That is why the memo can say *milliseconds* without exaggerating. A carrier's claim takes weeks because the trigger, the cover and the payment are three parties' documents reconciled by people. Here they are three fields of one document read by one function. **The memo's argument that ordinary insurance would be faster with the same clarity is right, and it is also the argument for why this stage needs no carrier**: nothing here waits on anyone.

### 2 · What the memo adds to doctrine 11

Doctrine 11 named the excess-of-loss structure and said the memo before it had left out the per-occurrence limit. **This memo supplies all four parts, twice**, for two resources:

| Part | Pushes, own branch | Pushes, dev | Bytes per push |
|---|---|---|---|
| Deductible — the normal band | 10 a day (memo: "five or ten") | 3 a day | 50 KB |
| Per-occurrence limit | — | — | **300 KB** |
| Aggregate — the pool | 20 (memo: "20 or 50") | 10 | **1 MB a day** |
| Interval | a day | a day | a day |

And one thing doctrine 11 argued for and could not show: **the pool is shared.** *"After three or four agents use 250k each, we don't have a policy any more"* — the pool is per repository, not per agent, so every agent pushing to it draws from the same megabyte. The ledger lives in the repository, which is what makes it shared. That is the correlated-spike case from doctrine 11 §3 with a mechanism, and it makes doctrine 11's shared-fate warning **deliberate policy**: when the pool is out, nobody pushes. The per-occurrence limit is what stops one agent spending it alone.

### 3 · "Let Claude manage this" is the honest tier, and it is the first rung

The memo asks for a skill, and for Claude to run it. Read against [doctrine 05](../insurance/not-in-line.html): a check the agent runs on itself, against a ledger the agent can edit, is a **setting** — the second of three tiers, above an expectation and below a boundary. **The skill says so on its own face**, as GM-D42 requires of any gate.

What would make it a boundary is not a better skill. It is *the same check run by a party the agent cannot reach*: a required CI status on the branch, or a push rule on the host. Both take the same `policy.json` and the same arithmetic. So the skill is not a compromise; it is the first rung of a ladder whose upper rungs already have a shape.

### 4 · Feedback loops: the ledger is the loss data

*"This then has feedback loops and stuff like that, we learn."* The ledger the check appends to is exactly the data [doctrine 11 §4](../insurance/the-resource-pool.html) said the pivot had never had: dated, quantified, attributable, independently measured by git. **The numbers in the policy are placeholders until the ledger has enough entries to re-fit them** — and the first fit is already available, because the tool can replay history.

### 5 · What was built

`insurance/push-policy/`: the policy as a mandate-shaped document, a checker that measures what git would send and returns one of three verdicts, an append-only ledger, a sample pre-push hook, a README that says what it does not prove, and a skill at `.claude/skills/push-policy/` that tells Claude to run the check before any push and to stop when refused. The measurement is the uncompressed size of new objects — a floor, as the grant rule prefers.

### 6 · What the policy said about this estate, before anything was written here

The checker can replay a branch's history as if each commit had been a push. Run against the last twelve releases on `dev` before this brief existed:

| Release | Bytes to push | Verdict |
|---|---|---|
| v0.1.53 – v0.1.60, 31 Aug | 3.0 – 3.8 MB each | **refused**, 10–12× the per-push maximum |
| v0.1.61, the insurance book | **13.1 MB** | refused, 43× |
| v0.1.62 – v0.1.64, 1 Sep | 4.2 – 4.7 MB each | refused, 14–15× |
| *Two non-release commits, 25 Aug* | 30 KB · 114 KB | normal · **drawn**, 63 KB from the pool |

**Twelve of twelve releases refused.** Eight of them on one day, which would have drawn five from the dev push pool as well. The cause is not the content: it is `chrome.py`, which stamps the version into every page on every release, so a one-line change ships 180 changed files. **The first thing the policy found was that the estate's own release mechanism breaches it every time.**

Two readings, and the memo's own words pick one. Either the numbers are wrong for a site that regenerates itself, or the release mechanism is wasteful. *"That is now a cost paid continuously by every developer, every push"* — the memo is describing exactly this, and the memo is right: re-stamping 180 pages to change a version string is the 25 MB push in slow motion. **The policy is not mis-calibrated. The estate is.** The hook is therefore shipped and *not installed*: installing it today would block every release until the release stops touching every page, which is a change worth making and a separate one.

### 7 · The measurement, and what it is not

Bytes are counted before the push as uncompressed sizes of objects not on the remote. git packs and compresses on the wire, so the real transfer is smaller — often much smaller for text. **The number is a floor on what the agent is asking to send, not a bill.** A policy that wants wire bytes needs the host's meter, which is the supplier's boundary (doctrine 11 §5) and not this estate's to read.

## Decisions This Implies (proposed into change control)

| # | Decision | Status |
|---|---|---|
| GM-D97 | **A draw on the pool is a claim, paid in the resource, settled by the check itself.** The payment is the permission to proceed; the ledger is the claims file | Proposed — finishes GM-D88 |
| GM-D98 | **A claim settles in milliseconds when trigger, cover and payment are fields of one document read by one function.** The speed is a property of the mapping, not of the software | Proposed |
| GM-D99 | **The pool is per repository, shared by every agent pushing to it**, because the ledger lives there. Pooled fate is policy, not accident; the per-occurrence limit is what stops one agent spending it alone | Proposed — gives GM-D93 its mechanism |
| GM-D100 | **A skill that runs the check on the agent itself is a setting and says so.** The boundary is the same policy and arithmetic run by a party the agent cannot reach: a required CI check or a host push rule | Proposed — GM-D42 applied to the first MVP |
| GM-D101 | **The ledger is the loss data.** Policy numbers are placeholders until re-fitted from it; the checker's replay of history is the first fit | Proposed — makes GM-D89 concrete |
| GM-D102 | **Bytes are measured before the push as uncompressed new objects — a floor, never a bill.** Wire bytes belong to the host's meter | Proposed |
| GM-D103 | **A release that touches every page is a policy breach in slow motion.** The version stamp on 180 pages is the reason twelve of twelve releases were refused; the fix is in the release, not the policy | Proposed — **the MVP's first finding, and it is about this estate** |

## Open Questions, The Project Lead's

1. **Install the hook, or fix the release first?** Installing today blocks every release. The release could stamp the version in one place the pages read at load time, and ship only what changed. Your call which comes first.
2. **250 KB or 300 KB?** Your message said one and the memo the other. The policy took the memo and can take either.
3. **Whose branch is "own"?** The policy treats anything not named `dev` as an agent's own branch. A `main` policy does not exist yet, and it should be stricter than dev's.
4. **Pushes or commits?** The memo says both. The checker counts pushes, because that is where git meters bytes; a commit-level budget is a different hook.

---

*CC BY 4.0. Sources: the project lead's voice memo of 2 September 2026, twelfth of the series (verbatim above); v0.33.71–83; doctrine 05, 07, 10 and 11; `insurance/push-policy/check.py --backtest 12 --ref origin/dev`, run before this brief was written. Everything below the transcript is the site agent's reading and says so — including §6, which is a measurement of this estate and not a position.*