# Who Pays For The Delta Nobody Chose, And The Rating That Moves Overnight

**version** v0.33.74
**date** 30 August 2026
**from** Human (project lead)
**to** Strategy, the RiskMandate team, the registry site

**type** Strategy brief — memo 3 of 8 on the insurance pivot

*Produced from the third of eight voice memos recorded on 30 August 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. The memo's worked example is this estate's own, which made one claim in it checkable against the published twin — and the check failed in the estate's favour as a finding: **memo 3 names a grant node this estate's own measurement does not have.** That is recorded in §1 rather than quietly fixed.*

---

## What This Is

The accountability question the first two memos deferred: **the memo asks who is actually insured and who pays, working it through the GitHub example this estate already publishes — a code host offering only read-only or read-write, so an operator who needs to push at all must confer the ability to push to every branch and to author commits as anybody; it separates two policies exactly where the corpus separates two covers, one for what can go wrong inside the mandate and one for what can go wrong outside it, and then asks the question nobody has asked: the delta outside the mandate exists because the platform offers no finer grain, so is it GitHub who pays, or the customer, or the service provider, or the model vendor underwriting its own hallucinations; it raises the zero-day case, where a defect in the platform temporarily widens the grant beyond its documented shape into repository settings and visibility, and asks who covers capabilities nobody knew were conferred; and it lands on the idea the corpus has not had until now, that a rating should move dynamically — a vulnerability lands, the damage the agent can do multiplies, and the policy re-prices within the hour, which lets the business decide whether the value still justifies the risk, pull the plug for an hour or a week, or buy temporary cover to keep operating in a heightened state.** It is the fourth document of 30 August (cross-ref: v0.33.71–73, the v0.33.60 service-twin brief, and the estate's own library entry for the CCR container). New contributions: **the delta classified by who could have closed it, the broker as a market participant whose value is measurable, dynamic re-rating separated into twin and world state, and the temporary-cover workflow.**

## The Memo, Verbatim

*Transcribed by otter.ai; carried whole, exactly as received.*

> Okay, so now I want to sort of capture the interesting dynamics at play when you have, especially on agentic insurance or agentic worlds, where you have multiple parties at play and multiple providers at play, and who is actually accountable for what, and who will take the insurance element of of what, and who you actually insuring? So let's take an example of the the GitHub example of the and let's say there's a competitor to GitHub, right? Which is basically one which will you know let's call it lockdown GitHub. Or actually, there's a broker. Sorry, there's a broker service, right? That facilitates access to GitHub in a sort of privilege, more more more privileged granularity way, right? So take the example of I give GitHub access to one of my agents, and right now my only options is to give it read only or read write. Right, I don't have more granularity than that. Right, so so let's say I have to give it read write because I wanted to push changes to a repo. So what what this means it means that now you have a situation where you have you have an agent that can now push to all branches by default of a GitHub repo and can actually pretend to be anybody when he commits because you know, doesn't have, you know, sign commits in a lot of ways, or at least, you know, unless you have that set up, right? And but let's focus on the branches, right? So you can commit to any branch. So, so that's one element. So that in this case, that's what we call the grant of this, right? And and then you have a situation where we want I only want Git to commit to either its own branch that gets created when the agent starts, or or I can expand the mandate to, for example, say, "Hey, okay, I also want you to push to dev, but that's kind of it, right? I don't want it to push to any other branches, and I definitely don't want it to push to main because let's say in this case main will actually ship to production where dev will ship to a dev environment right so so now let's think about the insurance elements of here right so so we have in a way and I want to focus here now first not on what can happen with actually pushing what the dangers of pushing to the authorised one, i.e. the mandates, which is another thing, but I want to focus on the risks that exists outside the main and who's accountable for those. So we can turn around and say, well, we have an insurance policy here that basically covers the the risks that happens on the mandate, right? But we have an insurance policy that covers the dangers that can happen when you push outside of that, right? So when although we gave the agent the mandate to do what's it called to do to push to dev? Let's say the agent can also push to main, and so now the interesting question here, first of all, is that is an understandable problem today. It's an understand limitation of GitHub, right? So from a policy point of view, we want to insure against that problem. Who you know who's paying for that policy? Is it GitHub? Is it the customer? Right? You know who's who's covering that? Right? Is the service provider that's involved? There's a number of interesting. Is Claude that actually owns that risk, right, or or underwrites that, you know, is Claude going to actually have a policy on its own to cover any mistakes? And then remember that then you have the problem of hallucination, right? So, if again the agent was not supposed to push to main and push to main or push to another branch, causes havoc, right? Who who pays for that, right? Like, who's responsible for that hallucination, right? And who's in the controls? So that's one interesting element of this. But the other interesting element is, let's say that there is a zero day or vulnerability on GitHub itself, and in addition to being able to commit to dev or main, we can even make changes to the repo. We change some security properties, can you know change some other things that have security implications, or make the repo public instead of private, right? Because remember, that's a control on the other side. Like again, who's who ensures that, right? Who insures, and who who covers that liability, right, for those extra capabilities, and and this is where I think insurance becomes quite interesting because we can quantify this stuff, right? We can quantify the cost of these things, and even like, if you think about like even dynamically, which I think is very important, right? As we move into this sort of dynamic world, we we can have insurances that change dynamically based on what's happening. So let's say that in this example, there's suddenly a zero day that allows GitHub. There's a vulnerability on GitHub that allows Git, you know, any repo, any agent to now do a lot more damage on GitHub, right? Or even maybe access other GitHub accounts, right? Ultimately, it's your agent, it's the company's agent who's doing all that stuff, right? So we, you know, immediately the insurance here could change, right? It could change overnight, could change in an hour or in half an hour. You could now say, hey, hold on, the insurance policy for you now running this agent has just gone 10x because the damage the agent can do now we for this period of time why this zero day exists or why this understanding exists is now 10x and this then allows the business to make a decision allows the business to say hey is the money that we're making with the agents, you know, or is the value that we're getting from the agents enough to justify this risk, or do we pull the plug, right, temporarily, or do we pull the plug for a week or a month or a day or an hour, right, until this gets recovered. So this is the thing that's very powerful because, in a way, you know this exchanges. Or do I need to go to market and buy a new insurance temporarily for a couple of hours, a couple of days, right, in order to to to continue to operate in this heightened risk state, and that's that's that's why it's so powerful. This sort of dynamic possibility, right, and this ability to to connect risks to business. Because, like I said, ultimately what we're allowing is to allow the business to make good business decisions, right? We're allowing the business to be able to fundamentally Make decisions based on on what's going on, and and this is I'm saying that it's a it's a really cool workflow to to implement.

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

### 1 · The example is ours, and the memo names a node our own twin does not have

The memo's example is the one this estate has published, measured and enforced against, which makes it checkable. Two claims in it, checked:

**"push to all branches by default" — confirmed.** The published twin for this container records node `n3`, *"push commits to the attached repository"*, and states in its own text that *branch discipline lives in the session's instructions* — which is precisely the memo's point: the credential does not know what a branch is.

**"can actually pretend to be anybody when he commits" — correct, and we do not measure it.** Git's author and committer fields are free text; absent signed-commit enforcement, a push credential confers the ability to author commits under any name and address. That is a distinct capability from pushing, with a distinct blast radius — attribution, not availability — **and there is no node for it in either library entry.** The twin has nine nodes; none is about authorship.

> **Finding: memo 3 names a grant node this estate's own measurement misses.** The rule is that a grant is discovered, not authored, and the discovery instrument has a hole in it. Recorded here rather than quietly patched, because the interesting fact is not the missing node but that *a five-minute conversation found what the tool did not* — which is the honest limit of `measure.py` showing itself, and an argument for the measurement being reviewed by people who know the platform.

### 2 · Two policies, arrived at twice

The memo separates cover for *"the risks that happens on the mandate"* from cover for *"the dangers that can happen when you push outside of that."* [The pivot briefing](v0.33.71__strategy-brief__insurance-for-agents-the-delta-is-where-the-insurance-lives.md) split cover the same way and called them A and B. **Two independent derivations of the same split is evidence the split is real**, and worth recording as such rather than as a repetition.

### 3 · Who pays — and the answer is a taxonomy, not a party

This is the memo's hard question and it has a clean structure hiding in it. The memo supplies the key itself: *"that is an understandable problem today. It's an understandable limitation of GitHub."*

**The operator did not choose that delta and cannot close it.** No amount of care, budget or diligence lets a customer make GitHub offer branch-scoped tokens. Charging the operator for it is charging them for somebody else's design decision — and a rating that does so is not measuring their risk management, it is measuring their vendor's roadmap.

So the delta divides by **who could have closed it**:

| Class | What it is | Could the operator close it? | Whose it is |
|---|---|---|---|
| **Elective** | The operator conferred more than needed, or skipped an available control — no branch protection, no signed commits, a token scoped to every repo when one would do | **Yes** | **The operator's.** This is the part a rating should charge for, because it is the part effort moves |
| **Structural** | The platform's finest grain is coarser than the mandate — read-write or nothing | **No** | **The platform's**, or nobody's. Present in every customer's estate simultaneously |
| **Defect** | A vulnerability temporarily widens the grant beyond its documented shape — repo settings, visibility, other accounts | **No, and could not have known** | **The platform's**, and *temporary* — which is what makes §5 necessary |

**Three consequences follow immediately.**

**A rating that does not separate these is unfair and useless in the same move.** Unfair, because it charges for the unfixable; useless, because a level an operator cannot move is not a decision input. Memo 2 required the derivation to decompose so a team can be told *reduce by this much*; **this is the sharper version of that requirement — the decomposition must separate what they can move from what they cannot.**

**It gives structural delta a natural payer, and it is not a party — it is the aggregate.** Every customer of a coarse platform carries the identical exposure. That is the textbook shape of a **pool**: a risk nobody can individually avoid and everybody shares. It is also, uncomfortably, the shape of an argument the platform should be making to itself.

**And it makes the platform's granularity a rating input in its own right** — which is the market signal the memo is circling. A platform offering branch-scoped tokens would move a whole class of delta from structural to elective for every one of its customers at once. *That* is quantifiable in this estate's terms: how many placements' structural delta the change converts.

### 4 · Platform granularity belongs in the library, not the instance

Here the estate's existing split does real work. **How coarse GitHub's permissions are is a fact about GitHub**, identical for every customer. It should be measured once, published once, and referenced by every placement — never re-derived per estate.

That is exactly [the library/instance rule](../packs/grant-and-mandate/library.html) (GM3): the registry holds the public library carrying no personal data; the instance holds references, never copies. **A platform-granularity library is the same object as a grant library, one level up** — and it is the fractal the memos keep pointing at, in a form that is buildable rather than aspirational.

It also has a property worth naming: it is **the only part of this rating apparatus that is a public good.** One measurement of GitHub's permission model serves everybody. That is a genuine argument for publishing it here rather than holding it in a product.

### 5 · The broker becomes a market participant, and its value becomes measurable

The memo names *"a broker service that facilitates access to GitHub in a more privileged granularity way"* — which is [the execution broker](v0.33.60__arch-brief__service-twin-agent-never-holds-the-credential-closes-the-authorised-misuse-boundary.md) the corpus designed in August, arriving from a completely different direction. Designed then as a security control; named here as a **product somebody sells.**

And §3 gives it a price tag: **a broker's value is exactly how much structural delta it converts to elective.** Before: the platform's finest grain is read-write, and you cannot narrow it. After: the broker interposes, holds the credential, and enforces a branch constraint the platform would not — so the delta becomes something you *chose* to leave open or closed.

**That is the first commercially legible statement of what an execution broker is worth**, and it is computable in this estate's terms rather than argued. The service-twin brief's own warning still stands and gets sharper here: the broker holds usable credentials, so it becomes the highest-value target in the estate — **which means the broker needs its own rating, and it is the one placement where a bad rating is systemic.**

### 6 · Dynamic re-rating: what has to be true for it to work

The memo's most exciting idea, and it has requirements it does not name. Stating them is not a rebuttal — it is what makes it buildable.

**The twin does not change when a zero-day lands.** The measurement recorded what it recorded; the credential still reaches what it reached. What changes is **what that reach is worth** — the world, not the placement. So:

> **rating = f(placement twin, world state, mandate)** — and the twin and the world have **independent freshness**.

That separation is the architectural contribution. The estate already prints twin age on every evidence pack; a dynamic rating needs a **second age**: *how current is our picture of the world?* A rating computed against a six-day-old twin and a three-minute-old vulnerability feed is a different object from one computed against both stale, and only saying so keeps it honest.

What it requires, listed plainly because none of it exists here:

| Requirement | State |
|---|---|
| A feed of platform-affecting events (advisories, incidents, vendor notices) | Does not exist in this estate; the inputs are public |
| **A mapping from an event to which grant nodes it widens** | **Does not exist anywhere**, and is the hard part — CVE feeds describe software, not capability trees |
| A re-rating trigger and a notification path | Does not exist; mechanically small once the above do |

The middle row is the real work. *"GitHub advisory X widens node n4 from in-scope-repositories to all-repositories"* is a judgement somebody has to make and record. **It is a library artefact** (§4) — made once, used by everyone.

### 7 · The 10x, and what can honestly be said instead

> the insurance policy for you now running this agent has just gone 10x

**The magnitude is not computable and will not be for years**, because it requires loss data that does not exist for anyone. A rating engine printing "10x" would be false precision of exactly the kind this estate refuses everywhere else.

**But the direction and the mechanism are computable today**, and they carry most of the decision value:

- *"This placement's grant now reaches repository settings and visibility, which it did not yesterday"* — a node count and a named capability.
- *"A control that was a boundary is now defeated"* — a tier recomputation, which the workbench already does.
- *"Two mandate constraints are now unenforceable"* — a mandate-versus-grant recomputation.

**So a dynamic re-rating states what changed, which way, and which controls are implicated — never a multiplier.** An operator asked *"is the value still worth it?"* is better served by *"your agent can now change repository visibility"* than by *"10x"*, because the first is actionable and the second is a number they cannot check.

### 8 · Pull the plug is a gate that closes on something already running

Memo 2 made the rating a gate on go-live. **Memo 3 extends it to a continuous obligation** — *do we pull the plug, for an hour or a week* — and that is a harder object. A go-live gate evaluates at a decision point; a running-agent gate must evaluate on world events, when nobody is asking.

The estate already owns the mechanism at the other end. **A mandate is revoked by an append to the issuer's record** — a signed statement with an effective date, never a deletion — and the register publishes a fixture demonstrating exactly that. So:

> **A rating crossing a threshold can emit a revocation**, and the enforcement path from revocation to a refused push already exists and has been demonstrated.

That is the full loop the memo is describing, and every piece of it except the world-state input is built. It is also where the tier question from memo 2 becomes acute: **a "pull the plug" that emails somebody is an expectation; one that revokes a mandate the agent's own hook honours is a setting; one the agent cannot reach is a boundary.**

The memo's alternative — *"go to market and buy a new insurance temporarily for a couple of hours"* — is the same event with the opposite response, and it is genuinely how catastrophe markets work. In stage 1 with no money it has a direct analogue: **a time-boxed exception, recorded, that expires by itself.** Which is a mandate with a short interval, and the estate has those.

### 9 · Hallucination liability: the estate can make the question answerable without answering it

> who's responsible for that hallucination, right? And who's in the controls?

**This is unsettled law and this estate should not pretend otherwise.** Whether a model vendor, an operator, or a deploying business carries loss from an agent acting outside instruction is being worked out in courts and contracts, not in a registry.

But there is something precise to contribute, and it is the estate's whole existing output: **any liability determination needs to know what happened, under whose authority, against which mandate, with which controls in place — and that is an evidence pack.** The estate cannot say who pays. It can make the question *answerable* rather than a swearing contest, which is what the parties actually lack today.

On *"is Claude going to have a policy of its own"*: model vendors currently disclaim liability in their terms, so today the answer is no. Worth noting only that **a vendor offering such cover would be making a falsifiable quality claim**, which would be a real market signal — flagged as speculation, because it is.

## What This Changes

| Position | Status after memo 3 |
|---|---|
| The rating charges for the delta | **Corrected**: only the *elective* delta is the operator's. Charging for structural delta rates a vendor's roadmap, not a customer's diligence |
| GM-D44: the derivation decomposes | **Sharpened**: it must separate what the operator can move from what they cannot, or the gate is unfair and useless at once |
| The library holds measured grants | **Extended**: it should also hold **platform granularity** — measured once, referenced by all, and the only genuinely public-good part of this apparatus |
| The execution broker is a security control | **And a product**, whose value is exactly the structural delta it converts to elective |
| The rating is a function of the twin | **Wrong as stated**: it is a function of the twin **and the world**, with independent freshness. Dynamic re-rating changes the world input |
| `measure.py` discovers the grant | **Holed**: it does not measure commit authorship, which memo 3 named in passing |

## Decisions This Implies (proposed into change control)

| # | Decision | Status |
|---|---|---|
| GM-D45 | **The delta is classified by who could have closed it** — elective (the operator's), structural (the platform's finest grain), defect (a vulnerability, temporary). Only elective delta is attributable to the operator | Proposed — the memo's accountability question, answered as a taxonomy |
| GM-D46 | **Platform granularity is a library artefact**, measured once and referenced by every placement — a fact about the platform, never re-derived per estate. The one public good here | Proposed |
| GM-D47 | **rating = f(twin, world state, mandate)**, and the twin and the world carry **independent freshness**, both printed | Proposed |
| GM-D48 | **A re-rating states what changed, which way, and which controls are implicated — never a magnitude multiplier**, until loss data exists | Proposed |
| GM-D49 | **A rating crossing a threshold may emit a revocation**, which the register already carries as an append and the hook already enforces. The "pull the plug" path, and it declares its tier | Proposed |
| GM-D50 | **`measure.py` gains a commit-authorship node.** A push credential confers authorship under any name absent signed-commit enforcement; the twin has no node for it | Proposed — a defect in the measurement, found by memo 3 |

## Open Questions, The Project Lead's

1. **Does structural delta appear in the operator's rating at all** — shown but not charged, or excluded entirely? Showing it is honest and may be discouraging; hiding it is neither.
2. **Who measures platform granularity, and where is it published?** §4 argues it is a public good and belongs in the library here. That is a business decision as much as a technical one, because it is also the moat.
3. **Where does the world-state feed come from?** The event-to-grant-node mapping (§6) is the hard part and does not exist anywhere. It is also, plausibly, the most defensible asset in this whole pivot.
4. **Shall `measure.py` be fixed now** (GM-D50)? It is a small change, it makes the estate's own twin honest about a capability it confers today, and it is a good demonstration that the discovery instrument is itself reviewable.

---

*CC BY 4.0. Sources: the project lead's voice memo of 30 August 2026, third of eight (verbatim above); [v0.33.71](v0.33.71__strategy-brief__insurance-for-agents-the-delta-is-where-the-insurance-lives.md), [v0.33.72](v0.33.72__strategy-brief__insurance-without-money-first-the-rating-is-the-product-and-micro-policies-scale.md), [v0.33.73](v0.33.73__strategy-brief__the-ecosystem-without-the-money-insurance-as-a-go-live-gate.md), [v0.33.60](v0.33.60__arch-brief__service-twin-agent-never-holds-the-credential-closes-the-authorised-misuse-boundary.md); the CCR container library entry, whose nodes were re-read to check §1. Everything below the transcript is the site agent's reading and says so.*