ADR-051: Slow sync_score decay ~5× for early-stage play cadence

Status: Accepted Date: 2026-05-11 Context: The decay system shipped in Feb 2026 (migration 007) was calibrated for a steady-state world where engaged users play frequently. In practice the game has very few active players, and the realistic cadence is 1–2 games per week. Under the original defaults (base_rate=0.5, grace=7d, acceleration_scale=14d), a mid-score (~50) casual player loses ~6 pts/month and a 95% player loses <1 pt/month — small in absolute terms, but the signal it sends ("you're decaying") is the wrong one for a product that's still trying to attract play. Sync_score is also meant to reflect decision-making style, which is a stable trait, not a perishable skill.

Decision

Update sync_decay_config defaults via migration 093:

Param	Old	New	Effect
base_rate	0.5	0.1	5× slower decay overall
grace_period_days	7	30	No decay in the first month of inactivity
acceleration_scale_days	14	60	Decay ramps to full rate over 2 months past grace, not 2 weeks

vulnerability_floor (0.1), score_floor (10), and games_scale (20) remain unchanged — they were already doing useful work (protecting high scores, anchoring durability).

Rationale

• Style is durable. Sync_score is a trait estimate, not a skill rating. A player's reasoning style doesn't drift on a weekly clock, so the original 7-day grace was modeling the wrong thing.
• Don't punish the cadence we actually have. 1–2 games/week is the realistic pattern. The new 30-day grace covers that with margin.
• Linear lever. base_rate scales the whole formula, so a 5× reduction is one number to reason about. Grace + acceleration shape the onset of decay, which is where the perceived-fairness problem lived.
• Live-tunable. Values are stored in sync_decay_config, so this is a UPDATE not a code change — easy to retune as play frequency increases.

Alternatives Considered

• Drop base_rate only (0.5 → 0.1). Simpler, but a player who's been gone 8 days would still feel the system reach for their score — bad UX signal for the current player base.
• Disable decay entirely. Tempting at zero scale, but leaves ADR-050 (agent permission tiers gated by sync_score) without a freshness signal. Want decay present but patient.
• More aggressive slowdown (10×+). Would functionally turn decay off for any realistic timeline. Better to keep the gradient and revisit once play cadence increases.

Discussion

User raised this in the context of "nobody's really playing the game" and "people change slowly." The original decay was sized for an active product trying to keep high-trust scores honest; the current product is trying to get play. The shape of the curve (vulnerability floor protects high scores, durability rewards engagement, score floor of 10) is still right — only the time constants needed loosening.

Tradeoff surfaced: under ADR-050, sync_score gates agent permission tiers. A slower decay means a dormant 95% score keeps governance permissions longer than before. Decided this is acceptable because (a) at this scale there are no live delegation flows depending on freshness, and (b) the parameter is live-tunable, so when delegation lands we can tighten without a code deploy.

Not changed: vulnerability_floor=0.1 already kept high scores nearly immune (a 95 loses ~0.026 pts/day at full acceleration); slowing things further at the top of the curve would be invisible.

Consequences

• A mid-score (~50, 50 games) idle player now loses ~1.2 pts/month at full acceleration vs. ~6 pts/month. A 95% player loses well under a point per quarter.
• "Pending decay" warnings on the hub will appear ~4× less often and only after a full month of absence.
• When delegation/permission flows go live (ADR-050), revisit whether 30-day grace is too generous for trust-gating. Easy to tighten via UPDATE sync_decay_config.
• Watch: if play cadence picks up to daily, the 60-day acceleration scale will feel too slow at the end of the curve. Re-tune then.

Deferred deploy — trigger to ship

As of 2026-05-11, migration 007 (the decay system itself) has never been applied to the remote Sync project, so neither the original defaults nor these slower ones are running in production. Decision: keep it deferred at current play volumes (no governance-tier dormancy to defend against; turning on score-shrinkage while trying to attract play sends the wrong signal).

Apply 007 + 093 together (and enable pg_cron + schedule the daily job per migration 007's deployment notes) when any of these conditions hits:

• ADR-050 agent permission tiers ship — sync_score gating real delegation needs a freshness signal.
• Active-player base grows enough that high-tier scores from dormant users start to skew leaderboards, team context, or any "ask a 90+ player" surfaces.
• We need decay data (the sync_decay_log table) to answer a product question about churn or staleness.

Until one of those, this ADR is the record of what we'll deploy, not a description of running behavior.

Key files: - migrations/093_decay_slowdown.sql — the config update - migrations/007_sync_score_decay.sql — original decay system + formula - src/lib/decay/decay-service.ts — TS service reading the same config table - docs/decisions/050-agent-permission-tiers.md — downstream consumer of sync_score freshness