# Observability Is The Usage Graph Nobody Has To Declare: Check Events Belong In The Issuer's Own Lane Rather Than A Central Log, A Verification Is Not A Use, And The Missing Edges Are Worth More Than The Present Ones

**version** v0.33.61
**date** 20 August 2026
**from** Human (project lead)
**to** Architecture, Engineering, Security, the pki.sgit.ai site agent

**type** Architecture brief

*Ninth of 20 August. The lane's limits and its blind write contract are quoted from the interface reference fetched today, and one property the design depends on is absent from that reference and is recorded as an open question rather than assumed. Resolves a direct tension with the notary brief written earlier today, where the same dataset was named as the sharpest contradiction of this estate's positioning, and the resolution is that both are right and the difference is who holds it. Limitation: no volumes exist yet, so the capacity arithmetic here is from published limits rather than from measurement.*

---

## What This Is

The observability layer the memo asks for, the correction it needs, and the single design decision that determines whether it is a security property or a surveillance product: **the memo proposes that observability be first-class in the registry from the beginning rather than added afterwards, that the vaults carry it now and platforms carry it later, and that the essential insight is that you learn where a mandate is being used by capturing who checks it, which yields an unexpected agent presenting a valid mandate, a valid agent presenting one in a place nobody intended, and the blind spots where checking tails off; the proposal is right and it is load-bearing for something already written today, because this morning's position was that declared mandates are instrumentation rather than enforcement and are worth building precisely because they produce the evidence that says where enforcement earns its cost, so without check events that justification is empty and the mandate layer produces no evidence at all; the correction the memo needs is that a verification is not a use, and the error runs both ways, since a resolver walking a chain generates an event with no usage behind it while a relying party that simply does not bother to verify generates nothing at all, which means the graph is a verification graph and the silent case is the dangerous one, so the most valuable output of this layer is not the edges it draws but the parties holding a mandate that have never once checked it; where the events are written then decides everything, because a central check log at the registry accumulates who is evaluating whom across parties that never consented and is held in plaintext by construction, which is the contradiction named earlier today, whereas a check event written by the checker into the issuer's own lane is an owner observing their own asset, and this corpus's rule that evidence is appended by the asserter to its own record settles which of those to build; the shipped append lane is already the mechanism, account-less with a blind acknowledgement, and its published limits set the shape, since a thousand pending files per token means a busy mandate exhausts its token and the endpoint refuses further writes, so draining becomes an obligation on the issuer rather than an option, and whether an unregistered party may report a check at all is not stated in the reference and has to be answered before this is committed; and the memo's sharpest original observation deserves promoting, because 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, and turning what is normally a hope into a measured number that can also be written as one of the few mandate clauses that is actually decidable.** It is the ninth document of 20 August (cross-ref: the v0.33.61 notary brief, the v0.33.61 register interface brief, the v0.33.61 register brief, the v0.33.61 grant and mandate brief, and the v0.33.60 append lane brief). New contributions: **verification separated from use with the asymmetry named, the missing edges identified as the primary output, the holder of the log established as the decision that separates security from surveillance, the capacity arithmetic from published limits, draining named as an obligation, and effective revocation latency defined and made measurable in advance.**

## Observability First Is This Corpus's Own Position, And This Time It Is Load-Bearing

The memo asks for a sequencing commitment. The project lead: **"observability doesn't added later; is added straight at the beginning."**

That is a position this corpus reached from a different direction and has repeated since: **instrument before you enforce**, because you need not predict what breaks when you can measure it. So the memo is asking for something already argued for, and agreeing is cheap.

What is worth saying instead is that here it is not merely good practice. **It is what makes something written this morning true.**

This morning's strategy brief drew a hard line between the execution broker, which is enforcement because the agent never holds the credential, and the declared mandate, which is instrumentation because nothing prevents the holder doing more. It recommended building declared mandates anyway, and the entire justification was that they are cheap and **they produce the data that says where enforcement is worth its cost.**

