# The Schemas, The Clocks, And A Warranty Is A Fact With A Maximum Age

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

**type** Strategy brief — memo 10, the last of the series

*Produced from a voice memo of 31 August 2026 which contains two memos in one — the project lead says so partway through and keeps recording. 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 transcript ends mid-sentence**, which is recorded in §7 rather than smoothed over. This memo closes the series at ten.*

---

## What This Is

The interfaces and the clocks: **the memo argues that the APIs and schemas this ecosystem needs are easy to underestimate and are the thing that makes it work at all, particularly for micro-policies and policies with intervals — covering how a policy is created, what criteria bring it into existence, and what levels of trust make it valid, since all of that depends on where the agent is actually running; it makes cover conditional and continuous rather than checked once, so a policy holds only while stated preconditions hold, enforced through criteria to check, hashes to create and certifications to produce, with real-time checks mattering more as the money rises; and it then turns to time as a subject in its own right, naming expiry, dynamic creation, activation, policies bought for a small window or for a fixed number of uses within one, cover that applies only during office hours, and requirements that are themselves time-bounded — the worked example being a policy valid only while a backup less than twenty-four hours old exists, which means a database change is refused when the last backup failed or cannot be evidenced.** It is the seventh document of 31 August and the last of the memo series (cross-ref: v0.33.71–80, the observability brief's *a verification is not a use*, GM-D47's independent freshness, GM-D55's not-in-line position). New contributions: **the warranty as a fact with a maximum age, the third clock, the use-versus-verification distinction applied to metered policies, and the schema-not-API reframe.**

## The Memo, Verbatim

*Transcribed by otter.ai; carried whole, exactly as received, including its truncated final sentence.*

> Okay, so one of the things that I mentioned on the last memo, which I think it's very important to capture, is this idea of these APIs, but also the schemas that are required for this ecosystem to work, and and I think this is one of those things that it's easier to underestimate the the importance of it, because fundamentally what we kind of a saying is that you know for this to work, especially when you look at microinsurances and you look at insurances that also have a time interval, which is kind of again important to to think about itself. But the the APIs that are needed are very important, so we can actually create a mapping and a simulation to say what APIs do we need in terms of managing the policies themselves, to the creation of the policies, to the the criteria of for the policy to exist. Because fundamentally, this whole thing then needs to be agentic and data-driven. So, if you think about it, you know an insurance policy will then need to be able to require and define the schemas and the what's it called? Define the criteria and the levels of trust for the for the the policy to be you know valid to for the policy to be sort of accurate because you know it kind of all depends on where the agentic is running. So you you want a situation where the the policy provider is able to say right. So you you get this policy, but only if this still works only if your agent is still operating in these conditions, only if these preconditions that we have defined are working, and you know if the policy is in play. So, in this case, it's almost like there's APIs that, or criteria that you need to check, and maybe hashes to create, and maybe certifications to to create that defines if the policy is in play, if the policy is actually correct, but then you also have the situation of the what's it called you know real time checks that need to occur again for policies a bit more advanced, or especially the more money the policy is is dealing with, the more important this criteria becomes, right? So I feel that this is again is an important feature to capture. But we can actually map out. We can do a simulation, and you know maybe on this one have a first go of creating a simulation, and what do the APIs, what do the schemas, what would the data sets kind of will look like in the multiple pieces of the puzzle for this to work, so that we have these sort of micro policies in play, and you know, and maybe some of these are done by spreadsheets, right? You know, which is what exists today. But then, where does that intersection occur, and where does those flows occur? So I think that's quite important to capture. Now, this is sort of a second memo. I'll just record it here. But I feel, I feel That that I I'll capture it here, but I feel that this is literally a a second memo to capture, which is the idea of time, and I think time in this scenario is actually very important because time has a bunch of different properties here that are very important to capture and are very important to take into account when we design this system. Again, following from the previous memo, but I think time is actually one of those things that needs to be taken into sort of account of of the flows because there's a lot of items here that are very time sensitive, which we need to take into account from from the point of view of the the policy itself, you know, which might have a time expiry date, and my and and again, you could have situations where policies are created dynamically, or policies can be activated, or you can buy. You could even have a case where a policy can be bought so that it only alive or is only active for a small period of time. So instead of somebody buying a policy for 24 hours, maybe buys a policy that provides 10 time usage over a period of an hour, right? And again, that has a different cost structure than a permanent cost, right? And and and and policies that, for example, only provide, let's say, guarantee over office hours, let's say, and but also so there's the time that there's the expiry, there's the time to start with, and also there's the sort of the the time duration of the policy that has a certain amount of requirements that might also be time sensitive. You could have a requirement like I think one of the things that we were checking one of the examples was a a policy that said that you know, it's only valid if you have a backup with less than 24 hours. So that means that you know you cannot make a change to the database if the backup, for example, last backup failed, or if you don't have evidence that the last backup is actually operating. So in this case, you could say that you have a 24-hour period where within that window

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

### 1 · The backup example is the best thing in the memo, and it defines a warranty precisely

> it's only valid if you have a backup with **less than 24 hours** ... you cannot make a change to the database if the last backup failed, or if you **don't have evidence** that the last backup is actually operating

This is worth extracting as a definition, because it is sharper than anything the pivot has had for a cover condition:

> **A warranty is a fact plus a maximum age.**

Not a boolean — `{fact: last_backup_succeeded, max_age: 24h}`. And the second clause matters as much as the first: *or if you don't have evidence*. **A warranty fails three ways, not two** — the fact is false, the fact is stale, or the fact is unknown — and the memo puts unknown on the same side as false, which is the correct and uncomfortable choice for a cover condition.

**The estate already computes exactly this shape.** Every evidence pack prints the twin's age precisely because a measurement goes stale; [document 01's](../insurance/the-rating.html) three-valued facts already keep `unknown` distinct from `false`. A warranty is those two mechanisms combined and pointed at a cover condition rather than at a rating (GM-D76).

