aw-notify: smart anomaly-detection notifications (percentile/sigma above baseline)

[TimeToBuildBob]

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

[ErikBjare]

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]

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]

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:

• Anomaly detection ("you're in an unusual state") is retrospective — needs 30 days of baseline before it's useful, and frames everything as a deviation.
• Coaching/forward-looking ("you're on pace for your best focus day this week") can activate sooner as a session builds and can be positive rather than corrective.

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]

See these links:

• https://dl.acm.org/doi/10.1145/2858036.2858428
• https://forum.activitywatch.net/t/achievements-progress-bars-streaks-and/1630
• https://activitywatch.net/blog/future-of-time-tracking/

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]

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:

• Works with minimal history (first occurrences are still valid achievements)
• Framing is additive and positive rather than corrective
• "Trophy for best focus day this month" is more shareable/engaging than "you're 2σ above baseline"

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]

@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]

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.