**Without check events, they produce no data.** A declared mandate with no observability is a document that nobody reads, generating nothing, and this morning's recommendation would be indefensible. So observability is not an adjunct to the mandate layer. It is the half that makes the honest description of that layer honest.

## A Verification Is Not A Use, And The Error Runs Both Ways

The correction the memo needs, and it matters because the conclusion the memo wants to draw is a usage conclusion. The project lead: **"how do we know if a mandate is being used in is and is being and by who is using it? Guess what, by capturing and visualising and listing who has checked for the mandate, we know where is being used."**

**What is captured is verification, not use**, and the two come apart in both directions:

| Situation | Event generated | Consequence |
|---|---|---|
| A mandate is used and the relying party verifies it | Yes | The intended case |
| A mandate is used and the relying party does not bother verifying | **None** | **The dangerous case is silent** |
| No use, but a resolver walks the chain past it | Yes | An event with no usage behind it |
| No use, but a monitor or a curious party probes | Yes | Noise that looks like adoption |

So the graph is a graph of who is checking, and reading it as a graph of who is using will produce confident wrong answers. **And the error is in the worst possible direction**, because the party that never verifies is exactly the party whose relying process is weakest, and it is the party this layer cannot see.

The memo gets close to this from the other side. The project lead: **"some some users do a lot of checks in the beginning, but then after a while they don't. So which basically means introduces 10s of light spots."** That is right, and the sharper form is that a party which never checked at all was never visible to begin with, so tail-off is the detectable version of a problem whose worst instances are undetectable.

## So The Missing Edges Are The Primary Output

Which turns the design around, and lands on a position this corpus has now reached in enough places to be a habit: **the gap is the finding.**

The valuable query is not who checked. It is:

> Which parties hold a mandate issued by me and have never once verified it?

**And that join is available**, because the issuer knows both halves: it knows who it issued to, and its lane records who checked. Issued-to minus has-checked is computable, it is small, and every row in it is a relying party accepting a mandate on faith.

That is a better product than an adoption dashboard, and it is the same shape as the register interface's most useful page from earlier today, which lists every edge nobody can verify. **Both are lists of absence**, and in each case the absence is the actionable half.

## Where The Events Are Written Decides What This Is

The most consequential decision in the memo, and it is not stated in the memo, so it needs stating here. It also resolves a tension with a brief written earlier today rather than leaving two positions standing.

**The notary brief warned against exactly this dataset.** It recorded that a live notary accumulates a map of who is currently evaluating whether to trust whom, that neither party handed it over, that the subject is never told it was checked, and that for a project positioned on the server being unable to read your content, holding that graph in plaintext is the sharpest available contradiction.

**This memo proposes building that dataset as a security feature.** Both are right, and the difference is entirely in who accumulates it.

| Design | Who accumulates | What it is | Consent |
|---|---|---|---|
| A central check log at the registry | The operator | **A live map of who is evaluating whom, across everybody** | Nobody gave it |
| Check events into the issuer's own lane | Each issuer, for its own mandates | **An owner observing their own asset** | Implicit in holding the mandate |

**This corpus's own rule settles it**, and it is the rule taken from the 2019 keyserver failure and restated in this morning's register brief: evidence is appended by the asserter to its own record, never to the subject's, and never to a third party's.

So: **the checker writes the check event into the issuer's lane.** The issuer learns who checked the mandates it issued. No party learns who checked everybody's, because no such record exists anywhere.

Three properties follow, and the third is a cost rather than a benefit.

**There is no central observability store**, so there is nothing central to compromise, which is the catastrophic failure principle applied to telemetry rather than to keys.

**The checker's exposure is bounded and comprehensible.** Checking a mandate tells its issuer that you checked it, which is a statement about a relationship you already have with that issuer, rather than a data point in a stranger's dataset.

