# The Policy Is A Signed Statement, And The Relying Party Is The Boundary

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

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

*Produced from the seventh of eight voice memos, 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 supplies the boundary the pivot could not previously reach.** [Memo 5](v0.33.76__strategy-brief__not-in-line-the-schemas-are-the-product-and-the-scale-is-one-to-five.md) established that a party outside the line can never itself be a boundary; memo 7's handshake relocates enforcement to the relying party, who is definitionally outside the agent's grant. It also re-derives, independently, a sentence this corpus published on 27 August — noted in §4.*

---

## What This Is

How it works in practice, using primitives the estate already has: **the memo makes the policy a signed statement and therefore a thing that can be presented, checked and revoked like any other — so a relying party can refuse to release data until the requester presents an active, certified policy and signs the specific request against it, which the relying party then verifies with a third party; it identifies that verification step as a revenue stream and an observability surface for the policy provider, since checking reveals how often a policy is used, by whom and for what; it restates trust as connectivity rather than as a verdict held in a registry — the question is whether a path exists from a requirement, through a grant, to an action — and makes the structure fractal, since policies may cover policies and an internal policy regime can roll up into one external signature; it makes revocation the removal of a link, with a dynamic clause the memo has been building toward, that a zero day or a change in the threat landscape revokes the policy within minutes and the holder is then outside cover; and it observes that this is already how regulated business works, since without the specific cover you may not trade — which is a mandate to operate rather than a recommendation.** It is the fourth document of 31 August (cross-ref: v0.33.71–77, the v0.33.61 observability brief, the v0.33.63 trust-as-confidence brief, and the v0.33.60 briefing pack). New contributions: **the policy as a mandate-shaped statement, the relying party identified as the enforcement point, verification metering named as both a business model and a hazard, and the operating-licence pattern.**

## The Memo, Verbatim

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

> So this is now one about how this can actually work in practice, right? With a lot of the primitives that we have, and and and this is why, when you when you think about the work we've done, a lot of these dots connect together. Because if you think about it, the if you look back to the PKI and look about who's signing what and who provides the cryptographic signatures and the identities. What ultimately we have here is a policy becomes something that can sign something. So you. So what's cool about this is you can now, for example, say, hey, I'm only going to give you the data if you have a particular policy from an entity that I trust, that is, for example, active and is certified, and that can only be done if you can, for example, you have an active key that is being certified by something else. So, if you look at these practices, that I can imagine a system that before sending data to another system, before calling another system, saying, "Hey, you know, I have here that you have this certification. I have here that you have this policy in place. I have here that you have these controls in place. Can can you sign it for me using this? This is what I want to send you. Can you sign it? And then once he signs it, I can then go and check with another third-party service, which is this is why the insurers and the companies and there's a lot of ecosystem here that's important to have. Then you can sign it off, and then you can check it. So you can start to see that the same logic of the grant and the and and you know when we pivot recently on the whole idea that trust is what you can verify. Trust is is not like the the keys registry, is not providing the source of truth, or no. So it's not has all the you know revocations and all that stuff. It's whether when I need to verify something, there is a path. There's a connection between a particular requirement and a particular grant and a particular action. So in this case, you know, let's say that that particular system has been underwritten by a particular insurance provider. You know, this is the broker or the underwriter, etc. Then I can take the message from that thing, sign, go to the other service, and say, "Hey, is this correct? Which actually creates a revenue stream. Actually, for the the provider also becomes a way for the provider to control how much time is being policy being used, for what kind of uses? Is there any abuses? You know, is there any kind of usage stuff? So there's a lot of interesting, again, verification metrics and observability metrics that can actually drive other types of of business models. But the logic here is that if you look at the graphs that we've been creating, this is the ecosystem. So in a way, the trust becomes through connectivity, right? And of course, meaning through connectivity. In this case, trust through meaning, right? It's like I should be able to connect the dots and follow the dots, in order to really be able to gain a level of trust of a particular policy, because a policy then becomes a signed document, and remember that you might have policies of policies or policies. This thing could be fractal, so you could have a situation where there's a whole policy mode running internally, and at the end of that, that gets signed to the external provider, and then that's what then gets verified for this. So this is again, there's a fractal element of this, that, and you can have some manual processes over there that then get correlated and then again that's the fractal element of connecting the dots. So the point here is that a lot of the stuff that we've been working on all connects here because what we're now introducing is we're introducing sort of like another element, just kind of like the risk mandate acceptance, but we're providing a level of the connection of the dots that allows the the providers to then make good decisions and allows the you know in this case revocation by removing the link right or controlling it says, "Hey, I'm normalising this policy, which actually, for example, means that actually one examples I talked before, which is like when when things changed, you can have a policy that says, "Hey, if there's a zero day discovered here, or if the things change, or the threat landscape change, or the threat provider changed, etc. Within 10 minutes or within an hour, we will revoke access to the policy, right? Which basically means at that moment in time, you revoke the ability to use that policy and the ability to actually use the what's it called? You know, do whatever that policy says you do, and then you are almost like outside of of insurance. And a lot of companies might go, "Well, that is our mandate to operate. Without that, we cannot operate. Which actually, to be honest, is what happens already in a lot of business, where they basically have these modes that if you don't have a specific policy, if you don't have a specific Kind of, you know, insurance at play. You are not able to do business, right? And and again, that's that's pretty cool, right? That's a really great way to operate and to keep the system working and to keep the system efficient in this way. So, and that's why, if you look at the graphs of graphs of graphs that we talk about, that all connects the dots here, right? And that's how we would work in practice. And and our job at Risk Mandate or other businesses that are built around this is to facilitate this, is to connect the dots, is to build the graphs, is to make the connections, is to enable business to actually operate in this sort of insurance-driven mode, and to make good decisions in this, starting with the agents that they're using, and the capability and the grants that the agents actually have, and and that's kind of what we want to map out.

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

