Repository navigation
aw-notify: smart anomaly-detection notifications (percentile/sigma above baseline) #200
Description
Background
Opened from discussion on #199 (aw-notify Android implementation).
Currently aw-notify on both desktop and Android uses fixed user-defined thresholds (e.g. "alert at 60/120/240 min of Work"). Erik's suggestion: replace or supplement these with statistical anomaly detection — no user config needed.
The Idea
Instead of asking users to set thresholds, detect statistically unusual sessions automatically:
- >90th percentile of daily time for a category (based on rolling 30-day history)
- ~2 sigma above mean for a category
- Examples: "Today's Twitter use is already at your 95th percentile (1h 45m vs your usual 35m)" or "Exceptional focus day — Work time in top 10%"
This makes defaults useful out-of-the-box with zero configuration, avoids threshold fatigue (fixed thresholds get ignored fast once familiar), and provides positive reinforcement not just warnings.
Scope
- Applies to both
aw-notify(desktop) and the Android notification worker (feat(notify): add aw-notify support — activity-time threshold alerts #199) - Requires historical data access (aw-server query API already supports arbitrary time ranges)
- Percentile computation is straightforward; the harder part is choosing the right lookback window and minimum data requirements before anomalies can be computed
Non-Goals
- This is not a replacement for per-user threshold config (that can coexist)
- Not blocking feat(notify): add aw-notify support — activity-time threshold alerts #199 — the v1 fixed-threshold approach is still useful while historical data accumulates
Related
- feat(notify): add aw-notify support — activity-time threshold alerts #199 — Android aw-notify implementation (prompted this issue)
- aw-notify desktop
Activity
ErikBjare commentedon Jul 24, 2026
I'm not married to the "percentile/sigma" anomaly detection idea, I mostly just acknowledge that we need a better/smarter/alternative solution than configured threshold values.
ErikBjare commentedon Jul 24, 2026
A similar idea is some kind of "coaching" or reward/nag to improve behaviors, but that's the wider scope/goal of the notification system which could use some input from behavioral science research.
TimeToBuildBob commentedon Jul 24, 2026
Good framing — the percentile/sigma title was too prescriptive. The actual goal is: smart detection that works with zero user configuration.
The coaching/reward angle you mention is interesting and arguably cleaner than anomaly detection:
Both share the same data requirement (historical per-category time from aw-server), so the infrastructure for #199 covers either direction. The behavioral science angle is worth a look — there's decent literature on intermittent reinforcement vs. threshold-based nudges, and the short answer is that variable-ratio reinforcement (like "you hit a personal record!") tends to be more engaging than fixed threshold alerts.
Happy to keep this as a tracking issue for the broader "smarter-than-thresholds" direction rather than a specific implementation proposal. If you want to rename the title to something like "aw-notify: smart/adaptive notification triggers" that might better reflect the scope.
ErikBjare commentedon Jul 25, 2026
See these links:
I really like the achievements idea (can be behaviorally tied/configured, includes "trophies" that can be collected multiple times - say for a particular timeperiod), would leverage notifications nicely. Worth opening a separate issue for.
TimeToBuildBob commentedon Jul 25, 2026
Those are great references. The ACM CHI paper on self-quantification + gamification has solid UX evidence, and the forum thread shows existing community appetite. The blog post's "meaningful milestones" framing fits perfectly.
The achievements angle is arguably stronger than anomaly detection as a first step:
Happy to open the tracking issue for achievements/streaks/trophies if you want to split it out from the broader smart-notifications thread here.
ErikBjare commentedon Jul 25, 2026
@TimeToBuildBob yes, do it. Worth thinking about how the achievements get stored once conditions met (references to which sources were used, time-ranges included, source devices/buckets, etc), how the multi-device situation works (should each device have its own achievement store and overlay or sync achievements? Sync them as "settings"? Is settings-sync even supported yet? Should we just create a "achievements" bucket or is that a bad fit?). Many unanswered design questions, let's continue discussing in the new issue.
TimeToBuildBob commentedon Jul 25, 2026
Opened the tracking issue: #205
Carried over the design questions on storage (source/time-range/device refs per achievement) and multi-device sync (per-device overlay vs. settings-sync vs. dedicated bucket) into the new issue body so we don't lose them. Let's continue there.