# Every Trust Edge Is A Two-Way Conversation: The Notary Was Specified In March As A Countersignature, The Real Fork Is Signed-Once Against Checked-Every-Time, And Metering The Second One Costs The Privacy Claim

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

**type** Architecture brief

*Sixth of 20 August, and the first of two documents from one memo at the project lead's own division. The prior notary specification was located in the repository and is quoted from it rather than recalled. The June trust model is quoted from the same clone. Limitation: the clone's brief folders end at 14 August, and the commercial arithmetic here is structural rather than costed, since no price has been proposed.*

---

## What This Is

The verification half of the registry, the specification it already has, and the fork that decides both the architecture and the business model: **the memo proposes that a claim naming an authority should be checkable by going to that authority and asking, so that every trust edge carries a two-way conversation rather than a one-way assertion, and it names notaries as the paid version of that service; the concept has a specification in this corpus from 13 March, where an external party countersigns a commit as an attestation carrying its own key identifier, and where the depth of verification a client performs is a client-side setting rather than a property of the data, which is the memo's own distinction between what a client can verify and what only a provider can, already designed as a dial; the structural claim is right and it is the June model, in which upward trust is self-declared and grants nothing until the named party is asked, so the two-way conversation is not a new requirement but the mechanism that turns a declaration into a signal; where the memo states two options in passing is where the whole design sits, because a signed assertion verified once and a live lookup checked every time are not two settings of one feature but two products with opposite properties, the first working offline with staleness bounded by expiry and the second always current and requiring the authority to be reachable, and only the second can be charged per use because only the second is observed; that observation is the cost, and this corpus has already priced it once, since being the meter moves a privacy claim from architectural to operational, and here the exposure is worse than the token gateway's because what the notary accumulates is not the customer's own content but the graph of who is checking whom, which is a relationship dataset the parties never handed over; there is a design that escapes it, since a notary that publishes signed dated answers to a location the verifier fetches cannot meter and cannot surveil, and those turn out to be the same property rather than two; and a paid notary changes resolution itself, because the June rule that a partial result is legitimate acquires a new reason for stopping, which is that the next check cost more than the budget, so a budget becomes a trust boundary and a resolution result has to record what it declined to verify and why.** It is the sixth document of 20 August (cross-ref: the v0.32.4 registry brief, the v0.13.32 PKI workflows document, the v0.33.56 token gateway brief, the v0.33.61 register brief, and the v0.33.61 history brief). New contributions: **the March specification located, the two-way conversation identified as the existing mechanism rather than a new requirement, the two verification modes separated as products, the metering exposure named as a relationship graph, publishing identified as the escape from both metering and surveillance, and the budget named as a trust boundary.**

## The Notary Was Specified On 13 March

The memo suspects prior work and it is right, twice over. The project lead: **"it's kind of like the same way that we have meaning to connectivity in our graphs. Here's you have trust to connectivity, which is kind of like I think the document we wrote a while back."**

`v0.13.32__pki-workflows__operating-modes.md`, 13 March, is a PKI deep dive that already carries both halves of what the memo is asking for.

**The notary has a data shape.** The document describes a future mode in which a commit carries an additional countersignature from an external party, naming an auditor, a compliance system or a notary service, and gives the object: alongside the branch signature and the author signature sits an attestations array, each entry carrying the attesting key's identifier. So a notarisation is a countersignature that names its attester and travels with the thing it attests.

**And the client decides how deep to verify.** The same document sets out verification levels as a client-side configuration, rising to a level described as trusting that an external party confirmed each commit, verifying countersignatures from auditors and notaries, and offered for legal and regulatory evidence chains.

That second point is the memo's own distinction, already designed. The project lead: **"some of the verifications can be done by the client, some can only be done by a provider."** The March model says the same thing from the other side: **the data carries whatever attestations exist, and the consumer chooses how many of them to check.** Depth of verification is a setting rather than a property of the record.

Two things follow. The work today is operationalising a March specification rather than producing one, which is the third time this pattern has appeared in this day's briefs. And the specification's own status matters: it is marked as a future mode and explicitly not for initial implementation, so it is a design to inherit and not a capability to cite.

## The Two-Way Conversation Is The Existing Mechanism

The memo states the structural claim clearly. The project lead: **"every time there's a trust relationship, there is a two-way conversation. There's a two-way element where, in some of the flows that we have, we need to go to the entity that has that is being claimed that there's a trust relationship and check."**

