Events by themselves are not yet an answer to “what do we do with them”. Rules are that answer: “mark events on this topic like this”, “everything below the threshold — do not show”, “about our supplier — straight into the digest”. You do not configure them by hand either: you describe what you want in words, and the agent assembles the condition tree.
What a rule is
A rule is a short description of “which events interest me and what to do with them”. For example:
“Everything about competitor price changes — tag with ‘prices’ and include in the daily digest.”
One rule — one such intent. There can be many rules, and together they form the processing order.
Order and scope
Every rule describes its own scope — which events it looks at at all. The scope is set by monitors, sources, tags, or “everything at once”. Scope matters so that rules do not interfere with one another.
Rules are checked in order — from first to last. The order is fixed and visible: when a “tag it” rule has fired, already-tagged events continue down the chain. Usually the check stops after the first matching rule, so that events are not processed twice.
Conditions
A condition is what gets checked about an event. No programming needed: the condition vocabulary is limited and understandable in words.
- Materiality rating — “more important than five points”.
- Topic — “regulation”, “prices”, “our products”.
- Entity — a specific company, person or product.
- Words — the text must contain or not contain certain words; patterns are supported for complex cases.
- The type and size of the change — got more expensive or cheaper, by how many percent or dollars.
- Confirmation by sources — “at least two independent sites reported it”.
- Story state — new, developing, fading.
Conditions combine into a tree: “both this and that”, “either this or that”, “everything except this one”. The tree can nest, but not endlessly — the depth is limited so a rule stays understandable to a human.
Facts computed by code
Sometimes the needed condition cannot be expressed with the ready fields: say, “churn risk above 0.3”. Then your own Python code computes the fact, and the rule uses it like an ordinary condition. Your own facts do not replace the built-in ones — their names are their own.
When the code breaks, the condition simply does not hold: better a missed trigger than a false alarm out of nothing. Details — in the Custom Scripts section.
What a rule does
- Tags — a label on the material; filtering then works on it.
- Hides — the event stays in the data but does not get into your feed.
- Routes into a digest — the event lands in a scheduled digest instead of a separate message.
- Includes in publishing — a publication draft is prepared for such an event.
- Sends a webhook — the data goes to your system at the address of a configured channel.
- Runs your code — a script action: for example, send the data into an internal system by your own rules. What the code returned is visible in the decision journal.
The decision journal
For every event you can see which rule did what to it — and, more importantly, why the one you expected did not fire. This answers the most frequent question of news watching: “I thought I had configured that”. In the journal, the decision is described in words, not in codes: both the matched condition and the stopping reason are visible.
Testing before enabling
A new rule can first be tested on the past: the agent runs it over the already collected events and shows what it would have done — how many events would match and what would happen to them. Nothing is sent and nothing is changed. That is how you see, before the rule starts working for real, whether it came out “too broad”.
Rules and publishing
A rule can start publication preparation: then a draft is assembled right away for a matching event and waits for your approval. The second way is publishing by schedule, without rules, “every morning at nine”. Both are described on the Publishing page.
Next → Alerts & Noise Protection