And the consequence the memo draws is an escalation the pivot has been climbing without noticing:

| | Gate evaluated | From |
|---|---|---|
| **Go-live** | Once, at deployment | [Memo 2](v0.33.73__strategy-brief__the-ecosystem-without-the-money-insurance-as-a-go-live-gate.md) |
| **Running agent** | On world events | [Memo 3](v0.33.74__strategy-brief__who-pays-for-the-delta-nobody-chose-and-the-rating-that-moves-overnight.md) |
| **Per action** | **Every time the agent acts** | **This memo** — *you cannot make a change to the database if…* |

The third is the strongest and the most expensive, and it is the one the [handshake](v0.33.78__strategy-brief__the-policy-is-a-signed-statement-and-the-relying-party-is-the-boundary.md) already provides the mechanism for: a relying party checking on every request is checking the warranty on every request too.

### 2 · Cover is continuous, which adds a third clock

*You get this policy, but only if your agent is still operating in these conditions* makes cover **continuously conditional**, and that is a different object from a policy with an interval.

The pivot now has three clocks running at different rates, and conflating them is how a system like this quietly lies:

| Clock | What it measures | Established in |
|---|---|---|
| **The policy interval** | From when, until when the cover exists at all | Memo 7 — a policy is mandate-shaped |
| **Twin and world freshness** | How current the measurement and the threat picture are | [GM-D47](../packs/grant-and-mandate/change-control.html) |
| **The warranty's check interval** | **How recently each cover condition was confirmed** | **This memo** |