**That is the June model, and the two-way conversation is not an addition to it. It is what makes it work.**

The registry design of 5 June has trust in two directions: downward trust asserted by the truster and held in the truster's own dataset, and upward trust self-declared by the subject, which grants nothing. The mechanism that turns the second into a signal is precisely the memo's check: go to the named party and ask. And the June model already enumerates the outcomes, which is more than a yes and a no:

| What the subject claims | What the named party says | The signal |
|---|---|---|
| A should trust me | A confirms | A strong, confirmed link |
| A should trust me | A has not verified | Weak or pending, and legitimately so |
| A should trust me | A says it does not | **Explicit distrust, which is information rather than absence** |
| A should trust me | A cannot be reached | **Unresolved, and it must not read as either of the above** |

The last row is the one the memo's live-lookup design adds, and it is the one that needs stating, because an unreachable authority is the common case in any real network and it is not the same as a denial. **A resolver that renders unreachable as untrusted will produce outages that look like security events**, and one that renders it as trusted has no security property at all. It has to be its own state.

## The Fork The Memo States In Passing Is The Whole Design

The memo names both modes and moves on. The project lead: **"it could be something that has to be checked all the time, or it could be something that again using PKI can only can be provided once and checked, you know, and not have to be checked all the time."**

**These are not two settings of one feature. They are two products with opposite properties**, and almost every consequence in this brief follows from which one is being built.

| | **Signed assertion**, verified once | **Live lookup**, checked each time |
|---|---|---|
| What the verifier needs | The notary's public key | The notary reachable, now |
| Works offline | **Yes** | No |
| Currency | As fresh as its issue date | **Always current** |
| Withdrawal | Needs revocation or a short expiry | Implicit, since the answer simply changes |
| What the notary learns | That it issued something, once | **Every check: who asked about whom, and when** |
| Failure mode | Stale acceptance | **An unreachable authority blocks the transaction** |
| Chargeable | Once, at issuance | **Per use** |
| Existing instance in this estate | Workflow signing, where a short-lived certificate and a public log make the claim checkable without a directory | A directory lookup, which the shipped commands do not have |

Two observations that are not obvious from the table.

**The signed path is what this morning's register brief already recommended**, from a different direction. A certificate that expires in minutes and whose issuance is recorded in a public log does not need revoking, because it was never durable. That is the signed mode with the staleness problem engineered away, and it is available now.

**And the live path is the only one that can be metered.** You cannot charge per check unless you see every check. So the commercial angle the memo is attracted to is attached, structurally and unavoidably, to the mode with the worse privacy and availability properties. That is worth knowing before a price is set rather than after.

## Metering The Live Path Costs The Privacy Claim, And This Corpus Has Paid That Once

The memo reaches for the business model. The project lead: **"it could be free from a point of view of calls, or it could be charged, like a notary."**

On 6 August this corpus recorded, in the token gateway work, that being the meter forces you into the request path and that the price of being in the path is privacy, because the claim moves from architectural, meaning we cannot see it, to operational, meaning we do not retain it. **The same finding applies here and the exposure is of a different and worse kind.**

The gateway sees the customer's own content, which the customer chose to send. **A live notary sees something nobody handed over: the relationships between third parties.** Every check is a sentence of the form this party is currently evaluating whether to trust that party, stamped with a time.

| | Token gateway | Live notary |
|---|---|---|
| What accumulates | Prompts and completions | **Who checked whom, and when** |
| Whose data is it | The customer's, given deliberately | **The querier's and the subject's, given incidentally** |
| Does the subject know | Not applicable | **No. The subject is never told it was checked** |
| Value of the accumulation | The content | **The graph, which is worth more than any single answer** |

That last cell is the reason this deserves a section rather than a caution. A notary running at any scale accumulates a live map of who is deciding whether to trust whom, which is a more commercially valuable and more dangerous dataset than the answers it is selling. **For a project whose entire positioning is that the server cannot read your content, holding that graph is the sharpest possible contradiction**, and it would be held in plaintext by construction, since a lookup you cannot read is a lookup you cannot answer.

## Publishing Escapes Both, And They Turn Out To Be One Property

There is a design that avoids it, and it is the one this estate already uses everywhere else.

**A notary that publishes rather than answers.** Instead of a verifier asking a question and receiving a reply, the notary writes a signed, dated statement to a location, and the verifier fetches it. The statement says the same thing. The interaction does not exist.

