working in it

Automation and alerts

Automation is the model-backed half of the control plane: observers that watch a run and report on it. It produces exactly two things, an attention item or a run note, and it can never do anything else.

#

What an observer can and cannot do

It can read a run and write a finding. It can never type, approve, spawn, execute a script, or change a Project. That is structural: there is no code path from an observer to an action, so there is no setting that would grant one and no misconfiguration that could produce one.

#

Two outputs, and where each one lives

  • A run noteSomething worth recording that is not worth interrupting you for. It has exactly one home: the Activity tab's Findings.
  • An attention itemSomething that may need you. It appears in the Alerts drawer tab and in the Automation dashboard's Activity tab - the same component over the same data rather than a second copy of it.
#

The interrupt budget

This is the part that makes an alert inbox usable rather than another thing to ignore. Items are ranked, and there is a hard daily interrupt budget, four a day by default. Four channels split by how expensive the item is to resolve.

  • Incidents merge rather than repeat. The same problem recurring is one item with a count, not fifteen.
  • Demotion rules are mined and expire. What you dismiss teaches it what not to raise, and those rules time out rather than accumulating into a filter nobody remembers writing.
  • The suppressed count is always shown. You are told how many items did not make the budget, with their reason, so the ranking is auditable rather than a black box.
#

The Automation dashboard

TabWhat it holds
PolicyThe one editor that can turn an automation off in either scope: the install-wide ceiling and every per-Project opt-in, as one matrix. Limits and budgets live behind a disclosure here.
UsageWhat automation has spent, by automation and by Project. The same component the Usage view draws, over the same numbers.
ActivityThe attention inbox and the run notes, at fleet scope.

Settings, Automation shows status and links here rather than holding a second set of switches. Two controls writing one key is how a setting ends up with two answers.

#

Budgets

Every automation carries a cap, and a cap is tokens, dollars, or both. The reason it is both is a real limitation rather than a preference: a dollar cap cannot bind against a provider that reports no cost. Absent cost is recorded as unmeasured rather than as zero, every total drawn over it reads as a floor, and the token axis is the honest backstop.

Rate limits and per-call ceilings are deliberately not budgets. They count acts and bound one request; a budget bounds a period's spend. Conflating them makes one of the two silently unenforced.

#

Alerts and push

Web push to a phone, with per-device preferences, plus sounds on the desktop. Which device you are actually at is decided once, for the whole application, from a presence heartbeat, rather than each feature guessing separately and disagreeing.

Push goes through your browser vendor's push service, which is how web push works everywhere, and only after you subscribe a device. Nothing is sent to a service this project operates, because there is not one.

#

The deterministic detectors need none of this

Loops and stalls, declared-but-not-verified claims, documentation debt, and provenance gaps all run with no model at all. They cost nothing per session and cannot hallucinate a finding, and they are worth having on well before any observer is. The control plane covers the layering.