**And the aggregate is foreclosed.** The operator cannot see, sell or reason over the whole graph, which removes precisely the asset the notary brief identified as more valuable than the answers being sold. That is the same trade as the publish-rather-than-answer choice in that brief, one layer down: **the design that protects the positioning is the design that destroys the dataset**, and it should be chosen deliberately rather than discovered later.

## Derived Rather Than Declared, Which Keeps The Entry Clean

The memo's own framing, and it agrees with two positions already settled. The project lead: **"it will actually allow certain things not to be mapped but derived."**

**Usage is never written into the register entry.** It is derived from the lane on demand. That agrees with the June principle of clues rather than storage, and with today's history brief, whose rule is that an entry carries current state and no accumulated history, because the growth belongs somewhere designed for growth.

So the entry says what the mandate is. The lane says who asked about it. Nothing has to be declared, kept in step, or trusted, and the register does not grow every time somebody looks at it.

## The Shipped Lane Is The Mechanism, And It Has Numbers

The transport exists and needs no design. Append is account-less, takes a token in the body, and returns a blind acknowledgement, quoted from the reference today as returning exactly an ok and nothing else: no file identifier, no count, no metadata. **That is precisely right for this use**, because a checker reporting a check must not learn anything about the lane it wrote to, including how busy it is.

The published limits set the shape:

| Limit | Value | On breach |
|---|---|---|
| Payload per write | 5 MB | 413 |
| **Pending files per token** | **1000** | **507** |
| File identifiers per batch | 100 | 400 |
| Inline content when listing | 3 MB cumulative | 413 |
| Page size | 50 default, 200 maximum | Clamped silently |

**The binding constraint is a thousand pending files per token**, and a check event is small and frequent, which is the worst combination for that particular limit. Three consequences.

**Draining becomes an obligation rather than an option.** An issuer that does not enumerate and mark or purge will fill the lane, and further writes are refused. So observability creates ongoing operational work for the issuer, and an issuer who stops doing it stops receiving evidence without being told, which is a silent failure of the exact kind this corpus keeps recording. **The drain needs monitoring more than the lane does.**

**Or checkers aggregate**, batching several checks into one event and trading freshness for volume, which is the same commit-queue trade recorded in the shared drive brief earlier today and should reuse its reasoning rather than reinvent it.

**And the page size caps the read side**, at two hundred per page and clamped silently, so a busy issuer's drain is itself a paginated job rather than a single call.

One property the design depends on is **not stated in the reference**. The configure endpoint registers append anchors as hashes of accepted senders, and the documentation does not say whether a lane with no anchors configured accepts any holder of a token or refuses everything. That decides the coverage of this entire layer:

> If anchors are required, only checkers the issuer already registered can report, and **the relying parties you most want to observe are the ones you do not know about.**

That has to be answered before this is committed, and the ambiguity is worth reporting to the site team as the third documentation gap found today.

## Effective Revocation Latency Becomes Measurable Before Anything Is Revoked

The best original observation in the memo, and it deserves promoting from an aside to a defined metric. The project lead: **"remember are the revocations in our case happen when somebody checks if the link is still there or is following the rabbit hole of dependencies and then hits a dead spot."**

That is correct and it generalises: **in this design there is no push.** A revocation does not travel. It sits in the register until a relying party looks, so a revocation propagates at exactly the rate at which parties check.

Which gives a number nobody usually has:

> **A relying party's effective revocation latency is the interval between its checks.** It is computable per party and per mandate, from the check events, **before anything has ever been revoked.**

Conventional key infrastructure cannot do this, because the consumers of a revocation list are invisible to the issuer. Here they are visible, because they wrote to the issuer's lane. So an issuer can publish, in advance, a distribution: half of the parties relying on this mandate would notice a revocation within an hour, ninety five percent within a day, and these four would never notice at all.

