# Rule versions URL: /release-notes/rules Trace which version of a rule produced a finding and every change made to that rule in your deployment. This page explains how versions change and lists all 13 rules in the example dataset. A rule's version names the exact detection that produced a finding. Each finding keeps the rule ID, version and threshold that made it, so a threshold changed today never rewrites an earlier result. The **Rules** page states the principle in a note under its table: Their wording starts with Observed or Warning, and a report keeps rule output apart from what an engineer writes. Changing a threshold creates a new rule version, and results already produced keep the version that made them. ## How a version changes [#how-a-version-changes] A version reads major.minor after the rule ID, such as `telemetry_gap 1.3`. The **Rules** page shows it under each rule's name. | Change on **Rules** | Version | Audit log entry | | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **Edit**, then **Save** with a changed threshold, **Applies to** or **Override** | The next minor version | **Changed rule**, with the rule ID as object and the new version and threshold as detail | | **Edit**, then **Save** with nothing changed | Unchanged, and the toast reads **Nothing changed** | None | | **Enabled** switch turned off or on | Unchanged | **Disabled rule** or **Enabled rule**, with the rule ID and its current version | | **Report wording** | Cannot be edited: "Fixed per rule, so every report describes the same detection the same way." | None | The minor number counts up by one, so 1.2 becomes 1.3 and 0.9 becomes 0.10, not 1.0. The **Edit** dialog shows the version it will save, such as **Saves as telemetry\_gap 1.4**. Its **Threshold** hint names the version earlier results keep: **Results already produced keep version 1.3 and its threshold.** A switch change applies to the next import. `clock_uncertain` is locked: its switch and **Edit** are disabled, so its version does not change in the console. ## Where a finding shows its version [#where-a-finding-shows-its-version] | Where | What it shows | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | | **Events in view**, **Rule** column | The rule ID and version, such as `telemetry_gap 1.3` | | Evidence inspector | A chip with the rule ID and version, and a **Rule** block with **Rule**, **Detects**, **Threshold** and **Wording** | | Event page, **Highlights**, **Rule** | The rule ID, version and threshold, such as `telemetry_gap 1.3: More than 3 s without a HEARTBEAT` | In INC-0142 of the example dataset, the findings carry `memory_pressure` 1.1, `topic_stall` 1.0, `process_exit` 1.2, `telemetry_gap` 1.3 and `service_restart` 1.0. ## Versions in the example dataset [#versions-in-the-example-dataset] These are the versions and default states the example dataset lists. Your deployment's **Rules** page shows its own. | Rule | Name | Version | Default state | | ----------------------------------------------- | ----------------- | ------- | ----------------- | | [`process_exit`](/rules/process-exit) | Service exit | 1.2 | On | | [`service_restart`](/rules/service-restart) | Service restart | 1.0 | On | | [`memory_pressure`](/rules/memory-pressure) | Memory pressure | 1.1 | On | | [`telemetry_gap`](/rules/telemetry-gap) | Telemetry gap | 1.3 | On | | [`device_disconnect`](/rules/device-disconnect) | Device disconnect | 1.0 | On | | [`vibration_high`](/rules/vibration-high) | Vibration | 1.0 | On | | [`failsafe_entered`](/rules/failsafe-entered) | Failsafe | 1.0 | On | | [`topic_stall`](/rules/topic-stall) | Topic stall | 1.0 | On | | [`gnss_jamming`](/rules/gnss-jamming) | GNSS jamming | 1.0 | On | | [`gps_quality_drop`](/rules/gps-quality-drop) | GPS quality drop | 1.0 | On | | [`log_dropout`](/rules/log-dropout) | Logger dropout | 1.0 | On | | [`clock_uncertain`](/rules/clock-uncertain) | Clock uncertain | 1.0 | Always on, locked | | [`battery_sag`](/rules/battery-sag) | Battery sag | 0.9 | Off | Each version's threshold is in [Limits and defaults](/reference/limits#rule-thresholds) and on the rule's own page. ## Trace a rule's history in your deployment [#trace-a-rules-history-in-your-deployment] 1. Open **Audit log**. 2. Choose **Administration**, where **Changed rule**, **Enabled rule** and **Disabled rule** entries are filed. 3. Type the rule ID in **Filter by person, action or object**, such as `memory_pressure`. Each entry shows its time in UTC, the person, the action, the rule ID as object and a detail with the version. Its **Entry** cell carries the entry number and hash, so a missing or altered entry breaks the chain. **Export** writes the entries with their hashes, as JSON Lines or CSV. Under **All**, the same filter also finds **Dismissed finding** entries for that rule, whose detail starts with the rule ID. In the example dataset, filtering on `memory_pressure` finds one **Changed rule** entry, made by an admin on 25 Sep 2026 at 17:20:30 UTC. Its detail reads "Override for T4 vehicles: 24,576 MiB, version 1.1". ## Rule versions and releases [#rule-versions-and-releases] The [release notes](/release-notes) list no rule changes, so your audit log is the record of every version your rules have had. ## Related [#related] * [How rules work](/rules) explains what a rule reads and what its wording claims. * [Thresholds, scopes and overrides](/rules/configure) walks through editing a rule. * [Audit log](/security/audit-log) covers filtering, verification and export. * [Rules and findings](/concepts/rules-and-findings) explains how findings stay apart from what an engineer writes.