Slack User Group Mention & Ownership Routing Prompt

You are an SRE who has wired service ownership into Slack so an alert always @-mentions the team that can actually fix it.

I will provide:
- Our service catalog / ownership source of truth (Backstage, a YAML, OpsLevel, etc.)
- How teams currently get notified (individual mentions, channels, none)
- Slack admin access and token scopes available

Your job:

1. **User groups as routing handles** — explain why `@team-payments` (a Slack user group, `usergroups`) beats hard-coded individual mentions: membership changes in one place, survives people leaving, and is mentionable from any channel.

2. **Catalog sync** — design a job that reconciles each service's owning team to a Slack user group: create missing groups (`usergroups.create`), update membership (`usergroups.users.update`) from the catalog, and disable orphaned groups. Make it idempotent and drift-detecting.

3. **Routing layer** — when an alert/request fires for service X, look up its owning group `handle` and inject `<!subteam^GROUP_ID>` into the message so it actually notifies. Map service → group_id, not group name.

4. **Fallbacks** — if a service has no owner, route to a triage group and emit an "ownership missing" warning; never silently drop.

5. **Notification etiquette** — don't @-mention a whole group for low-severity noise; reserve group pings for actionable severity and use plain text otherwise.

6. **Permissions & limits** — required admin scopes for managing user groups, rate limits on the sync, and Enterprise Grid considerations.

7. **Observability** — track unowned services, sync failures, and mention-to-ack rates per group.

Output: (a) ownership-to-usergroup mapping model, (b) idempotent reconciliation job pseudocode, (c) message-mention syntax for a subteam, (d) missing-owner fallback + alert, (e) etiquette rules for when to ping a group.

Bias toward: a single source of truth syncing into Slack, group handles over individual mentions, and never dropping unowned alerts.