**And it produces one of the few mandate clauses that is genuinely decidable.** This morning's brief established that a mandate is decidable when it constrains something the system already sees. Almost none of the interesting ones qualify. This one does:

> Verify this mandate at least once every twenty four hours.

A relying party that fails it is in breach of a term of the mandate it holds, and the breach is visible in the issuer's own lane without any cooperation from the party. That is worth having because it is so rare.

The honest limit belongs beside it. **For a party that never checks, the latency is infinite and invisible**, which is the same blind spot as the section above, and it means the published distribution describes the parties that participate rather than the population.

## What A Check Event Must Contain, And What It Must Not

Short, and the second list is the one that keeps this on the right side of the line drawn above.

| Must carry | Why |
|---|---|
| The mandate or entry identifier | What was checked |
| Timestamp | The latency metric depends on it |
| Checker identity, or a stable pseudonym | Otherwise the missing-edges join cannot be computed |
| The question asked | Since a chain walk and an authorisation check are different events |
| The result | Confirmed, denied, unknown, unreachable |
| The anchor it was resolving toward | So a chain can be reconstructed |

| Must not carry | Why |
|---|---|
| **What the checker was authorising** | The issuer has no claim on the checker's business, and including it turns an asset log into a customer surveillance log |
| The checker's own credentials or tokens | Nothing about a check requires them |
| Anything the issuer could not already infer from holding the mandate | The consent argument above depends on this boundary |

**That second table is the design.** Remove it and this becomes the thing the notary brief warned about, with the issuer in the operator's chair.

## The Timing Channel, And Both Halves Of It

Stated because the corpus's own rule is that a breach claim without its exception is unfalsifiable.

**Content in the lane is encrypted client-side and the server holds hashes of the capabilities.** So a compromised server does not learn who checked what.

**And the lane's growth rate is observable.** Check events are small, frequent writes, so anybody able to watch the lane's object count and timing learns how heavily a mandate is being exercised, and when, without decrypting anything. That is the shape-of-the-estate disclosure the corpus recorded on 19 August, arriving in a place where the shape is more sensitive than usual, because the rate of checking is itself a business signal.

Aggregation by the checker helps here as well as with the token limit, which is a rare case of a capacity fix and a privacy fix being the same change.

## This Populates The Badge

A build note rather than an argument, and the third time today that two briefs turn out to need one thing.

The register interface brief written earlier today specifies a badge on every edge carrying, among other fields, when the edge was last checked and what the result was. **That field has no data source in that brief.** It has one here: the issuer's lane is where last checked comes from.

So the observability layer is not a separate system with its own dashboard. **It is the interface's evidence, and the badge is its user interface.** Building it twice, once for a telemetry view and once for the register, would produce two answers to the same question, and the register would eventually be the one that is wrong.

## What This Does Not Try To Be

- **Not a usage graph.** It records verification, and the parties that never verify are invisible to it.
- **Not a central log.** Events go to the issuer's lane, and no aggregate exists anywhere.
- **Not a record of the checker's business.** The event says a check happened, never what was being authorised.
- **Not push-based revocation.** Nothing travels; the metric exists because propagation depends entirely on checking.
- **Not free to run.** Draining the lane is continuing work for the issuer and fails silently if it stops.

## Honest Tensions

| Tension | Note |
|---------|------|
| Observability as a security property | It is the evidence that makes declared mandates defensible and it is the dataset this estate warned against holding, and only the location of the log separates the two |
| Issuer-held logs | They keep the aggregate from existing and they also destroy the most commercially valuable dataset the registry could have produced |
| The checker is revealed to the issuer | It is a relationship that already exists and some checkers will not want their evaluation known, which pushes them to the published path that generates no event at all |
| Publishing versus observing | The privacy-preserving verification route from the notary brief is invisible to this layer, so the two good designs actively subtract from each other |
| Draining as an obligation | It bounds storage honestly and an issuer that stops draining loses evidence without being told |
| Effective revocation latency | It is a real number and it describes only the parties that participate, which are not the ones that worry you |

