Skip to main content
This page is the decision logic behind the Recurring faults tab on the Warranty page. Read the tab description first; this page explains the order in which the rules are applied.

​
Matching one pair

The subject is always the later defect. Every earlier defect on the same asset within the window is a candidate, and each candidate is tested in the order below. The first rule that holds decides the basis of the pair; the rules after it are not evaluated. Two thresholds appear in the graph and they are not the same control: Text similarity is computed for every pair and shown as a percentage, whatever the basis. On COMPONENT, FAULT_CODE and PRODUCT_GROUP pairs it is informational and can be low. The graph reads the product-group rule as a strict order: a pair on one root path never becomes CROSS_GROUP. If its text is below the text threshold but at or above the cross-group threshold, it still qualifies, and it keeps the TEXT basis.
The window is directional. A defect only looks backwards, so a pair is listed once, on the later defect. The earlier defect gets no row from that pair, though it may have rows of its own from defects that preceded it.

​
From pairs to rows

A grid row is one subject defect with at least one visible pair. The row aggregates its pairs:
  • Component, Fault code, Product group — a green check when any pair shares that criterion.
  • Text — the highest similarity among the pairs.
  • Matches — the number of pairs.
Rows sort by the strongest basis among their pairs, in the order COMPONENT, FAULT_CODE, PRODUCT_GROUP, TEXT, CROSS_GROUP, then by descending score. The drawer lists the pairs in the same order.

​
What hides a pair

Matching is computed on every request. Two persisted states take pairs out of the default view. The tab never shows them; the API returns them flagged with the reason when asked (include_hidden). The drawer is where both states are produced. Dismiss records one pair, Dismiss all matches records every visible pair of the subject, and Create warranty claim raises the REPARATION claim that marks the subject handled. That claim stores one visible match as its original defect — used directly when there is one, picked by the Warranty Manager when there are several — so the shortcut is absent once every match is hidden. All three are Warranty Manager actions.