Rules Overview

Explains how to define and manage the detection conditions for events received through Sources, and the policies that control automatic incident creation and initial response.

Overview

Lorel.ai’s Rules feature is made up of two mechanisms: Trigger Rules and Incident Policies.

1. Sources — receives the event.
2. Trigger Rules — judge the received event and create a detection event.
   • Detection Rule (matches a single event)
   • Compound Rule (matches occurrence frequency / a threshold across detections)
   • Metric Rule (matches a collected metric against a threshold)
3. Incident Policy — automatically generates an incident from the detection event, deciding:
   • The initial severity (Critical–Low)
   • The automatically assigned assignee
   • How incidents are split (grouping condition)
   • The initial response to auto-trigger (AI Agents or Runbooks)
4. Incident automatically filed / response begins

Role of Trigger Rules

Judges events and metrics brought in through Sources and creates detection events. There are three kinds: a Detection Rule, which evaluates a single event; a Compound Rule, which judges based on an accumulation of multiple detection results; and a Metric Rule, which judges a collected metric’s value against a threshold.

• Detection Rule: Judges an event received from a single Source.
• Compound Rule: Accumulates and judges the firing history of a Detection Rule or Metric Rule. Well suited to designs that should only respond when detections exceed a certain frequency within a window (frequency-based anomaly detection). Currently only one rule can be specified as the input source.
• Metric Rule: Compares a collected metric’s value with a threshold. On screen, you create it by choosing “Detection Rule” when creating a rule and then choosing a metric-based data source. In the rule list, open the [Trigger Rules] tab and choose “Detection Rules” under “Rule type”; it appears there with the data type “Metric”.

Role of Incident Policies

A rule set that automatically generates an incident when a Trigger Rule (Detection, Compound, or Metric) fires. It links one or more Trigger Rules and defines the initial severity, initial assignee, and the AI Agent or Runbook for the incidents it generates.

What you can do

Rules-related features you can define and manage within a project, and the role each requires.

Creating, editing, deleting, or enabling/disabling a Trigger Rule or Incident Policy requires the Editor role or higher.

Trigger Rules

1. Configuration items for a Trigger Rule

The configuration items that make up a Trigger Rule, and their specification.

Basic info

• Data source (required): Choose one of the active data sources registered in Sources, listed by display name and grouped under “Event” and “Metric”. Choosing one expands the detailed settings on screen (rule name, source, detection logic, and so on).
• Rule name (required): A display name identifying the Trigger Rule (up to 100 characters on screen; rules with the same name can be registered).
• Source (required): Within the chosen data source, choose the specific receiving endpoint to monitor (for example, an SNS topic ARN, a GitHub repository, or a Sentry organization). A Trigger Rule links to exactly one source. This item doesn’t appear when you choose a metric data source.

Detection logic

The section that defines the conditions used to evaluate and extract from received events.

• Match Conditions (AND, required): The required conditions for detection. Each is made up of a field, an operator, and a value; if more than one is registered, all must be satisfied (AND). At least one is required.
• Exclude Conditions (OR, optional): Filter conditions that exclude an event from detection. A received event matching any one of the configured exclude conditions is excluded (OR). Zero is a valid configuration.

Target Distinction

The section defining the aggregation unit used when routing detected events to incident filing or aggregation.

• Identifier label: Specify an identifier label (such as a host name or instance name) used to split incidents and detection data. You can specify up to 8 labels; when you specify more than one, splitting happens per combination of their values (a composite key).
  • If not specified: no splitting occurs, and everything is aggregated as a single event. In this case, you can’t choose “Split by identifier label” on the downstream Incident Policy.
  • If specified: each value of the chosen identifier label (or, with more than one, each combination of their values) is evaluated independently and processed for incident filing, in parallel.

Data retention period

Specifies how many days (at least 1) the system retains detection event data generated by a matching rule. If omitted, your plan’s default applies automatically (some plans may not allow changing it). See the Plans and Pricing page for the specific retention days (plan limits and defaults).

