Quartz 4

guild-roles

8 min read

Guild Roles — Staff / GM / Member

Design for the role model that governs who has what permissions, what presence visibility, and what responsibilities in Guild.

The problem

Right now, Panat and Carrie each have a single account that’s both a Staff account (admin dashboard access) and a Member account (personal check-ins, purchases, XP). This conflation has two problems:

  1. Privacy leakage. Carrie surfaced this directly: she wants personal shopping activity kept private from her staff context. A single account makes that impossible — any audit trail of member activity includes her own.
  2. Role ambiguity for new contributors. As the community grows, there’s a natural emergence of people who aren’t employees but who run things (event hosts, GMs, volunteer moderators). With only “Staff” and “Member” as categories, there’s no clean place for them — they end up either over-privileged (given full Staff access for moderation tasks) or under-recognized (treated as regular Members despite material contribution).

This is a design decision we need to make before shipping any role-gated feature (staff presence, apprentice mentorship, GM-specific tooling, discretionary XP bonuses, etc.).

The three-tier model

TierWhoPermissionsMMO analogue
StaffPaid employees (Panat, Carrie, and anyone formally on payroll)Admin dashboard, ledger write access, discretionary XP bonus authority, ability to modify member recordsActual MMO employees (GMs in the literal sense)
GMNon-employees who run things (event hosts, mods, volunteer session leaders, future apprentice-masters)Named presence, event-hosting tools, public identification as a GM in Guild, possibly limited moderation tools. No admin dashboard access.MMO volunteer GMs — the old-school kind, pre-outsourcing
MemberEveryone elseSelf-serve: own profile, own XP ledger, own purchases. No admin, no moderation.Regular player

Key principle: permissions and responsibilities are separate axes from recognition. Being recognized as a GM (visible badge, presence as a host, named on events) does not require admin access. Staff has admin access because the job requires it, not as a reward.

Examples

  • Panat — Staff (engineer/owner) + has a Member side for personal shopping (level progression, check-ins when not on shift).
  • Carrie — Staff (manager/owner) + Member side for personal shopping.
  • Tom (hypothetical) — Member who runs weekly D&D sessions. He is a GM but not Staff. Surfaces as a host on the event pages, appears in presence as “GM on shift when running a session,” but cannot see other members’ purchase history or award XP bonuses.
  • Kris and Allan (current name-level candidates) — Members. If they take the apprentice-master role at V2 name level, they become eligible for GM (see Apprentice → GM pipeline below).

Architecture decision: separate accounts vs. role-scoped views

Two ways to solve the privacy problem:

Option A: Separate accounts

Panat-Staff and Panat-Member are two distinct accounts with separate auth, separate data, and separate views. Same person, two logins.

Pros:

  • Clean data separation by default — can’t accidentally leak Carrie’s personal purchase history through a staff admin surface.
  • Simpler mental model: the account is the role.
  • No complex permission-scoping logic at the query layer.

Cons:

  • Context-switching friction (log out, log in).
  • Double the account state to maintain.
  • Email collision (probably needs distinct emails, which is awkward for one person).
  • Non-obvious what a “Staff” account does on its own Member side — does it earn XP? Accumulate purchases? (Answer: no; Staff accounts should be admin-only with no member-side data.)

Option B: One account, role-scoped views

Single account has both roles. UI explicitly switches between “Member Mode” and “Staff Mode.” Queries are scoped so that staff admin views never include the staff member’s own Member data, and Member views never surface admin-only info.

Pros:

  • Single identity. Same login, same email, same profile.
  • Matches how users already think about themselves.
  • Easier onboarding (“you have two views” vs. “you have two accounts”).

Cons:

  • Privacy enforcement now depends on every query in the codebase being correctly scoped. Any query that forgets to exclude-self-from-staff-context is a privacy leak.
  • Role-switching UI has to be discoverable but not disruptive. This is a hard UX problem.
  • Harder to audit (who did this action — Staff-Carrie or Member-Carrie? Both have the same identity.)

Recommendation

Option A (separate accounts) for the Staff/Member split, with the explicit design principle that a Staff account has no member-side data at all — it’s purely an admin login. The Member account is the “real” identity; the Staff account is a job function.

Reasons:

  • The privacy guarantee is structural (data simply doesn’t exist in the wrong context), not policy (every query must remember to filter).
  • It’s easier to implement correctly the first time.
  • Carrie’s concern is real and current; we shouldn’t bet on query-level discipline to protect her.