### 1 · A policy is a mandate-shaped statement, and the register already holds it

The memo's *"a policy then becomes a signed document"* is more tractable than it sounds, because the shape already exists. Set the two side by side:

| | A **mandate** says | A **policy** says |
|---|---|---|
| issuer | who authorised | who rated / underwrote |
| subject | the agent placement | the same placement |
| scope | capability on resource, with constraints | the level, and what it is contingent on |
| interval | valid from → until | cover period |
| revocation | an append to the issuer's record | an append to the issuer's record |
| signature | raw r‖s over the canonical form | the same |

> **`policy/v0` is a mandate-shaped statement issued by a rater rather than an operator.** Same five fields, same append-only record, same revocation-by-append, same verification walk.

That closes [GM-D36](../packs/grant-and-mandate/change-control.html) — which asked what shape `policy/v0` should take — with an answer that needs **no new register machinery at all**: one more statement `type` alongside `identity`, `mandate`, `acceptance`, `revocation` and `grant`. The estate's [record pages](../registry/index.html) would render it the day it existed.

### 2 · A policy does not sign. Its subject signs, and the policy is what makes the signature mean something

The memo's phrasing — *"a policy becomes something that can sign"* and *"can you sign it for me using this?"* — carries two different mechanisms, and separating them prevents designing a confused object.

- **A policy is signed** — by its issuer, which is what makes it verifiable. Straightforward.
- **A holder signs a request** — proving possession of the private half of the identity the policy names as subject.

**The policy never signs anything.** A key signs; the policy establishes what that key's signature is *worth*. And this corpus already stated the distinction, in the briefing pack of 19 August:

> **"A signature proves possession of a private key and proves nothing about trustworthiness."** Trust is a policy decision made afterwards, and conflating the two is the most likely way to misread any of this.

**Memo 7 is describing exactly that "afterwards."** The policy is the artefact that turns proof-of-possession into a statement about standing — which is precisely the gap the corpus said had to be filled by something other than the signature itself.

So the handshake is three checks, and they are the ones the register already answers:

1. **Is this the subject?** — signature verifies against the identity's published key.
2. **Does a policy name that subject, in force now?** — a statement lookup with an interval and no revoking append.
3. **Does its issuer mean anything to me?** — the relying party's own root decision, which the register deliberately does not make for anybody.

### 3 · The relying party is the boundary — the one this pivot could not otherwise reach