## Open Questions

| Question | Notes |
|----------|-------|
| Does a lane with no anchors accept any token holder? | Absent from the reference, and it decides whether unknown relying parties can report at all |
| Is the checker identified or pseudonymous? | The missing-edges join needs stability, not identity, and pseudonymous is the weaker claim that may be enough |
| Who drains, and what watches the drain? | The failure is silent and the layer is worthless once it starts |
| Do published statements carry a reporting obligation? | A checker fetching a published answer generates nothing, so the two designs cannot both be complete |
| What is the aggregation window for checkers? | The same trade as the commit queue, and it fixes capacity and the timing channel together |
| Can an issuer prove it did not delete inconvenient events? | The lane is the issuer's own record, so the issuer can purge it, which is the reference-mutability problem from today's history brief in a new place |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 20 Aug | `v0.33.61__arch-brief__every-trust-edge-is-a-two-way-conversation-notary-specified-in-march-signed-once-against-checked-every-time.md` | The warning against accumulating who checks whom, resolved here by where the log lives, and the published path that this layer cannot see |
| 20 Aug | `v0.33.61__dev-brief__register-ui-every-edge-carries-a-verification-badge-policy-is-a-query-that-must-return-empty.md` | The last-checked field, whose data source this supplies, making the badge this layer's interface |
| 20 Aug | `v0.33.61__strategy-brief__grant-is-not-the-mandate-the-gap-between-them-is-the-exposure-nobody-accepted.md` | Declared mandates as instrumentation, whose entire justification depends on this evidence existing |
| 20 Aug | `v0.33.61__arch-brief__register-was-designed-in-june-published-keypairs-are-fixtures-not-identities.md` | The rule that evidence is appended by the asserter to its own record, which decides where check events go |
| 19 Aug | `v0.33.60__arch-brief__append-lane-is-shipped-and-account-less-four-tiers-and-five-corrections.md` | The lane, its blind acknowledgement and its limits, and the shape disclosure this inherits |
| 6 Aug | `v0.33.56__arch-brief__sg-send-plugins-are-capability-grants-ambient-authority-is-the-injection-root-cause-instrument-before-enforcing.md` | Instrument before you enforce, which this is an instance of rather than a restatement |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | Observability is what makes the declared mandate layer defensible, since its stated justification is the evidence it produces |
| 2 | A verification is not a use, and the graph captured is a verification graph |
| 3 | A relying party that does not verify generates no event, so the weakest relying process is the invisible one |
| 4 | The primary output is therefore the parties holding a mandate that have never checked it, which the issuer can compute |
| 5 | A central check log accumulates who is evaluating whom across parties that never consented |
| 6 | Writing check events to the issuer's own lane makes it an owner observing their own asset instead |
| 7 | That follows the corpus rule that evidence is appended by the asserter to its own record |
| 8 | It also forecloses the aggregate, which is a real commercial cost chosen rather than discovered |
| 9 | The shipped lane is the mechanism, and a thousand pending files per token makes draining an obligation that fails silently |
| 10 | Whether an unregistered checker may report at all is absent from the reference and gates the layer's coverage |
| 11 | Revocation propagates only at the rate parties check, so the interval between checks is effective revocation latency and is measurable in advance |
| 12 | That yields one of the few decidable mandate clauses, namely a maximum permitted interval between verifications |

---

## Sources

- The append lane interface, stating that the write response is blind and returns exactly an acknowledgement with no file identifier, count or metadata, that the configure endpoint registers append anchors as hashes of accepted senders together with the enumeration key hash under the vault write key, and the published limits of five megabytes per write, one thousand pending files per token, one hundred file identifiers per batch, three megabytes of cumulative inline content when listing, and a page size of fifty by default and two hundred at most, clamped silently: https://sgit.ai/api/append-lanes

---

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