2. Behavior specification per rule type

Detection Rule (single-event detection)

Judges an event received from one data source against the specified field conditions.

• Relationship to the data source, and event source: A Detection Rule belongs to exactly one data source (1 rule = 1 data source). A Detection Rule can receive events via several delivery methods, including an HTTP webhook.
• How conditions are specified, and operator specification: Each condition is made up of a field, an operator, and a value.
  • Field: specify the event’s attribute using a dot-notation path (a leading $. may be omitted).
  • equals (eq): matches when the value is an exact match.
  • contains (contains): matches when the value contains the specified string. Case-sensitive.
  • regex (regex): matches when part of the value matches the regular expression (partial match). Standard regex syntax is supported, but some special constructs — lookahead/lookbehind assertions and backreferences — are not.
• Evaluation rule and order: At least one match condition is required; exclude conditions are optional (zero is valid). Evaluation order: an event is detected only if it satisfies every match condition (AND) and matches none of the exclude conditions (OR).
• Viewing detection results and observed values: A detection event’s detail screen shows the actual value for each match condition at the time of detection. Long values may be truncated.

Compound Rule (frequency / threshold judgment)

A rule that aggregates a chosen Detection Rule’s firing frequency over a period of time, and fires only when the condition is met.

• How the source type affects counting: A Detection Rule (event type) counts the number of received events, while a Metric Rule (metric type) counts the number of per-minute evaluations. The same “N or more” configuration counts different things depending on the source type. When the source is a Metric Rule, because metrics are only evaluated once per minute, the Threshold Count can’t be set higher than the number of minutes in the Time Window.
• How the aggregation period is calculated (sliding window): Each time an event is received, the occurrence count is recalculated by looking back over the configured aggregation period from that moment. Once fired, the aggregation period and count are not reset to zero. Firing is evaluated immediately, every time an event occurs.
• Alert firing and re-notification (level-trigger): While the count remains at or above the threshold, the same anomaly doesn’t re-fire or send a duplicate notification (only the first notification is sent). Only after the count drops back below the threshold and then reaches it again does a new detection event fire. Because the return to a normal state is judged on a periodic evaluation, there can be a short lag between the count dropping and the status clearing.
• Independence of the fired/cleared status from the rule’s own status: Whether a Compound Rule is firing (ON) or cleared (OFF) is independent information, separate from the rule’s own management status (Enabled / Disabled / Error).

Detection event retention period

• When creating or updating a Detection Rule, you can individually specify the retention period (in days) for detection event data, at least 1 day.
• If omitted, your contract plan’s default number of days applies. The default and any upper limit vary by plan, and some plans may not allow changing it.
• Changing the retention period requires the Editor role or higher.
• If you shorten the retention period, existing detection events older than the new period become subject to automatic deletion; this can’t be undone.
• A Compound Rule has no retention period setting of its own. When its source is a Detection Rule, the retention period configured on that Detection Rule applies as-is. When its source is a Metric Rule, the Metric Rule’s own retention setting applies instead.

Where a Metric Rule is created: A “Metric Rule,” which directly monitors a numeric metric’s value against a threshold, is created on this Rules screen by choosing a metric-based data source when creating a rule. An already-created Metric Rule can be selected as a Compound Rule’s source (see “Configuration items for a Trigger Rule” above).

3. Trigger Rule status and permissions

• Rule status
  • Detection Rule: two states, Enabled or Disabled.
  • Compound Rule: three states, Enabled, Disabled, or Error.
• Initial state on creation: A newly created rule starts Disabled, for safety. Detection begins only once you explicitly enable it.
• Error transition when a source is deleted: If you delete a Detection Rule or a Metric Rule, any Compound Rule that uses it as a source automatically transitions to Error (the Compound Rule itself is not automatically deleted). A Compound Rule also goes to Error if its source rule changes the identifier labels it distinguishes targets by, and it doesn’t recover until its judgment split is selected again. To recover from Error, fix the source reference, which returns it to Disabled so it can be enabled again.
• Required role
  • View, list, preview: requires the project Viewer role or higher.
  • Create, edit, delete, enable/disable: requires the project Editor role or higher, and no write restriction from unpaid billing.

