Contact
Sequence

Notifications & alerts

The notification centre, subscriptions, the seven ready-made schedule alerts and their thresholds, and the three rules about quiet hours and rate caps that are easy to get backwards.

The centre#

Notifications are collected in a centre with an unread count. Every notification says why, not merely that something changed — that is a requirement on the shape, not a nicety, and it is not optional.

Subscriptions#

You subscribe to a target — a row, a sheet, a filter — and choose a cadence:

Cadence
Immediate
DailyA digest
WeeklyA digest
Off

Kinds: mention, comment, reply, resolved, and alert.

Three rules that are easy to get backwards#

1. Nobody is notified about their own action. Obvious, and the single most common defect in this feature wherever it exists — because the author is always a subscriber to the thing they just touched.

2. A mention bypasses subscriptions, not the rate cap. A mention notifies regardless of subscription settings, and that is honoured exactly. It is not extended to the per-hour cap: a tool that floods people gets filtered to a folder and then the alerts stop working, and mentions are the highest-volume event there is. An uncapped exemption would be precisely the flood the cap exists to stop.

3. Quiet hours and the cap defer; they never drop. ⚠⚠ Excess arrives as one digest — arrives, not vanishes. A notification silently discarded is data loss wearing a preference's clothes, and it is unfalsifiable from the outside: nobody can notice the thing they were never told. Every suppressed notification is still recorded, still in the centre, and carries why it was held — cap, quiet hours or cadence.

The seven schedule alerts#

Ready-made rules a project switches on, evaluated against the schedule:

RuleFires when
Baseline slipA row's finish moves past its baseline
Went criticalA row that was not critical now is
Due, no startDue to start within N days with no actual start
OverduePast its finish date and not marked complete
Float belowTotal float on any row dropped below N days
Pushed by predecessorThe driving predecessor is behind its baseline and moved this row
Stale in progressUnchanged for N days while showing in progress

Default thresholds: 9 days for due-no-start, 5 days for float-below, 14 days for stale-in-progress.

⚠ These thresholds are defaults with no per-project authoring surface yet. They are defaults rather than constants precisely so that the surface, when it lands, has something to set.

⚠ Pushed-by-predecessor names the driving predecessor only. A non-driving predecessor being late did not push anything, and saying it did would invent a chain the engine never computed.

⚠ Summaries are excluded, as they are from the scheduling passes — a summary's float and criticality roll up from its children, so alerting on both alerts twice for one fact.

State versus transition#

Some of these are transitions ("a row went critical") and some are states ("is past its finish and not complete"). A rule that fired on state alone would re-alert on every recalculation — the flood the cap exists to survive rather than a thing to cause. So the rules answer the state question, and the transition is derived by comparing two evaluations. That keeps every rule pure and leaves "what changed" in one place instead of seven.

Two clauses that are half-built#

⚠ Escalation. The overdue rule is specified as "notify, escalating after N days". Only the notify half exists. It is deliberately not built because the specification does not say what escalating does — a second notification, a louder one, or one addressed further up. The day count is named in the alert, so severity is visible; what is absent is any change in behaviour over time.

⚠ Email. Delivery outside the application is a server obligation, and no server ships with the beta.