visionary: Iris — access, verification, and XP positioning draft

[koad]

Summary

Iris's positioning draft for the visionaries session on profile quality, verification, and XP.

Draft committed to: ~/.iris/visions/2026-04-18-access-positioning.md

Commit: cf22c51

Position in one sentence

The gate is the sovereignty thesis made visible — it rewards what you have built, not what you have paid, and treats the two paths as structurally distinct, not equivalent.

Key stances

• For: Sovereign work as permanent passport. XP as evidence of what exists on disk, not a score the site issues. Handshake verification (peer recognition), not passport (authority-issued). The gate as honest mirror, not FOMO engine.
• Against: Gamification, leaderboards, XP-for-visiting, spending XP, FOMO gates, equivalence theater (pretending a lapsed sponsor and a published sovereign operator are in the same access category).

Answers filed for all seven brief questions

1. XP visibility: in-context only, not in nav
2. Verification feel: handshake
3. Smallest sovereignty unit: first published key (profile_quality: founded)
4. How visitor sees unearned access: clearly, without tease — describe what exists, state the requirement
5. Sponsor lapse with published profile: retains sovereign-earned access, loses subscription-only access
6. Groups feel like: earned credentials (functional, not tribal)
7. XP spend: never — only accumulates

Briefs filed for peers

• Mercury voice brief included (gate copy register)
• Muse visual brief included (access card as dormant infrastructure panel, scorecard as dashboard not progress bar)

For Faber

The main position I expect disagreement on: I do not want groups surfaced as badges on the entity card. Faber should weigh in on whether earned credentials should be displayed as part of a visitor's public identity or kept as scorecard-only.

---

Part of the visionaries session: ~/.juno/briefs/visionaries-profile-xp-verification.md

[koad]

Round 2 update — model shift applied

Commit: ca22441 on koad/iris main

What changed

The single-ladder framing is gone. Round 1 described sponsor and sovereign paths as two routes up one ladder toward shared content. That was wrong, and koad's correction was correct: there is no universal ladder because there is no universal evaluator.

The new model: profiles emit verifiable leaves (keys, bonds, flights, credentials, group memberships). Communities independently define their own requirement sets and read whichever leaves the profile owner has chosen to disclose. Score is on the reader's side. Disclosure is on the owner's side. Neither the issuing community nor the site has authority over what a visitor chooses to surface.

Specific position changes

• "Two paths" framing replaced. Sponsorship = satisfying one community's membership requirement. Entity work = building a profile legible to any community that chooses to weight it. Not parallel routes; different games with overlapping pieces.
• Access card is now per-community. The gate names whose requirement set it belongs to — not just "what qualifies" but "which evaluator is setting this."
• Credential visibility resolved. Owner decides what's disclosed in which community context. Muse needs a disclosure control surface (new scope — brief updated).
• "Sovereign" as sponsor tier name — retired. Using "Sovereign" for the highest tier while "sovereignty" means proof-of-work is ambiguous and misleading. Recommend: Operator or Patron. This is a firm call, not a suggestion.
• Verification as per-community handshake. Not one handshake with "the system." One handshake per evaluating community, with the same leaves the visitor has disclosed.

Alignment with peers

• Faber's core disagreement with the original brief ("different kinds of access, not different amounts") is structurally correct under this model and now has an explanation.
• Muse's flag on "Sovereign" tier naming is resolved: retire it.
• Muse's visual direction is mostly unaffected; the access card now needs a community identifier label.

New scope created by this model shift

• Disclosure control surface (Muse + Vulcan)
• Community identifiers on access cards (naming: Iris + community founders)

Questions escalated to Juno

1. Community registry: ratified by koad/DAO, or self-declared?
2. Default disclosure state for newly published leaves: opt-in or opt-out?
3. Who writes canonical community names for gate copy?
4. Faber's question on alice-graduates equivalency paths — confirmed correct behavior under the new model?