visionary: faber — visitor arc, stranger to sovereign

[koad]

Faber's visionaries session output

Draft committed at: ~/.faber/visions/2026-04-18-visitor-arc.md
Commit: b8421e5

---

What's in the draft

A synthesis + sequence document covering the visitor's arc from first encounter to vested participant. Five stations: Witness, Reader, Enrolled, Active, Vested.

Core editorial position: Sponsor path and sovereign path should diverge, not converge. Sponsors earn consumption privileges (see more, chat more, longer context). Sovereigns earn participation privileges (bonds appear on entity pages, entity discoverable in kingdom grid, contributions credited in activity feed). These are not equivalent amounts of the same thing — they are different kinds of access.

Implementation brief for Vulcan:

1. Access card must show both paths side by side, not one preferred + two fallbacks
2. Profile quality levels need user-facing names (not just slugs) — suggested: Seeded, Rooted, Witnessed, Published
3. Verification metaphor: handshake, not passport — "Prove you hold these keys"
4. Remediation copy must be specific and actionable — Iris writes it, Vulcan exposes the field
5. Partial visibility ships in Phase 1, not Phase 5 — partial projections are the first impression

Key editorial calls:

• XP visible only in scorecard + access card. Never in the nav. Not a score, a passport stamp.
• Groups are credentials, not tribes. One-time achievement, permanent record.
• Lapsed sponsor retains sovereign-tier participation features. No penalty state.
• XP is not spendable. It is a record of work done, not a currency.

---

Open questions for second round

• Iris: what does the access card voice say at Station 0, before the visitor has vocabulary?
• Muse: what does a gestated entity card look like in the kingdom grid vs a mature one?
• Juno: is Alice's curriculum the only path to alice-graduates, or can equivalent competence qualify?

---

Standing disagreement with brief

The brief frames sponsorship and sovereignty as parallel routes to the same content. Faber's position is they lead to different kinds of access. If koad disagrees, the content strategy diverges substantially. Flagged as open question, not patched past.

Related briefs: briefs/kingofalldata-tiered-data-access.md, briefs/entity-harness-generalization.md

Part of the visionaries session: Iris and Muse drafts pending.

[koad]

Faber — Round 2 of the visionaries session

Filed: ~/.faber/visions/2026-04-18-visitor-arc.md (Round 2 section appended)
Commit: b97082c — vision: visitor arc round 2 — contextual community scoring model

---

What changed

Round 1 drew a five-station ladder. Round 2 replaces the ladder with a profile tree.

The corrected model: profiles emit cryptographically-verifiable leaves (keys, flights, bonds, credentials, payment, group memberships). The profile owner controls which leaves are disclosed per community. Each community defines its own requirement set and weights the leaves it sees. Scoring is always on the reader's side; disclosure is always on the owner's side.

This resolves several round-1 ambiguities:

• The "two paths" (sponsor, sovereign) are not parallel tracks. They produce different leaf types. Access is determined by which leaves you disclosed and which communities weight what.
• alice-graduates is one leaf. koad:io can weight it. Another community can weight it too if the owner discloses it and that community wants to. No system-wide policy.
• The "first sovereign moment" is now precisely: the moment a visitor realizes their leaves are portable across communities and disclosure is in their hands.

---

Flags for peers

Iris: Two items.

1. Your round-1 voice brief wrote access-card copy as if there is one universal requirement set. The card is community-scoped. The copy pattern is right, but it needs to be authored per community, not site-global. Please update your brief when you see this.
2. The "Sovereign" tier-name collision Muse flagged is sharper under this model. "Sovereign" as a $100/mo tier name actively undermines the sovereignty-as-disclosure-ownership concept. Recommend renaming the tier.

Muse: Two items.

1. Your premise "the paths arrive at the same content" was the flat-ladder model. Under the corrected model, the access card needs a community identifier — small label, "evaluated by: koad:io insiders" — so the visitor knows their standing is community-scoped, not universal.
2. The scorecard is now two distinct views: in-context community modal (your standing here, for this gate) and /me full disclosure management (all your leaves, which communities see which). Both need design. Both need Vulcan templates.

Vulcan (via Juno): Five spec items are in the Round 2 section of the doc. Key ones: communities are first-class data entities with named requirement sets; the scorecard has two shapes; disclosure is a user-controlled boolean per leaf per community; credential validity is cryptographic + owner consent (no cross-community politics); remediation copy is community-scoped.

---

Open question for Juno

Who authors a community's requirement set, and how are those requirements versioned? koad defines the koad:io insiders community for now. As the system scales to multiple kingdoms, this needs a protocol. Flagging as a Vesta spec question, not holding up execution.