For GM role, it’s a flag on the Member account — GMs are Members who’ve been recognized as hosts. No separate account needed. The GM flag adds capabilities (event hosting, named presence) to their Member identity without creating a split.

So the real model is:

Staff account (admin-only, no member data)
 └─ possibly linked to a Member account for the same person

Member account (default)
 ├─ GM flag (optional)
 └─ Apprentice-of flag (optional, V2 — links to another Member as master)

Permission matrix

CapabilityStaffGMMember
View own XP, purchases, profile—YesYes
Check in at kiosk—YesYes
Earn XP from purchases/events—YesYes
View other members’ public info (username, level, class)YesYesYes
View other members’ private info (email, purchase history, etc.)YesNoNo
Host events (shown as host on event pages)YesYesNo
Be listed in “Staff on shift” presenceYesNoNo
Be listed in “GM on shift” presenceNoYesNo
Award discretionary XP bonus to membersYesNoNo
Modify another member’s XP, tier, or profileYesNoNo
Access admin dashboardYesNoNo
Take on apprentices (V2)—OptionalYes, if name-level

Blanks (—) indicate “role doesn’t have a member-side identity” for the Staff column — a pure Staff account has no personal XP or purchase flow.

How this interacts with other systems

Staff presence (Kunal/Carrie feature)

The “bad-surprise” framing — members come in expecting to chat with a specific staff person and they’re not there — requires knowing who’s on shift. That’s a Staff role property. GMs have a parallel presence (“GM on shift running Magic tonight”), surfaced the same way but scoped to the event they’re running, not a general shift.

Apprentices (name-level V2)

See name-level. At V2, name-level members can take on apprentices — lower-level members who mentor with them. The apprentice relationship is a Member↔Member link, not a new role. But the master in that relationship is a natural candidate for the GM flag later: a member who has apprentices and runs learning activities with them is already acting as a GM in the BECMI sense. The pipeline becomes:

Member → reaches name level → may take on apprentices → may be flagged as GM

This is why GM eligibility should NOT be the name-level reward (see name-level reward-framing discussion). GM emerges downstream of apprenticeship, not as an automatic unlock at level 9.

Discretionary XP bonuses

See rpg-loyalty-system-design “Discretionary XP Bonuses.” Only Staff can award these. GMs cannot — this is one of the deliberate levers that differentiates the tiers. GM recognition is surfaced through named presence and event-hosting visibility, not through the ability to modify member XP.

Account separation for Panat and Carrie

Both currently have conflated accounts. When we implement the split:

  1. Create distinct Staff accounts (admin-only, no member data).
  2. Existing accounts become Member accounts exclusively — all purchase/XP/check-in history stays on them.
  3. Grant the new Staff accounts admin access; revoke admin from the Member accounts.
  4. Test: does Carrie’s personal purchase history appear anywhere in the Staff view? If yes, the split is incomplete.

Open questions

  • Email handling: does a Staff account need a distinct email? (Probably yes — panat-staff@... or similar. Alternative: email alias rules.) Ties into the 2026-04-14 note about moving primary email to panat@dungeonbooks.com and spinning down scriptwizards.
  • Should GMs have a limited moderation toolkit? (Example: ability to hide a comment in an event thread.) Or is moderation strictly Staff-only?
  • How is GM status granted? Staff-assigned only? Or is there an application/self-nomination flow?
  • How is GM status revoked? Inactivity timeout? Explicit Staff action? Apprentice-master relationship ending?
  • Do GMs earn anything mechanically (XP bonuses, recognition items) from being GMs, or is the recognition itself the whole reward?
  • Should there be an “honorary” role for non-staff non-GM significant contributors (big patrons, advisors, former staff)? Or does the existing tier system cover this?
  • For multi-shop future: does a GM at Dungeon Books automatically have GM-adjacent recognition at partner shops, or is it per-shop?
  • How does this interact with the Discord role sync (discord-integration)? Does each tier map to a Discord role?

Not implementing yet

  • Sub-roles beyond Staff/GM/Member. Don’t pre-specialize. Two-role systems at 12 members is already over-designed; three is the practical ceiling for a while.
  • Cross-shop role portability. Matters for the cooperative-network vision but not before a second shop joins.
  • Self-nomination GM applications. Staff-assigned for now; revisit if it becomes a bottleneck.
  • Public role directory (“here are all our GMs”). Fine to build when there are more than a couple.

Graph View

Backlinks