How iTech Chooses the Next Best Test

The next step should reflect what is known now

After a fault report, several components may be plausible causes. A useful diagnostic system must do more than display that suspect list: it should help decide which observation to obtain next.

The iTech technique guide summarizes the approach using three considerations:

1. How quickly a test can be performed.
2. Where failure is more probable.
3. How effectively the result can eliminate remaining suspects.

The diagnostic model supplies the relationships that make test results meaningful. Probability and time or cost then help choose among the remaining useful opportunities.

These considerations work together. The quickest test, the most failure-prone component, or the most balanced split is not necessarily the best choice when considered alone.

First, use the evidence already available

A symptom, a built-in-test result, or a previously completed observation may already establish that part of the system is working or failing.

That evidence can reduce the relevant suspect set before another physical test is requested. A working function may support conclusions about shared dependencies; an invalid input may explain why a downstream function cannot operate.

Each conclusion depends on the model and test conditions. A good reading under one operating state does not prove every function healthy under all conditions.

For this reason, selecting the next test starts with a correct interpretation of the present evidence—not with a universal instruction to test a particular component first.

Failure probability helps prioritize, but does not prove

Two suspect areas can both fit the observations while having different recorded failure histories. Investigating the more failure-prone area may be sensible, particularly if it can be checked quickly.

iTech's automated-learning documentation describes using previous failures to adapt its test pattern.

History remains a guide to investigation, not a replacement for evidence. An infrequently failing component can still cause today's incident. Conversely, a commonly failing component should not remain the preferred explanation after reliable evidence rules it out.

The design-based logical core also means that structural diagnosis does not require a past example of every fault. See How iTech Diagnoses Faults It Has Never Seen Before.

A useful test separates plausible explanations

Consider a suspect set spread across an upstream group and a downstream group. A valid test at their functional boundary might distinguish an upstream failure from a downstream one.

This illustrates split-half reasoning: seek a result that divides the remaining possibilities usefully, rather than checking isolated components one by one.

The guide describes eliminating as close to half the remaining suspects as possible. This is a simplified explanation, not a requirement to divide every suspect set into equal numbers. Unequal failure probabilities and unequal test effort can change the practical value of a split.

Nor does a failed boundary test automatically identify the component at that boundary. It may leave several upstream causes unresolved. The model determines what the observation can legitimately establish.

Time and cost keep the strategy practical

A highly informative test may be unattractive if it requires substantial preparation. A less dramatic observation may be preferable when it is quick and removes a meaningful portion of the current uncertainty.

Relevant work includes the test itself and its associated setup. The training distinguishes shared preparation from individual measurements, while the optimization guide emphasizes overall time to test and replace.

Time and cost are alternative optimization priorities in the documented approach. Field downtime can make speed especially important; workshop economics may justify a different choice.

Real tests must remain within approved procedures and available capabilities. Optimization is not permission to skip safety steps or use a test under invalid conditions.

Worked example: choosing among three opportunities

Illustrative example, not an engine calculation or a performance benchmark. A modeled function has failed, leaving several possible causes. Three tests are available:

• Test A is quick, but establishes little beyond the symptom already reported.
• Test B tests a useful dependency boundary and could eliminate a substantial group of suspects, with moderate preparation.
• Test C checks the historically most failure-prone assembly, but requires difficult access.

Choosing solely by duration favors A. Choosing solely by failure history favors C. Choosing solely by the size of a suspect split might favor B.

The iTech approach considers these factors together using the model and current session evidence. Without the actual probabilities, procedure times, dependencies, and expected outcomes, this example cannot specify which test the engine would select.

Suppose a valid result then clears a previously suspect shared input. The remaining candidate set changes, so the value of the available tests changes too. The next recommendation is reassessed for that new situation.

Expert knowledge can guide the sequence

iTech also supports rules that add symptom information or specify tests to perform in order. The rules guide describes checking whether a listed test already has a result before performing it.

This lets a modeler encode a deliberate shortcut or required diagnostic sequence. Such rules complement the model-based strategy; they do not mean that all possible incidents must be reduced to a prewritten decision tree.

Better recommendations begin with better models

Useful recommendations depend on accurate dependencies, trustworthy results, realistic procedure times, appropriate failure information, and available tests.

If no test can separate the remaining explanations, no ranking strategy can manufacture that missing evidence. The outcome may remain an ambiguity group until testability or model coverage improves.

“Next best” therefore describes a choice grounded in the represented system and available information—not a promise of the globally shortest repair for every possible incident.

For the practical consequences of test effort, read Why Fewer Tests Do Not Always Mean Faster Repairs.