A policy in force, computed against a fresh twin, with a warranty last checked eleven days ago, is **not covered** — and only a system that keeps the third clock separately can tell you that (GM-D77). It is the same lesson as [memo 7's](v0.33.78__strategy-brief__the-policy-is-a-signed-statement-and-the-relying-party-is-the-boundary.md) revocation latency: a promise is bounded by the interval at which somebody actually looks.

### 3 · Ten uses in an hour is metering *uses*, and that is a different thing from metering checks

> instead of somebody buying a policy for 24 hours, maybe buys a policy that provides **10 time usage over a period of an hour**

[Memo 7's reading](v0.33.78__strategy-brief__the-policy-is-a-signed-statement-and-the-relying-party-is-the-boundary.md) argued against **per-verification** pricing, because taxing a check makes relying parties check less, raising the revocation latency the handshake exists to lower. **This is not that**, and the corpus's own line is the distinction:

> **"a verification is not a use."**

Metering *uses* is what insurance has always done — per flight, per shipment, per journey — and it prices the thing the buyer actually consumes. It is sound where per-check pricing is not.

**But it collides with the not-in-line position, and this is the finding.** To count uses you have to observe uses. The observability brief already established that a relying party which does not verify generates nothing at all — so a use is only countable by somebody **in the path of the action**:

| Who could count uses | Can they? |
|---|---|
| The relying party | **Yes** — it is the one being asked |
| An execution broker | **Yes** — it performs the action |
| The rater / this project | **No.** [GM-D55](../packs/grant-and-mandate/change-control.html): not in line, so it sees nothing |

> **A usage-boxed policy requires an in-line counter, which this project is not** (GM-D78). It can define the counting schema; somebody else has to hold the counter — which is the same division as everywhere else, and worth stating before a usage-metered product is designed on the assumption that we can see the usage.

### 4 · Office hours is the cheapest time feature, and it has one trap

Cover *only over office hours* is a small extension: a mandate already carries an interval, and this is an interval with **recurrence**. It is also a real control rather than an administrative nicety — an agent that may act only during business hours has a smaller blast radius because somebody is awake.

The trap is old and specific: **a recurring window without a timezone is ambiguous**, and daylight saving moves it twice a year. Ambiguity in a *cover* condition is materially worse than ambiguity in a schedule, because it is exactly the ground disputes are fought on.

> **A recurring cover window states its timezone** (GM-D80). Small, cheap now, and unpleasant to retrofit into policies already sold.

### 5 · The reframe: this project defines schemas, not APIs

The memo asks *what APIs do we need*. The honest answer follows from [memo 5](v0.33.76__strategy-brief__not-in-line-the-schemas-are-the-product-and-the-scale-is-one-to-five.md) and is worth stating plainly, because it changes the deliverable:

> **An API is operated. A schema is implemented.** The not-in-line position permits only the second.

So the artefact is not *the policy API* — it is **the policy lifecycle as a set of documents and the transitions between them**, which every participant then exposes however they like. And the estate already has the pattern:

| The memo's need | The estate's existing shape |
|---|---|
| Creating a policy | A signed statement appended to the issuer's record |
| Criteria for it to exist | The statement's own fields — the warranty set |
| "Hashes to create" | Statement hashes over the canonical form; already computed |
| "Certifications to create" | Signatures, verified against a published key |
| Amending, activating, ending | **Appends.** Never edits — the register's rule since v0.1.26 |

**Which means the answer to *what APIs do we need* is mostly: none that we build.** Interoperability lives in the documents; the API is whatever each party puts in front of them. That is a smaller and more defensible deliverable than an API surface, and it is the one this project can actually ship.

### 6 · Spreadsheets, and where memos 9 and 10 meet

> maybe some of these are done by spreadsheets, right? which is what exists today. But then, **where does that intersection occur**

This is [memo 9's survey](v0.33.80__strategy-brief__make-your-agents-insurable-and-the-first-fact-this-pivot-would-produce.md) question from the other side. Memo 9 asks *what format does the market accept*; memo 10 asks *where does that format meet ours*.

**They are one question and the survey answers it.** If the market fills in spreadsheets, the connector's job is to render an evidence pack into a spreadsheet — **carrying the evidence classes across**, or a measured fact and a declared one arrive in adjacent cells looking identical, which [GM-D73](../packs/grant-and-mandate/change-control.html) says is the shape of material non-disclosure. **A connector that flattens provenance into a spreadsheet would create the very defect the pivot exists to detect.**

### 7 · The transcript ends mid-sentence

The recording stops at *"you could say that you have a 24-hour period where within that window"*. **The thought is unfinished and this brief does not complete it**, because guessing the end of a sentence and rendering it as the project lead's position is the same error as guessing a survey's findings. Whatever followed *within that window* is not recorded here.

## Decisions This Implies (proposed into change control)

| # | Decision | Status |
|---|---|---|
| GM-D76 | **A warranty is a fact plus a maximum age**, and it fails three ways — false, stale, or unknown — with unknown on the same side as false. The estate's twin-age and three-valued-fact machinery already computes this shape | Proposed |
| GM-D77 | **Cover is continuous, and the warranty's check interval is a third clock**, separate from the policy interval and from twin/world freshness. A policy in force against a fresh twin with a stale warranty is **not covered**, and only a system keeping all three can say so | Proposed |
| GM-D78 | **Metering uses is sound where metering verifications is not** — *a verification is not a use* — but a usage-boxed policy needs an **in-line counter**, which this project is not. We define the counting schema; the relying party or broker holds the counter | Proposed |
| GM-D79 | **This project defines schemas, not APIs.** An API is operated, a schema is implemented, and the policy lifecycle ships as documents and transitions — creation, amendment, activation and ending all as **appends**, never edits | Proposed — the not-in-line position, applied to the interface question |
| GM-D80 | **A recurring cover window states its timezone.** Ambiguity in a cover condition is the ground disputes are fought on, and daylight saving moves an unqualified window twice a year | Proposed |

## Open Questions, The Project Lead's

1. **What finishes the sentence?** §7 — the backup example's window rule is cut off, and it is the most concrete cover condition in the whole series.
2. **Who holds the use counter in the first design?** §3 says it cannot be us. Relying party and broker have different visibility and different incentives to under-count.
3. **Does a warranty breach void, suspend, or downgrade?** Insurance has all three and they are materially different: voiding is retroactive, suspending is not, and downgrading keeps cover at a worse level. The memo implies refusal of the action, which is closest to suspension.
4. **The series is complete.** Ten memos, eleven doctrine documents, eighty decisions from this pivot. Two deliverables are specified and unbuilt — the [world model](../insurance/the-world-model.html) (N23) and the [market survey](../insurance/make-them-insurable.html) (N24) — and this memo adds a third candidate, the schema simulation it asks for.

---

*CC BY 4.0. Sources: the project lead's voice memo of 31 August 2026, the tenth and last of the series (verbatim above, including its truncation); v0.33.71–80; the v0.33.61 observability brief, quoted verbatim. Everything below the transcript is the site agent's reading and says so.*