| | Answering | Publishing |
|---|---|---|
| Notary learns who asked | Yes | **No** |
| Can charge per check | Yes | **No** |
| Availability at check time | The notary must be up | **Only the store must be up, and it can be mirrored by anybody** |
| Freshness | Exact | Bounded by the publication cadence |
| Matches the estate's own shape | No | **Yes: it is the register, and it is the published head from the history brief** |

The line worth carrying: **a notary that publishes cannot meter and cannot surveil, and those are the same property.** The ability to charge per check and the ability to observe every check are one capability seen from two sides, so a design that removes one removes the other. That is not a reason to reject metering; it is a reason to stop treating the privacy cost as a policy question. It is a consequence of the revenue model.

**So the honest commercial map has two products rather than one:**

| Product | Shape | What is sold | Privacy property |
|---|---|---|---|
| **Issuance** | The notary signs a dated assertion, once | The signature | Architectural: nothing is observed afterwards |
| **Lookup** | The notary answers, per call | The answer and its currency | Operational: every call is seen and retained long enough to bill |

And the tension to name rather than resolve: **issuance is better for the customer and worse for recurring revenue.** A signed assertion is bought once and verified a million times for free. A lookup is bought a million times. Anybody choosing between them is choosing between the customer's interest and the income statement, and a site whose thesis is about honest disclosure should say which it chose and why.

## A Budget Becomes A Trust Boundary

A consequence of paid verification that changes something already settled.

The June model establishes that resolution is the caller's responsibility and that a partial result is a legitimate answer: a resolver walks as far as it can, handles cycles, and returns what it reached along with where it stopped. The reason for stopping, in that model, is structural, being that it ran out of keys or hit a cycle.

**A priced notary adds a new reason for stopping, and it is not structural.** The resolver stopped because the next check cost more than it was willing to spend.

That has to be first-class rather than swallowed:

- **The resolver needs a budget ceiling**, which is the containment control this corpus has argued for since July and named as one of the cheapest available and least implemented.
- **The result must record what it declined to verify and why**, distinguishing not checked because unreachable from not checked because it cost too much. Those are different facts about the world and only one of them is about the network.
- **And the price becomes a security parameter.** A notary that raises its price reduces how deeply anybody resolves chains through it, which means a third party's pricing decision quietly changes the assurance level of every verifier downstream. That is a dependency nobody would put in a threat model and it is real.

The corpus's own discipline supplies the rendering: the gap is the finding. **A resolution result whose most interesting field is the list of things it did not check is behaving correctly**, and that list should be as visible as the verdict.

## Notary Is Not A Naming Collision

The fourth naming check in a fortnight, and this one passes, which is worth recording since three did not.

Three words have been caught colliding recently because each already carried a system meaning here: a twin is where a graph meets reality, a plugin is a capability grant, and a drive is what the positioning work calls the incumbent. **Notary carries no such meaning in this corpus and it is already used for exactly this purpose**, in the March document, for an external party that countersigns. Adopting it is consistent rather than colliding, and no decision is needed.

One caution that is about the word and not the corpus. A notary in the ordinary sense certifies that something was witnessed, and carries a legal weight this service will not have. **The site should say what it does not attest**, because a reader who imports the legal meaning will assume a liability position nobody has offered.

## What A Notary Answer Should Contain

Short, because the March object already supplies most of it and the additions are the corpus's own habits.

| Field | Why |
|---|---|
| Subject | Which key or entry, by fingerprint |
| Question | Stated so that a different question cannot be inferred from the answer |
| Answer | Confirmed, denied, unknown, or not checked, as four states rather than two |
| As of | The time the notary knew it, distinct from the time it was asked |
| Valid until | Or explicitly open-ended, which is a different and worse thing |
| Attester | The key identifier, per the March shape |
| Signature | Over all of the above |
| **Not checked** | **What this answer does not cover, and why** |

The last row is the one that will be dropped and it is the one that makes the rest honest. An answer that confirms one edge and silently declines three is indistinguishable, to its consumer, from an answer that checked everything.

## What This Does Not Try To Be

- **Not a new notary design.** The countersignature and the client-side verification level are from 13 March and are marked future rather than shipped.
- **Not a price.** The structural claim is that metering and surveillance are one capability; what to charge is a separate decision.
- **Not a recommendation of one mode.** Both are legitimate, they are different products, and the choice is commercial as much as technical.
- **Not a legal service.** The word carries a liability meaning this does not offer, and the site should say so.
- **Not the register interface.** That is the memo's second document.

