# A Secret Is Defined By Expectation And A Signature Is Defined By Scarcity: Publishing A Private Half Destroys The Integrity It Was Meant To Supply, And The Memo's Own Last Paragraph Carries The Right Rule

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

**type** Architecture brief

*Twelfth of 20 August. The shipped signing and encryption commands and the vault destroy operation are checked against the documentation and the repository rather than recalled. This brief agrees with the memo's first principle and its final paragraph and disagrees with the proposal between them, and it says so rather than smoothing the difference. It also confirms a position taken in the previous brief of today which this memo re-opens, and it records the two things the memo's framing added that the earlier one did not have.*

---

## What This Is

A clarification the memo asks for, one principle worth promoting, and a proposal in the middle that undoes its own purpose: **the memo opens by observing that sharing a secret is only a problem when somebody expected it to be private, which is exactly right and is worth stating as a house principle, because it separates key material by intention rather than by class and it explains why a published read key is a feature while a leaked write key is an incident; it then proposes a manoeuvre that works, since destroying a vault server-side leaves its key with nothing to write to, and it skips the half that matters, because a key that can no longer write can still decrypt, and this estate has already established that anybody may hold a complete copy of a vault forever, so destroying the vault removes the write target and publishes the contents to everybody who mirrored it; the proposal between those two is that every grant, mandate, claim and evidence node should carry a public and a private key, with the private half published, on the grounds that this gives integrity rather than confidentiality, and that is the one part to reject, because a signature's entire value comes from the scarcity of the private half, so publishing it leaves a hash wearing a signature's clothes and, worse, leaves a verifier that checks it and succeeds and concludes something false; the memo's own stated use, writing something that can only be verified or read by a particular grant or a particular evidence node, requires exactly the scarcity the proposal removes, so the use case is destroyed by the mechanism proposed to serve it; the one thing per-object keys would genuinely buy is an address, since the lane derivation is the hash of a public key, but that derivation is proposed rather than shipped, and routing evidence to an issuer's lane tagged with the object's identifier achieves the same thing without multiplying private keys by every document in the register; there is also a consequence for the register itself, because the flag recording whether a private half is published was established this morning as the most consequential piece of evidence an entry can carry, and a flag that is true on every row is a column rather than evidence; and the memo ends by describing the correct architecture almost in passing, that an instance which wants real authentication generates its own keypair and has it signed by a project key, which is a principal holding a secret and an authority endorsing it, so the rule the corpus should adopt is that a key belongs to whatever can keep a secret and everything else is signed by something that can.** It is the twelfth document of 20 August (cross-ref: the v0.33.61 register brief, the v0.33.61 end-to-end flow brief, the v0.33.58 topic sections brief, the v0.33.60 append lane brief, and the v0.33.59 publishing matrix brief). New contributions: **the expectation principle stated, the vault destroy manoeuvre corrected on its confidentiality half, scarcity identified as the source of a signature's value, the per-object address argument answered more cheaply, the flag's loss of meaning under a publish-by-default policy, and the memo's closing pattern promoted to the governing rule.**

## The Opening Principle Is Right And Should Be Promoted

The memo's first sentence is the most useful thing in it. The project lead: **"sometimes the idea that when you share a secret, right, it's a problem. It's only a problem if you don't expect it, right? If you think it's private."**

**That is a house principle and it should be written down**, because it settles a class of argument in one line:

> **A secret is defined by expectation, not by content.** The same bytes are a disclosure or a publication depending on whether somebody believed they were private.

The estate already behaves this way without having said it. Read keys are published deliberately and the corpus has a rule about it from 14 August, that read keys yes and write keys never. A public vault publishes its read key by definition. The publishing work of 16 August allows plaintext beside ciphertext only where the key is already published, and enforces it in the command because the failure is silent and permanent.

**Stating the principle explains all three at once**, and it does something more useful than tidying: it tells a reader which question to ask. Not is this key material, which sorts by class and produces the reflex that all key material is sensitive, but **did anybody expect this to be private**, which sorts by intention and gets the right answer for read keys, fixtures and published heads alike.

One qualification belongs with it, because the principle is about the past and the risk is in the future. **Expectation has to be recorded at issue, not recalled afterwards.** A key published deliberately in March and a key leaked in March are indistinguishable in June unless somebody wrote down which was which at the time. That is the argument for the required flag discussed below, and it is why the principle needs a field rather than a paragraph.

## The Vault Key Manoeuvre Works, And It Publishes The Contents