Incident Policies

Defines and manages how, based on events detected by Trigger Rules (Detection, Compound, or Metric Rules), incidents are automatically filed — including the conditions, initial severity/assignee, and automatic initial response (AI Agent / Runbook).

1. Configuration items for an Incident Policy

An Incident Policy is made up of basic info and the following four sections.

Policy creation and update specification

• On creation: Policy name and initial severity are required. You can create a policy without specifying any Trigger Rules (zero is valid at creation). A newly created policy is always Disabled (you can’t specify the enabled state at creation time).
• On update: You can’t reduce the linked Trigger Rules to zero via an update (zero is only allowed at creation).

Trigger Rule linking patterns

Detection Rules, Metric Rules, and Compound Rules can all be linked. A policy can link multiple Trigger Rules, and a single Trigger Rule can be linked to multiple policies. When creating a new Trigger Rule, choosing “Auto-generate an incident policy” creates a new Incident Policy tied to this rule and links it (the auto-generated policy is created in a disabled state, so enable it to start operating). To link the rule to an existing policy, use the Trigger Rules setting on the policy screen.

Reflected values at incident creation

The initial severity and initial assignee specified on the policy are applied as-is as the initial values when an incident is filed.

2. Important configuration/design rules and notes

Grouping (how incidents are split) specification and constraints

• Definition: A setting that chooses whether detected events are merged into one incident per trigger rule, or split and filed as an independent incident per resource unit (an identifier label such as a host or instance name).
• Only a shared label can be chosen: “Split by identifier label” can only use an identifier label that every rule specified as a firing condition (Trigger Rule) has in common. You can’t split by a label that isn’t shared.
• Watch for a surge after changing to split mode: After switching to (or configuring) “Split by identifier label,” each identifier label value is auto-filed as its own separate incident. That means notifications, and any automatic Runbook or AI Agent execution, run individually and in parallel for as many incidents as the split produces — watch carefully for a surge in notifications and resource consumption.
• Effect on ongoing (Open) incidents (non-retroactive rule): Changing this setting is not applied retroactively to incidents that are already in progress. An existing incident that had been merged into one is not automatically split into the new per-label structure — it stays as a single incident, still Open, on screen. Because such a leftover existing incident may not automatically switch to Resolved even after the underlying alert clears, an operator may need to manually change its status (resolve it).

Automatic membership validation for the initial assignee

• Validation at configuration time: When setting an initial assignee, the system confirms the specified user is a project member. A non-member can’t be configured.
• Re-validation at filing time: Every time an incident is generated, the system re-confirms the initial assignee is still a project member. If they have since left the project, the incident is filed as Unassigned for safety, and this is recorded in the activity log.

AI Agent assignment specification

You can configure up to 4 AI Agents to trigger automatically, matched to a state change (firing condition) in the incident’s lifecycle.

• The four firing conditions (triggers) for an AI Agent (currently, creation, resolution, and reopening can be selected on screen)
  • On creation: triggers asynchronously the moment an incident is newly generated (filed).
  • On resolution: triggers asynchronously the moment an incident’s status transitions to Resolved.
  • On reopening: triggers asynchronously the moment status moves from Resolved back to Open (reopened).
  • On escalation: triggers asynchronously the moment an incident is escalated (currently not selectable on screen).
• Constraints on agent assignment
  • Built-in agent constraint: A built-in agent (such as the incident root-cause analysis agent) has its trigger fixed to “on creation” only, and can’t be set for resolution, reopening, or escalation.
  • No duplicate assignment to the same firing condition: You can’t set more than one agent for the same firing condition at once. Since there are 4 selectable firing conditions, a policy can have at most 4 agents configured. This constraint applies per firing condition, so assigning the same custom agent to more than one different firing condition (for example, both incident creation and resolution) is allowed.

