Skip to main content

Core Events & Supersession

Phase 2 + 2.5 update (May 2026): core events now also feed the Activity Score engine via their event_families.family_id (mig 057), and brands on the universal reward formula (partners.use_universal_formula = true) compute the per-claim base as legacyReward × (1 + level/EVENT_DIVISOR) × (1 + min(AS/500, 0.5)) × localMultiplier. The supersession architecture below is unchanged — the ladder still selects the rule, the formula just folds tune-scaling and AS-velocity into the base. See Brand Programs README for the formula spec and per-brand opt-in flow.

Resonance Official has four core events — quality, gm_checkin, reaction_threshold, and social_link — that members can earn from at every Tune-In level. Each one exists not as a single rule but as a supersession ladder: ten rows of the same event_type in monitoring_rules, distinguished by min_tune_level, with growing rewards and caps as the tier rises. The event-handler picks the highest-tier row the member qualifies for at the moment they trigger the event.

This page explains why supersession exists, how it's implemented, and what changes per tier.

Why supersession (and not ten separate event types)​

The naive way to scale rewards with progression is to create one event type per tier — quality_l0, quality_l10, quality_l20, and so on. That's event-type sprawl: your monitoring rules, analytics dashboards, /cooldowns UI, and migration scripts all have to know about ten variants of the same thing. Members see ten different events on their cooldown list when conceptually they are claiming the same activity at different rates.

Supersession collapses this. There is one logical event type — quality — and the ladder of payouts is data, not schema. From the member's point of view they earn from "quality" at "tier 4". From the integrator's point of view they query monitoring_rules for event_type = 'quality' and let the lookup function pick the right row. From the analytics point of view, claims roll up under one event_type for cohort comparison across tune levels.

The 10-tier ladder​

Each of the four core events has tiers at Tune-In levels 0, 10, 20, 30, 40, 50, 60, 70, 80, and 90 — ten tiers spaced ten levels apart, covering the L0 → L90 range of the standard Tune-In progression. Every tier shares the same event_type, detection_config, and (mostly) the same cooldown_period; what changes per tier is reward_amount and max_claims_per_user.

The four core events are:

  • quality — substantive messages that pass the quality gate. The largest event in the program by volume.
  • gm_checkin — daily ritual check-ins. Gentler curve since it's once a day.
  • reaction_threshold (Popular Content) — your message receives at least N distinct credible reactors within the spread window.
  • social_link (formerly social_share) — sharing a link to Resonance Network content or a partner site, with anti-spam guardrails.

The exact reward and cap values for each tier appear in the Reference — Resonance Official Program page. The shape, in summary:

EventL0 → L90 reward growthL0 capL90 cap
quality15 → 75 RSNC50/wk120/wk
gm_checkin10 → 40 RSNC1/day3/day
reaction_threshold15 → 60 RSNC3/day12/day
social_link30 → 100 RSNC10/wk20/wk

Caps are bigger as tier rises, but never huge. The L90 weekly ceiling on quality is 120 claims — about 17 a day, sustainable but tight. This is deliberate: the rebalance moved from "vanity caps no one hits" to "binding caps that require actual sustained, quality engagement."

How the event-handler picks the right tier​

When an event fires, the event-handler in workers/src/event-handler/index.js calls a Postgres function that does the supersession lookup in a single query:

SELECT * FROM monitoring_rules
WHERE brand_id = $1
  AND event_type = $2
  AND active = true
  AND (server_id = $3 OR server_id IS NULL)
  AND min_tune_level <= $4
ORDER BY min_tune_level DESC, server_id NULLS LAST
LIMIT 1;

The four parameters are brand_id, event_type, server_id, and user_tune_level. The ORDER BY min_tune_level DESC clause is the supersession: among all rows the member qualifies for, take the one with the highest min_tune_level. The secondary sort prefers server-specific overrides over brand-wide defaults.

This is wrapped in the helper RPC get_effective_rules_for_user(brand, server, level), which returns one row per event_type for use cases (like /cooldowns) that need the full set of currently-effective rules at once.

What changes per tier​

Three columns commonly differ between tiers; one usually doesn't.

  • reward_amount — climbs significantly. The quality event goes 15 → 75 RSNC across the ten tiers, a 5× increase.
  • max_claims_per_user — climbs modestly. Caps roughly double between L0 and L90 across all four events. The point isn't to remove the cap; it's to acknowledge that L90 members are demonstrably sustaining higher engagement and to give them room.
  • cooldown_period — usually constant within a ladder. The quality ladder holds at 300s (5 min) at every tier. The cooldown is about anti-spam, not progression.
  • detection_config — should be identical across tiers of the same event. Strictness, reactor thresholds, anchor requirements: these are properties of the event, not of the member's tune level. Changing them per tier breaks the supersession invariant that members are doing the same activity at different rates.

If you find yourself wanting to vary detection per tier — "gm_checkin should require a longer message at L70" — that's a sign the activity is conceptually different. Make it a separate unlock event, not a supersession tier.

Last updated on