vesta: SPEC-126/127/128/129 — per-community access model, disclosure leaves, Insiders ledger, tier names

[koad]

Vesta flight 20260418T215033-324Z-vesta-6c8178 — specs delivered

Follows up on SPEC-123/124/125 (visitor verification, canonical identity, badge format) from the earlier session. The visionary session (Iris/Muse/Faber round 2) reshaped the model: access is per-community, not per-kingdom-ladder. These four specs canonicalize that shift.

Commit SHA: 6dc316e on github.com/koad/vesta (mirrored to Keybase)

---

Specs shipped

VESTA-SPEC-126 — Community Model

Decision: Communities are self-declaring, authority-signed requirement sets. No central registry. The signing key is the trust root; surface operators decide whose requirement sets to load. Gate evaluation is always per-community; the reads_leaves declaration on each feature entry drives the /me dependency surfacing. Versioning: current version at eval time; no retroactive denial.

~/.vesta/specs/VESTA-SPEC-126-community-model.md

VESTA-SPEC-127 — Disclosure Leaf Protocol

Decision: All leaves default to undisclosed except public artifacts (published keys, XP signals, profile quality, flight count — facts the visitor already made world-readable). Per-community disclosure is the visitor's sovereign control: the evaluator treats undisclosed leaves as absent. Amends VESTA-SPEC-124 VisitorProfiles schema: old verification and memberships fields deprecated; replaced by an explicit leaves array.

~/.vesta/specs/VESTA-SPEC-127-disclosure-leaf-protocol.md

VESTA-SPEC-128 — Event-Sourced Insiders Ledger

Decision: One Insiders document per user; _id === users._id. Events are immutable; state is always derived from events. Feature flags live in state.features and are computed by the InsidersFeatureRegistry derivation rules. Adding a new feature = adding a key to the registry + a background re-derivation job + a new requirement set entry. No schema migration of existing Insiders documents.

v1.0 event types: github-sponsor.start, github-sponsor.change, github-sponsor.end, one-time.payment, crypto.gift, alice.graduated, bond.signed, manual.grant, manual.revoke.

~/.vesta/specs/VESTA-SPEC-128-event-sourced-insiders-ledger.md

VESTA-SPEC-129 — Access Tier Names

Decision: Four canonical slugs: explorer, regular, insider, patron. "Sovereign" retired as a tier name (word reserved for the philosophy). "Operator" retired as a tier name (word reserved for kingdom operators in the entity model). Display names are Iris and Mercury's territory; slugs are protocol constants.

~/.vesta/specs/VESTA-SPEC-129-access-tier-names.md

---

Interactions with prior specs

• SPEC-123 produces daemon scorecards → SPEC-127 converts them to profile_quality, xp, flight_count leaves
• SPEC-124 VisitorProfiles schema amended by SPEC-127 (leaves array)
• SPEC-125 badge format → SPEC-127 member_of leaf
• SPEC-126 requirement evaluator reads SPEC-127 disclosed leaves and SPEC-128 state.features
• SPEC-128 derivation uses SPEC-129 tier slugs and TIER_ORDER

---

Tensions from visionary output — resolved

Faber's "sponsor vs sovereign path as different kinds of access": SPEC-126/127 resolve this cleanly. There is no "two paths" — there is one profile tree of leaves that multiple independent communities evaluate differently. The sovereign path produces different leaf types (entity, profile_quality, xp, holds_bond) than the sponsor path (insiders_state with currently_subscribed: true). Communities weight them independently. Faber's position is vindicated by the model.

Iris and Muse's "Sovereign" tier name concern: Retired in SPEC-129. "Patron" is the top tier. The word "sovereign" is reserved for the philosophy.

Iris's community registry question ("ratified by someone vs self-declared by any operator"): Decided in SPEC-126 §2: self-declaring. No central ratifier. Surface operators decide which communities to load. This is the sovereignty principle applied to communities themselves.

---

Follow-up specs surfaced

1. SPEC-111 amendment — koad.badge-claim sigchain entry type (flagged in SPEC-125 §3.7); still pending. Also: koad.identity-claim entry type for identity upgrade path (SPEC-124 §3.5).
2. Leaf portability across kingdom boundaries — SPEC-127 notes this as out of scope; it requires a cross-kingdom trust spec building on SPEC-115.
3. Scorecard modal trigger location — Muse left this open (nav? badge on entity page?). This is Faber's call and a Vulcan implementation detail; no SPEC needed unless it touches protocol.
4. Community display names governance — Iris asked who writes the name field in the requirement set. SPEC-126 §3.2 defines the field; who writes it is a content governance question, not a protocol question. Juno should assign.
5. insiders_state leaf privacy refinement — SPEC-128 §3.8 notes that surfacing the full state object (including lifetime_usd) may be more disclosure than needed; a future SPEC could narrow the leaf to state.features only.

---

Vulcan's implementation order

Suggest: SPEC-129 (tier names — just constants) → SPEC-128 (Insiders ledger — the data model) → SPEC-126 (community model + evaluator) → SPEC-127 (leaves + disclosure dashboard). Each spec depends on the prior in that order.

/cc @koad