Default Runbook assignment specification and notes

• Runbook assignment: You can configure one Runbook, chosen from the Runbooks enabled in the project, to auto-run when an incident occurs.
• Mutual exclusivity with an AI Agent: If even one AI Agent is configured within the Incident Policy, you can’t also assign a Runbook (attempting to do so results in an error).
• Effect of deletion/disabling after assignment: If the assigned Runbook is later deleted or disabled, it will not run when an incident occurs.

3. Policy status, list, permissions, and delete behavior

• Enabling and disabling: A newly created policy is always Disabled, for safety. Only once enabled does incident generation begin in response to a linked Detection, Metric, or Compound Rule firing. While disabled, no incident is generated even if a detection event occurs.
• List filter/sort specification: The project’s policy list supports keyword search by name, and filtering by enabled/disabled state or initial severity. It supports sorting by name, updated date, or initial severity (severity sort order is Critical → High → Medium → Low).
• Required permissions and billing status: View/list requires the project Viewer role or higher. Create/edit/delete requires the project Editor role or higher, and no write restriction from unpaid billing (a payment delay). View/list is not subject to this billing-status restriction.
• Effect of deletion (safety and specification for historical data): Deleting a policy is a complete deletion and can’t be undone afterward. Deleting a policy doesn’t delete incidents that were previously auto-filed from it, nor does it automatically clear the link on those incidents — the incident side keeps the reference to the now-deleted policy, and both the list screen and the facet-aggregation screen continue to display and work correctly even when the linked policy no longer exists.

Limitations

• Compound Rule judgment pattern constraint: The only judgment method a Compound Rule supports is “frequency” — aggregating the number of occurrences within the period.
• No multi-level chaining of Compound Rules: You can’t build a multi-level structure where a Compound Rule’s judgment result is used as the source for another Compound Rule. Only a single Detection Rule or Metric Rule (single-event/metric detection) can be specified as a source.
• No limit on the number of Compound Rules: You can create as many Compound Rules as you need in a project, and any number of Compound Rules can reference a single Detection Rule as their source.
• No combined create-rule-and-policy screen for a Compound Rule: There is no dedicated screen option to configure an Incident Policy at the same time you create a new Compound Rule (only Detection Rules support that).
• Compound Rule error transition: If you delete the Detection Rule or Metric Rule specified as a source, any Compound Rule referencing it automatically transitions to Error and its monitoring/judgment pauses (the same happens if the source rule changes its identifier labels). The Compound Rule itself is not automatically deleted.
• No live aggregate values shown for a Compound Rule: A Compound Rule has no preview feature, and the actual real-time aggregate value (such as the current matching count) and observed values are not shown on screen either (only the configured values and status are shown).
• Operators available for a Detection Rule: Only three operators are available for a Detection Rule — equals (eq), contains (contains), and regex (regex). Numeric comparison, field-existence checks, and prefix/suffix matching are not provided.
• Mutual exclusivity of the initial response: Within the same Incident Policy, you can’t configure both automatic AI Agent triggering and automatic default-Runbook execution at the same time.
• Creating a custom agent: Creating or adding a new custom agent to link to an Incident Policy is not currently supported. To link one, you first need a custom agent already created in the project.

Related features

• Integration Overview (the Sources that detect events for Trigger Rules, and the Access that Runbooks and AI Agents use)
• AI Agents Overview (where an AI Agent is assigned)
• Runbooks Overview (where a default Runbook is assigned)
• Incidents / Tasks Overview (the source of the incident status transitions (“resolved,” “reopened”) that correspond to firing conditions, and how incidents remain intact after their policy is deleted)
• Plans and Pricing (access control based on payment status, and the plan-specific default/limit for detection event retention)