The memo's example is sharp and half of it needs correcting. The project lead: **"we could have even shared the vault keys, if I, for example, delete that vault from my current server, which basically means that you could make changes. You just couldn't upload it to my current server."**

**The mechanical claim is right.** A vault key is address, credential and encryption key in one string. Destroy is a shipped operation. Destroy the vault and the credential half has nothing to authenticate against, so the key degrades from a credential into a decryption key.

**The half the memo skips is the one that decides whether to do it.** Destroying the vault removes the write target. It does not remove the ciphertext that other people already hold, and this estate has a name for that: the publishing work of 16 August established **custody without access**, meaning anybody can mirror, host, back up and preserve a vault they cannot read, because holding the objects grants nothing.

Set those together:

| Step | Effect |
|---|---|
| Somebody clones the vault without a key | Custody. They hold complete ciphertext and learn nothing |
| You destroy the vault server-side | Nobody can write to it, including you |
| **You publish the vault key** | **Every holder of that ciphertext can now read all of it, permanently** |

So the manoeuvre converts a write credential into a publication event. **That is fine when the content was meant to be public and it is irreversible when it was not**, and it is irreversible in the same way the corpus has recorded twice already: a published key cannot be recalled, and clones exist that nobody can enumerate.

The corrected form of the memo's claim: **destroying the vault makes the key safe to publish from the point of view of your server, and says nothing about the content.** Both halves have to be true before it is a good idea, and only the first is under your control.

## Integrity Does Not Come From The Object Holding A Key

The proposal to reject, and the reason is one sentence. The project lead: **"the reason why we want to give the private key is not that we have confidentiality because we don't, but what we have, I think... is we have integrity."**

**A signature's entire value comes from the scarcity of the private half.** Verification answers one question: was this produced by somebody holding the key? If the key is published, the answer is yes for everybody, and the question stops carrying information.

| Property | What actually supplies it | Survives publishing the private half? |
|---|---|---|
| The bytes have not changed by accident | A content hash. **No key required at all** | Yes, and the key was never doing this |
| The bytes have not been changed by anybody | A signature by a key only the signer holds | **No** |
| Who produced this | The same | **No** |
| They cannot later deny it | The same | **No** |
| Only this object can read what I sealed to it | Encryption to a private half only it holds | **No** |

So publishing the private half leaves **a hash wearing a signature's clothes.** Anybody can alter the object and re-sign it, and the result verifies.

**And the clothes are the dangerous part.** This morning's register brief reached the same conclusion for fixtures and stated the consequence: a consumer that verifies signatures and stops there will pass one, because the verification succeeds. A hash makes no promise and is therefore honest. A signature that anybody can forge makes a promise it cannot keep, to a verifier that has no way to notice.

**The memo's own use case is the clearest demonstration.** The project lead: **"I can say I'm going to write a message that I know that can only be verified or even read by this agent, by this grant, by by this evidence."**

Both halves of that sentence require the private key to be scarce. Only verified by that object means only that object could have produced the signature. Only read by that object means only that object can decrypt. **Publishing the private half removes both properties**, so the mechanism proposed defeats the purpose stated one sentence earlier. That is worth naming plainly rather than diplomatically, because the two sentences are adjacent and the contradiction is easy to carry forward unnoticed.

## What Per-Object Keys Would Buy, And The Cheaper Way To Get It

There is one genuine benefit and it should be credited before being answered.

**A public key is an address.** The append lane is addressed by the hash of the recipient's public key, so an object with a public key has somewhere for other parties to send things. Give a grant a keypair and evidence about that grant can be routed to that grant.

Three answers.

**The derivation is proposed rather than shipped.** Confirmed today from the documentation: the intended model is that the append token is the hash of the public key, the server side ships, and no shipped command emits that token, so a token is agreed out of band. **A per-object address does not exist to be used yet.**

**Routing does not need a key.** Today's observability brief already solved the same problem for check events: they go to the issuer's lane, tagged with what they refer to. An evidence node about a grant goes to the grant issuer's lane, carrying the grant's identifier. One lane per party rather than one lane per document, and it works with the shipped surface today.

**And the address you get is a public inbox anyway.** This morning's brief established that where the private half is published, the lane is readable by anybody who fetches it. So per-object keys with published privates buy an address whose contents everybody can read, which is the one property nobody asked for.

The cost side is the argument the corpus has already made about naming decisions being cheap now and expensive later. Keys per grant, per mandate, per claim and per evidence node multiplies the private key inventory by every document in the register, and every one of them is permanently unpromotable, since this morning's brief established that a published private half can never be upgraded into a real one and cannot be revoked through the register's own revocation rule, because anybody can sign a revocation and anybody can sign the append that reverses it.