This is the memo's most consequential structural claim, and it resolves something the pivot had recorded as a hard limit.

[Memo 5](v0.33.76__strategy-brief__not-in-line-the-schemas-are-the-product-and-the-scale-is-one-to-five.md) established, from the three-tier test, that **a party outside the line cannot enforce** — so this project can never itself be a boundary, only ship a check that becomes one when somebody in line installs it.

**Memo 7 names who installs it.** *"I'm only going to give you the data if you have a particular policy"* puts the check in the **relying party** — the system being asked for data — and a relying party is, by construction, **outside the requesting agent's grant**. It holds the data; the agent cannot reach into it and disable its policy check.

> **The policy handshake is the first mechanism in this pivot that can reach tier `boundary`**, and it gets there without this project standing in the line — because the enforcement point is the counterparty, not us.

That is a genuinely important result and it should be stated with its condition attached: it is a boundary **only where the relying party is genuinely independent of the requester.** An internal service enforcing a policy check on an agent run by the same team, on infrastructure that team administers, is back to a setting. The tier is a property of the relationship, as always.

### 4 · Trust is a path — and the corpus said it first, four days ago

The memo restates the pivot from the registry as an oracle to the registry as a graph:

> it's whether when I need to verify something, **there is a path**. There's a connection between a particular requirement and a particular grant and a particular action

**The corpus published the same sentence on 27 August**, in the brief on why the registry is not thinking in graphs:

> **"trust is a path and revocation is that path no longer existing"**

Memo 7 arrives at it again from the insurance direction, and adds *"revocation by removing the link"* — which is the same statement about the same object. **Two independent derivations of one sentence four days apart is worth recording**, and it means the policy layer needs no new trust model: it is the model the registry pivot already adopted, with one more node type on the path.

The fractal claim follows without strain. **Policies of policies is a path with more hops** — an internal regime rolling up into one external signature is a subgraph summarised by an edge, which is the estate's own composition rule at a new altitude. And the memo's aside that *"you can have some manual processes over there that then get correlated"* lands exactly on the two-channel rule: manual steps enter as **declared** facts and must be marked, or the roll-up launders them.

### 5 · The ten minutes is a ceiling, not a promise — and the handshake is what makes it real

> if there's a zero day discovered ... **within 10 minutes or within an hour, we will revoke access to the policy**

**The corpus already named the quantity that bounds this**, in the observability brief of 20 August, and it is the sharpest possible check on the claim:

> **revocation in this design propagates only at the rate relying parties check, which makes the interval between a party's checks its effective revocation latency** — computable per party and per mandate before anything is ever revoked.

So a policy promising revocation in ten minutes delivers ten minutes **only to parties who check at least that often**. To a party caching for a day, it is a one-day promise wearing a ten-minute label. **A revocation SLA that does not state a required check interval is not a commitment, it is a hope with a number on it.**

**And memo 7's own handshake is the fix.** A relying party that verifies **on every request** has a revocation latency of one request — the shortest achievable. That is the strongest argument in this memo for the handshake design, and it is one the memo does not make: the handshake is not only how you check, it is **what makes fast revocation mean anything**.