## Honest Tensions

| Tension | Note |
|---------|------|
| Live lookup versus published statement | The published form removes surveillance and removes the revenue in the same stroke, so the privacy property has a price tag on it |
| The relationship graph | It is the most valuable asset a notary would accumulate and holding it contradicts the positioning that the server reads nothing |
| Issuance versus lookup | Issuance is better for the customer and is bought once, which is the worse of the two business models and the better of the two products |
| Unreachable as its own state | It is correct and it means every verifier needs a policy for a case that will happen constantly and has no good default |
| Budget as a trust boundary | It bounds spend honestly and it makes a third party's pricing decision an input to everybody's assurance level |
| Adopting the word notary | It is consistent with the corpus and it imports a legal expectation the service will not meet |

## Open Questions

| Question | Notes |
|----------|-------|
| Which mode ships first? | They are different products and building both at once means neither is finished |
| What is the default for unreachable? | It will be hit constantly, and neither trusted nor untrusted is right |
| Is the query graph retained at all? | Billing needs a count, not a subject, and the separation should be structural rather than a retention policy |
| What does a published answer's cadence cost? | Too slow and the answer is stale; too fast and it is its own growing record |
| Who may ask about whom? | A notary that answers anybody about anybody is an enumeration surface for the register |
| Does a countersignature travel with the entry or beside it? | March puts it in the object; the clean-file rule from today's history brief argues for beside |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 13 Mar | `v0.13.32__pki-workflows__operating-modes.md` | The countersignature shape and client-side verification levels, specified there as a future mode and inherited here |
| 5 Jun | `v0.32.4__dev-brief__sg-send-pki-public-key-registry-on-vaults.md` | The two-level trust model whose verification step is the memo's two-way conversation, and the partial result this brief gives a new reason for |
| 6 Aug | `v0.33.56__arch-brief__sg-send-token-gateway-resale-prohibited-in-line-forced-append-and-settle.md` | Being the meter costing the privacy claim, applied here to relationships rather than content |
| 20 Aug | `v0.33.61__arch-brief__register-was-designed-in-june-published-keypairs-are-fixtures-not-identities.md` | Workflow signing with a short-lived certificate and a public log, which is the signed mode with staleness engineered away |
| 20 Aug | `v0.33.61__arch-brief__history-is-the-append-only-log-record-stays-clean-objects-are-immutable-and-the-reference-is-not.md` | The published head, which is the same publish-rather-than-answer move applied to the reference |
| 27 Jul | `v0.33.52__arch-brief__sg-send-agentic-outbound-maturity-model-aomm-reach-motive-freedom-silence-could-has-will-liability.md` | Budget ceilings as the cheapest unimplemented containment control, which the resolver now needs |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The notary was specified on 13 March as a countersignature carrying its attester's key identifier |
| 2 | The same document makes verification depth a client-side setting, which is the memo's client-versus-provider distinction already designed |
| 3 | That specification is marked a future mode, so it is a design to inherit rather than a capability to cite |
| 4 | The two-way conversation is not a new requirement; it is the step that turns a self-declaration into a signal in the June model |
| 5 | An unreachable authority is a fourth state and must not render as either trusted or untrusted |
| 6 | A signed assertion and a live lookup are two products with opposite properties rather than two settings |
| 7 | Only the live lookup can be metered, because charging per check requires observing every check |
| 8 | What a live notary accumulates is a relationship graph that neither party handed over |
| 9 | That contradicts the positioning more sharply than the token gateway did, because it cannot be held encrypted |
| 10 | A notary that publishes rather than answers cannot meter and cannot surveil, and those are one property |
| 11 | Issuance is better for the customer and lookup is better for revenue, and the choice should be disclosed |
| 12 | A priced notary makes a budget a trust boundary, so a resolution result must record what it declined to check and why |

---

## Sources

- The March PKI workflows document specifying an external countersignature from an auditor, compliance system or notary service, carried as an attestations array naming the attesting key identifier alongside the branch and author signatures, and setting verification depth as a client-side configuration whose highest level verifies those countersignatures for legal and regulatory evidence chains, marked as a future mode not intended for initial implementation; and the June registry design with downward trust asserted by the truster, upward trust self-declared and granting nothing, verification by asking the named party, and confirmed, pending and explicitly distrusting outcomes all treated as signals: the project repository, cloned and searched on 20 August 2026, with both documents named in the relationship table above

---

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