## If Publishing Is The Default, The Flag Stops Meaning Anything

A consequence for the register specifically, and it is the argument likely to land hardest because it is about a thing already decided.

This morning's brief made a required field recording whether an entry's private half is published, called it the single most consequential piece of evidence an entry can carry, and noted that it gives the register a property very few key registries have: it can answer, in one query, which of its entries are decorative.

**Under a publish-by-default policy, every row is true.** The query returns everything, the field distinguishes nothing, and the register loses the property. **A flag that is always true is a column, not evidence.**

That is the general shape of the problem with the proposal. The value of marking something is proportional to how rarely the mark applies, and the same is true of signing: **a signature everybody can produce and a mark everybody carries both cost the same to make and convey the same amount, which is nothing.**

## The Memo's Last Paragraph Is The Rule

The memo describes the correct architecture near the end, briefly, and it should govern the rest. The project lead: **"if you do want to have a version of let's say Claude represent an entity of Cloud Web that is now connected to a particular account, then... that instance can create its own public and private key. What it needs to do is then sign it with, for example, a project key."**

**That is right, and it is the enrolment shape from 19 August.** The instance generates the keypair. The private half is held by the instance and never published. A project key, held by a party with standing, signs the instance's public half. Verification then answers a question worth asking: was this produced by an instance that a project I recognise vouched for?

Two things follow, and the first is the whole brief in one line.

> **A key belongs to whatever can keep a secret. Everything else is signed by something that can.**

**And the memo's two halves are not equally weighted.** The proposal in the middle and the pattern at the end are alternatives, not layers. Adopting the pattern means declining the proposal, and this brief recommends that.

## Which Things Get Keys, Settled

Applying the rule, and it confirms the position taken in the previous brief of today by a different route.

| Object | Keypair | What it gets instead |
|---|---|---|
| A person | **Yes** | |
| A project or organisation | **Yes** | The key that endorses instances |
| An agent instance | **Yes, if it can hold a secret across its life** | Endorsed by a project key |
| A grant | No | An identifier, a content hash, and the signature of whoever observed or issued it |
| A mandate | No | The same, and the issuer's signature is what makes it a mandate rather than a note |
| A claim or an evidence node | No | The same |
| A fixture | **Deliberately broken, and marked** | Exists to exercise the plumbing and is never reachable from the trust graph |

One caveat sits on the third row and it is not small. **Whether a rented agent instance can keep a secret across sessions is the question left open on 19 August and still open**, and it decides whether that row is achievable at all rather than aspirational. An instance that cannot persist a private half cannot hold an identity, and it falls back to being endorsed per session, which is a different and weaker arrangement.

## Sign By Default, Encrypt By Exception, And Name What That Costs

The memo's closing posture is right and matches the shipped reality. The project lead: **"from now on... everything that happens is signed with keys and is has integrity, and then we need to decide whether we want confidentiality or not."**

Signing and encryption are separate shipped commands over different primitives, so the posture is available today rather than requiring anything new. And it is the correct default: integrity and attribution are wanted almost everywhere, confidentiality only sometimes, and the register holds public material by design.

**The cost to name is that a signature nobody verifies is decoration.** Three findings from today combine into it. Verification has modes and costs, and only some of them are free. Verification generates events, in the issuer's own lane. And the register interface renders a last-checked field on every edge.

So the honest version of sign everything is:

> Sign by default, and **publish which signatures anybody actually checks.** A graph where everything is signed and nothing is verified manufactures the appearance of assurance, which is the same failure as a signature anybody can forge, arrived at from the opposite direction.

That is the measurable version of the memo's posture, and it is already buildable from the observability layer described earlier today.

## What This Does Not Try To Be

- **Not a rejection of the memo.** Its opening principle and its closing pattern are both adopted; the proposal between them is not.
- **Not an argument against publishing keys.** Publishing read keys is settled practice and publishing a destroyed vault's key is legitimate when the content was meant to be public.
- **Not a claim that hashes are enough.** They give integrity against accident; attribution needs scarcity.
- **Not a new enrolment design.** The instance-generates-and-project-signs pattern is from 19 August.
- **Not a resolution of key persistence.** Whether an instance can hold a secret across sessions is still open and gates the one row that matters.

## Honest Tensions