Two conditions remain, and both are already recorded as gaps rather than new ones. The trigger needs [memo 3's](v0.33.74__strategy-brief__who-pays-for-the-delta-nobody-chose-and-the-rating-that-moves-overnight.md) world-state feed and its event-to-grant-node mapping, which **exists nowhere for anybody**. And the ten minutes is a claim about the *issuer's* reaction time, which nothing here measures.

### 6 · Metering verification is a business model and a hazard, and the corpus flagged both

> which actually creates a revenue stream ... a way for the provider to control how much time is being policy being used, for what kind of uses? Is there any abuses?

Real, and the estate's observability design anticipated the whole surface. Three cautions, and the third is the one that would quietly break the system.

**A verification is not a use.** The corpus's own line, and its consequence is stated there too: a resolver walking a chain generates an event with no usage behind it, while a relying party that does not bother to verify generates nothing at all. **So the metric is a verification graph, and the silent case is the dangerous one** — the most valuable output is not the checks recorded but *the parties holding a policy who have never once checked it.*

**Metering means the provider learns who checks what, when.** The corpus settled where such events belong precisely to avoid this: a central check log at the registry *"accumulates who is evaluating whom across parties that never consented"*, whereas a check event written by the checker into the **issuer's own lane** is an owner observing their own asset. A policy provider metering verifications is building the first shape unless it is deliberately built as the second.

**And pricing a check discourages checking.** If verification costs money per call, rational relying parties cache, batch and skip — which raises revocation latency, which is the exact quantity §5 says the handshake exists to lower. **A per-verification price is a tax on the behaviour the system most wants**, and it should be priced by seat, policy or period rather than by check.

### 7 · The operating licence, and who checks first

> a lot of companies might go, "well, that is our **mandate to operate**. Without that, we cannot operate" ... that's what happens already in a lot of business

The precedent is real and strong: regulated firms cannot trade without cover, and contractors cannot start on site without their certificates. **It is the clearest existing analogue for a gate that stops work rather than reporting on it**, and it explains why the pattern is culturally legible to a business in a way a security score is not.

**The hard part is not the mechanism, it is who checks first.** The handshake needs a relying party with a reason to refuse — and today an external platform has none. Nobody's code host is going to ask an agent for its insurance policy.

So the honest sequencing, and it lands where [memo 1](v0.33.72__strategy-brief__insurance-without-money-first-the-rating-is-the-product-and-micro-policies-scale.md) already pointed:

| First relying parties | Why they would check |
|---|---|
| **Internal services** within one organisation | The organisation sets its own rule. This is memo 1's internal marketplace with the handshake as its enforcement, and it needs nobody else's cooperation |
| **A broker** | Has a commercial reason: its own policy ([memo 6](v0.33.77__strategy-brief__the-broker-market-is-driven-by-insurance-and-a-broker-must-carry-its-own.md)) is exposed to what it lets through, so checking is self-protection |
| External platforms | **Not yet, and not for a while.** No incentive exists |

## Decisions This Implies (proposed into change control)

| # | Decision | Status |
|---|---|---|
| GM-D62 | **`policy/v0` is a mandate-shaped statement issued by a rater** — the same five fields, append-only record, revocation-by-append and verification walk. One more statement `type`, no new register machinery | Proposed — **answers GM-D36's open shape question** |
| GM-D63 | **A policy does not sign; its subject signs, and the policy establishes what that signature is worth.** The corpus's own rule, applied: possession is proved cryptographically, standing is established afterwards by a statement | Proposed |
| GM-D64 | **The relying party is the enforcement point**, and the policy handshake is the first mechanism in this pivot that can reach tier `boundary` — because a relying party is outside the requesting agent's grant. **Conditional on the relying party being genuinely independent of the requester** | Proposed — resolves the limit GM-D55 recorded |
| GM-D65 | **Verification is not metered by the check.** A verification is not a use; check events belong in the issuer's own lane rather than a central log; and a per-verification price is a tax on the behaviour the system most wants, raising the revocation latency the handshake exists to lower | Proposed |
| GM-D66 | **A revocation SLA states the required check interval**, or it is a hope with a number on it — effective revocation latency is the relying party's check interval, not the issuer's promise | Proposed |

## Open Questions, The Project Lead's

1. **Who is the first relying party you would build for?** §7 says internal services or a broker. Choosing decides whether the first handshake is a `setting` or a `boundary`.
2. **How is a policy provider paid, if not per check?** §6 rules out the obvious model on incentive grounds. Per seat, per policy, per period all work and shift the economics differently.
3. **Does a policy roll-up summarise or preserve?** §4's fractal claim allows an internal regime to become one external signature. Whether the external verifier can descend into it is a design choice with a real privacy consequence.
4. **Still open:** the MVP (N20). Memo 7 adds a third natural view — the handshake as a sequence — and `policy/v0` now has a settled shape to render.

---

*CC BY 4.0. Sources: the project lead's voice memo of 31 August 2026, seventh of eight (verbatim above); v0.33.71–77; the v0.33.60 briefing pack, v0.33.61 observability brief and v0.33.63 trust-as-confidence brief, each quoted verbatim and re-read out of the file it names. Everything below the transcript is the site agent's reading and says so.*