How rules work

A rule reads one kind of evidence and flags one kind of event: a unit leaving the active state, a receive gap, a failsafe. The console calls them deterministic detections. The same files and the same rule versions give the same findings, so a reviewer who reruns them next month gets the same answer.

Rules run as the last step of every import, after Foxborne has validated, hashed, parsed and aligned the files. On the run page, Import job opens those steps with their timings. A finding therefore sits on the same aligned timeline as the events around it, with its source's error bound.

What a rule reads#

Each rule reads one source, except clock_uncertain, which checks them all.

A rule with nothing to read produces nothing, so a missing finding is not evidence that nothing happened. The run page marks a run that lacks a source as Partial. Its note reads "Findings that depend on the missing source are not produced, and reports list the gap under Limitations."

What a finding records#

The console shows a finding in four places:

• the timeline's Findings row, subtitled Rule results, as a flag with a short name;
• the Events in view table, in bold, with the rule in the Rule column;
• the evidence inspector's Rule block, with Rule, Detects, Threshold and Wording;
• the event page's Highlights, with Rule and Finding.

Rules observe, engineers conclude#

This note sits under the table on the console's Rules page. Twelve rules start their wording with Observed:, and clock_uncertain starts with Warning:. The wording is fixed per rule, "so every report describes the same detection the same way", as the rule editor puts it.

A rule's output sits on the first rung of the evidence levels: observed. Linking two findings, proposing a cause or declaring a question unknown is the engineer's work.

The report draws that line in writing. Under the engineer's finding it states "This paragraph is the engineer's. Everything below it is extracted from the sources."

Versions#

A rule's version shows under its name in the Rules table, for example process_exit 1.2. Saving any change to a rule creates the next version, and the rule editor names it before you save: Saves as process_exit 1.3.

The number after the dot goes up by one, so 1.2 becomes 1.3 and 0.9 becomes 0.10.

Findings already produced keep the version and the threshold that made them. The editor's hint says so: "Results already produced keep version 1.2 and its threshold." A report can cite a finding made under a threshold that has since changed, and the version tells the reviewer which one applied.

The example dataset lists telemetry_gap 1.3, process_exit 1.2, memory_pressure 1.1 and battery_sag 0.9, and 1.0 for the other nine rules. Your deployment may show different versions after its own threshold changes. Rule versions records rule version changes across releases.

Scopes and overrides#

Applies to sets which vehicles or sources a rule covers. It is free text, and the example dataset uses All vehicles, Q4 vehicles, T4 vehicles and All sources. The Rules table shows the scope under each threshold.

An Override gives part of the fleet its own value. The example dataset has one: memory_pressure applies 6,144 MiB to Q4 vehicles and carries the override T4 vehicles: 24,576 MiB. vibration_high keeps its per-platform values inside the threshold text instead: Above 24 m/s² for 1 s (T4), 12 m/s² (Q4).

The locked rule#

clock_uncertain is always on, and its drawer has no Edit. Its Enabled switch is disabled too, with the tooltip "Always on. Every ordering claim depends on it."

A before or after claim between two sources is only as good as the clocks this rule checks.

Switching rules on and off#

The Enabled switch takes effect at once, with no confirmation. The toast states when the change applies, for example Battery sag enabled. Applies to the next import.

The audit log records Enabled rule or Disabled rule with the rule's version, which does not change.

battery_sag is the only rule that ships switched off in the example dataset.

Running rules again#

A run page carries a Run rules again button. It reruns the rules on the run's files, and the toast reports the outcome: Rules ran again. Results are identical to the previous run.

The audit log records Ran rules again against the run ID, under Imports.

Identical results are the point, and the run page's Import job drawer states the same guarantee: "Deterministic. The same files and parser versions give the same event IDs." A reviewer who doubts a finding can rerun it and see the same event, threshold and values come back.

Dismissing a finding#

An engineer can dismiss a finding that does not apply, for example a restart during a scheduled bench test. In the evidence inspector's Rule block, select Dismiss this finding.

The dialog states what happens: "The raw evidence is not changed. The dismissal and its reason are kept in the audit log and shown in the report." A Reason is required.

Select Dismiss finding, and the toast reads Finding dismissed. The evidence is unchanged.

The flag leaves the Findings row, and the inspector shows Dismissed with the name and the reason. The audit log records Dismissed finding with the rule and the reason, under Evidence.

All rules#

Next#

• Thresholds, scopes and overrides walks through editing a rule and switching it on or off.
• Rules and findings places rules in the whole reconstruction.
• Evidence levels explains observed, correlated, hypothesis and unknown.
• Telemetry gap shows one rule end to end, from the records it reads to an example finding.