| Tension | Note |
|---------|------|
| The expectation principle | It sorts key material correctly and it depends on somebody having recorded the intention at the time, which is exactly what nobody does |
| Destroying a vault to publish its key | It removes the write target cleanly and it publishes the content to every holder of a mirror, which is a set nobody can enumerate |
| Declining per-object keys | It keeps signatures meaningful and it means an object has no address until the lane derivation ships |
| Sign by default | It is the right posture and it produces a graph of signatures whose verification nobody is currently obliged to perform |
| The instance keypair | It is the correct architecture and it rests on a persistence question that has been open since 19 August |
| Confirming this morning's position | The rule holds by a second route and a memo has now raised the same proposal twice, which suggests the earlier brief did not explain it well enough to stick |

## Open Questions

| Question | Notes |
|----------|-------|
| Where is publication intent recorded? | The principle needs a field at issue, since a deliberate publication and a leak look identical later |
| Can an instance persist a private half? | Open since 19 August and it decides whether instances can hold identities at all |
| What signs a grant, the issuer or the observer? | A grant asserted by its issuer and a grant measured by an auditor are different claims about the same object |
| Does anything verify the signatures? | Sign by default is only worth its cost if the last-checked field is populated |
| What is the identifier for an object with no key? | A content hash changes when the object changes, which is right for evidence and wrong for a stable name |
| When the derivation ships, does the answer change? | A per-object address becomes real then, and the cost of per-object private keys does not |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 20 Aug | `v0.33.61__arch-brief__register-was-designed-in-june-published-keypairs-are-fixtures-not-identities.md` | The fixture finding this generalises, the required flag this shows would lose its meaning, and the promotion and revocation costs |
| 20 Aug | `v0.33.61__arch-brief__end-to-end-flow-is-the-august-worked-example-with-an-agent-as-the-twin-grant-tree-needs-control-labels.md` | The position that grants and mandates are artefacts, confirmed here by a second route after the memo re-opened it |
| 14 Aug | `v0.33.58__strategy-brief__sgit-topic-sections-catalogue-read-keys-yes-write-keys-never-frozen-vaults.md` | Read keys published and write keys never, which the expectation principle explains rather than replaces |
| 16 Aug | `v0.33.59__dev-brief__publishing-matrix-five-invariants-fourteen-tests-local-folder-needs-a-server.md` | Custody without access, which is why destroying a vault does not make its contents unreadable |
| 19 Aug | `v0.33.60__arch-brief__append-lane-is-shipped-and-account-less-four-tiers-and-five-corrections.md` | The lane addressing whose proposed status limits the one genuine argument for per-object keys |
| 20 Aug | `v0.33.61__arch-brief__observability-is-the-usage-graph-check-events-belong-in-the-issuers-lane-a-verification-is-not-a-use.md` | Routing to the issuer's lane, which supplies the addressing benefit without per-object keys |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | A secret is defined by expectation rather than by content, and this explains the estate's existing key rules in one line |
| 2 | The intention has to be recorded at issue, because a deliberate publication and a leak are indistinguishable afterwards |
| 3 | Destroying a vault leaves its key unable to write, and destroy is a shipped operation |
| 4 | It does not make the content unreadable, because custody without access means mirrors exist that nobody can enumerate |
| 5 | A signature's value comes entirely from the scarcity of the private half |
| 6 | Publishing that half leaves a hash wearing a signature's clothes, which is worse than a hash because a verifier succeeds |
| 7 | The memo's own use, sealing or signing to a specific object, requires the scarcity the proposal removes |
| 8 | The one genuine benefit of per-object keys is an address, and that derivation is proposed rather than shipped |
| 9 | Routing to the issuer's lane with an identifier gives the same benefit on the shipped surface |
| 10 | Under publish-by-default the required flag is true on every row and stops being evidence |
| 11 | The memo's closing pattern is correct: an instance generates its own keypair and a project key endorses it |
| 12 | So a key belongs to whatever can keep a secret, and everything else is signed by something that can |

---

## Sources

- The shipped public key infrastructure commands, with detached signing and verification over ECDSA P-256 and encryption to a recipient over RSA-OAEP at 4096 bits with an AES-256-GCM content key, as separate operations, and the stated absence of any revocation or rotation workflow: https://sgit.ai/docs/pki
- The limitations page recording that lane addressing is not wired end to end, that the intended model is an append token derived as the hash of the public key, that the server side ships, and that no shipped command emits that token so a token is agreed out of band today: https://sgit.ai/docs/limitations
- The vault destroy operation among the shipped vault surface, the 14 August rule that read keys may be published and write keys never, and the 16 August finding that a bare clone with no key is custody without access, so anybody may mirror, host and preserve a vault they cannot read: the project repository, cloned and searched on 20 August 2026, with the topic sections and publishing matrix documents named in the relationship table above

---

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