Activity classification

TimerOS decides whether your current activity counts as productive or idle entirely on your own device — using a deterministic scored rule engine first, with a small on-device machine-learning model as a fallback. There is no large language model, no model download, and no cloud AI involved.

Every few seconds (about a 5-second cadence) the desktop app looks at a few signals about your foreground work, classifies them, and the timer attributes that time to one of the tracked activity states (the sixth, Offline, just means the timer is stopped).

The signals it reads

• The active window title — the title of the window you are focused on.
• The running app — the foreground application’s name.
• Time since last input — how long since the last keyboard or mouse activity, used for idle and break detection.

One more signal is conditional: the host of the active browser tab (for example example.com), plus the first section of its path where that section reads as a word (for example console). Never the full URL, the deeper path or the query string. The value is kept in memory for the current tab and is never stored or transmitted.

Either of two things opens that read: your workspace has set website rules — marking a site as productive or idle by its domain — or you have automatic task assignment on, which uses the site as a hint about which task you are on. Task assignment is on by default and is a per-worker setting: switch it off in Settings → Activity Detection and, with no website rules configured, the capture does not run at all. It also never runs while tracking is stopped, in Manual mode, while your workstation is locked, or during a break you have declared.

The host is obtained by asking the browser for the current tab's address through the OS accessibility interface — not by parsing the title bar — and reducing it to host plus first path section in memory before anything is classified. Browser-internal pages (chrome://, edge://) and file:// are rejected outright. It works with Chromium-based browsers on a best-effort basis; when the host cannot be read, classification simply falls back to the app and window title.

How the decision is made

A scored rule engine runs first, summing weighted signals (app, title, project, role) into a productive-versus-idle decision. If the rules are not confident, a small on-device logistic-regression model decides instead. An employer rule overlay can override both. The output is a binary productive-or-idle result; break, overtime, and off-work labels are applied afterward by the timer.

Three tracking modes

• Automatic — rules plus the on-device ML model.
• Rule-based — the deterministic rules only, with ML switched off (this is the AI opt-out).
• Manual — no app classification at all; you set productive or break yourself.

On the desktop, choosing the mode is reserved for managers (executive level and above). In all three modes, idle and break detection and the shift-aware overtime handling still run.

Transparency for workers

Every worker — regardless of role — can open Settings → Activity Detection to see a live “Current Activity” card showing the category, source, and reason for the current window (in Automatic and Rule-based modes; in Manual mode a short hint appears instead, since apps aren’t being classified), and a “How your activity is classified” dialog listing the full baseline and employer rule set, read-only. In Automatic mode you can also mark the current activity as productive or idle; the on-device model retrains immediately and locally. Employers configure the rules; the monitoring notice explains the privacy stance in full, and our blog post on time tracking without surveillance covers the why.