How live alerts work
Arm any verified result as a standing definition: the same frozen features and edge rules run on live data, and every fire carries its observed values and a replay link.
The alert is the definition
Most alerting works backwards: you write a rule, it fires, and only then do you learn what the rule actually meant. Here you never write an alert. You run a definition against the record first, read its verified occurrences, and then arm THAT: the same versioned features, the same grammar, the same edge rules, now standing against live data.
There is no translation step where meaning can leak. What fires tonight is computed by the same frozen code that counted the history you already inspected. If the definition matched forty occurrences in the record, a fire is occurrence forty-one, on the same terms.
When it fires
Live evaluation runs on the same one-minute grid as the scan. A definition fires when its whole condition becomes true after being false: a state that stays true for an hour fires once when it begins, not sixty times while it persists. Sequences fire when their final step completes in order, inside the bound you set.
Candle features read the last completed 15-minute or hourly candle, never the one still forming, exactly as they do in the scan. An alert cannot see anything a historical query could not.
What a fire carries
Each fire records the market, the minute, and the observed value of every feature at that bucket: the setup, kept as evidence. Features that were not yet warm at that minute are recorded as absent, not zero, the same absence honesty the scan applies to its denominators. And every fire deep-links into tick-by-tick replay at its moment, pre-rolled so you watch the condition form.
Where fires land
Standing definitions live in the Alerts tab on the research page: enable, disable, or remove them there, and read recent fires with their replay links. A bell in the app header carries the count of fires you have not seen yet. Definitions are capped per account.
The public API and MCP server are research retrieval surfaces, not account automation surfaces. MCP v1 is read-only and cannot arm, disable or remove an alert. Use the browser to inspect the verified result and make that decision.
What alerts refuse
The refusals do not soften because the data is live. A fire says one thing: the condition you verified occurred again, on the record, at this minute. It is not a prediction, and this is not a signal service: nothing here tells you to enter, exit, or expect anything. Outcome-conditioned alerts (“fire only if price then drops”) are impossible in the grammar, the same OUTCOME_IN_PREDICATE refusal the scan enforces: an alert that waits for the future to confirm it is not an alert, it is hindsight.
FAQ
Do alerts predict anything? No. A fire is a measurement of the present against a definition you verified on the past. Nothing estimates what happens next.
What happens right after I arm a definition? It begins evaluating live data from that point. Features that read a window of history (a 15-minute tape share, an hourly candle) become eligible once that history has accumulated live; until then they are absent and cannot fire. Absence is reported, never improvised.
Can I arm a definition I never ran? No. Arming lives on a live result: you verify first, then the verified document itself becomes the standing definition, unchanged.
Can my AI agent arm alerts over MCP? No. The agent can read the registry, run scans and cohorts, inspect snapshots and retrieve reports, but it cannot mutate your account. The client-surface guide explains that boundary.
Occurrences describe only the recorded markets, dates and eligible buckets reported by the scan. They are observed examples, not a guarantee. Nothing here is trading advice.