ADRs 0091 and 0092; issues 026 and 070 resolved; designs 18 and 24 amended

03-DESIGN/01-to-be/24-the-secrets-vault.md

@@ -4,6 +4,7 @@ status: implemented
 code: [mesh-catalog, mesh-controller, mesh-host]
 updated: 2026-09-21
 decisions:
+  - 02-DECISIONS/0092-an-operator-delivers-a-pair-credential.md
   - 02-DECISIONS/0085-a-secret-is-a-provision.md
   - 02-DECISIONS/0031-the-control-plane-authenticates-nobody.md
   - 02-DECISIONS/0048-a-provider-creates-the-credential-the-mesh-minted.md
@@ -45,7 +46,12 @@ whose job it is to give it one."*
 
 A module that needs a secret for its own use requires a `secret` provision, exactly as it requires
 a database from the store. The vault generates the value — or takes custody of one an operator
-delivered — and the credential belongs to the consumer↔vault pair. Because it is an ordinary pair
+delivered, through `secret accept … --provider`, which seals it to both ends and records the pair
+as accepted ([ADR 0092](../../02-DECISIONS/0092-an-operator-delivers-a-pair-credential.md)) — and
+the credential belongs to the consumer↔vault pair. An accepted pair is the one exception to what
+follows: the mesh cannot make its replacement, so it is neither remade when a key changes nor
+rotated; both are refused aloud, and accepting a new value is the rotation. *How it is checked:*
+an inventory test accepts, reads back unchanged, and asserts the two refusals name the remedy. Because it is an ordinary pair
 credential, **everything already built for pair credentials applies to it unchanged**: it rotates
 with the one command that discards a credential and delivers both ends together, it is one secret
 per holder so rotating one touches nothing else, and *who holds this* is a query rather than an