---
status: located
opened: 2026-09-23
located-in: [mesh-controller internal/catalogue/seats.go (the seed lacks mesh-vault), mesh-catalog modules/mesh-vault/module.json (claims nothing)]
fixed-by: 
amended-design: [03-DESIGN/01-to-be/26-the-seats.md]
---

# 106 — The vault claims no seat, so nothing refuses a second one

## What was observed

Reading the registry, 2026-09-23. The vault provides `secret` to the whole mesh and **claims no
seat**. The store, the broker, the controller and the catalogue each claim one, named after
themselves, so that a second claimant is refused at resolution
([ADR 0079](../../02-DECISIONS/0079-the-foundation-seats-are-named-after-their-servers.md)). The vault
was added after that record and did not inherit the rule.

## Why it matters beyond this instance

The vault holds every credential the mesh mints. A second vault, assigned by mistake or by a module
that provides `secret` itself, would answer requirements the first was answering, and nothing in
resolution would object. Of all the components to allow two of silently, this is the one to allow
least.

The rule is already written; this is an instance it was not applied to. Worth asking whether
others were missed the same way — every provider added after 0079.

## Open questions

- A mesh-scoped seat `mesh-vault`, by the 0079 convention — is there any reason not to?
- Should a provider of a mesh-scoped provision be required to claim a seat, or say explicitly that
  more than one is allowed, so the omission cannot recur?

## Decided, 2026-10-01

[ADR 0161](../../02-DECISIONS/0161-what-deserves-a-seat.md), rule 1: `mesh-vault` joins the mesh's
own set, mesh-scoped, delivering `secret`, and the vault claims it; a second provider is a second
claimant, refused by name. The record also answers the second question: a provision the mesh's own
code dereferences by name gets a seat, every other mesh-scoped provision may have several providers.
Design 26's *reserved* for `secret` named an effect no rule produced; corrected there.