Suspect Does Not Mean Faulty: Understanding Diagnostic States

A possible cause is not a repair instruction

A diagnostic display highlights several components in yellow. Should the technician replace them all?

No. A suspect component is a possible contributor to the selected symptom, not a confirmed fault. Replacing it before obtaining the evidence needed to distinguish it from other candidates can waste time, introduce new problems and leave the original fault unresolved.

iTech uses diagnostic states to distinguish what is known, what remains possible and what cannot yet be assessed. Reading those states correctly is as important as choosing the next test.

The iTech component/test-status guide describes good, bad, suspect, indeterminate and off-path states. These labels apply to modeled components or test points; they must be interpreted alongside the selected symptom, test results and model boundaries.

Five states, five different conclusions

State	Display color	What it means
Good	Green	Evidence supports correct operation within the specified parameters for the relevant modeled function and tested conditions.
Bad	Red	The component or test point is outside its specified parameters or is physically broken.
Suspect	Yellow	Its condition is not yet established, and it could contribute to the selected symptom.
Indeterminate	Blue	It is downstream of a bad component or test point, so its own condition cannot be determined because its required input is bad.
Off-path	Blue	It is outside the diagnostic path for the currently selected symptom or fault.

Two states share blue, but they answer different questions. Indeterminate means a bad upstream input prevents an assessment. Off-path means the component is not involved in the current symptom.

Suspect: still possible, not yet proven

Consider a function that depends on a supply, a control path and an actuator. If the expected movement does not occur, several parts of that path may be possible causes.

Yellow identifies candidates that remain relevant to the investigation. It does not rank every candidate equally, establish a failure probability by itself or authorize replacement.

The useful next step is a test that separates the remaining explanations. Depending on the equipment and available procedures, that might establish whether the required supply reaches the actuator or whether the control path delivers the expected command.

This is one reason a symptom or error code is not equivalent to a failed-part identification. See Why Error Codes Are Not Enough.

Indeterminate: a bad input prevents a fair assessment

A downstream function cannot always be judged when the input it needs is missing or incorrect.

An actuator that does not move without its required power supply may be perfectly serviceable. Its lack of movement under that condition does not distinguish a healthy actuator from a faulty one.

In the situation described by the iTech guide, that downstream component is indeterminate: a bad upstream component or test point prevents its condition from being established.

The distinction from suspect matters:

• Suspect: the component remains a possible contributor to the selected symptom.
• Indeterminate: its own condition cannot be resolved under the present bad-input condition.

Neither label means “replace this item.” Once the upstream problem is corrected or an approved alternative test provides suitable conditions, further evidence can establish the downstream component's state.

Off-path: unrelated to this symptom, not certified healthy

Off-path is about relevance to the current investigation, not proof of condition.

The iTech guide gives a straightforward example: the air conditioner in an operator's cabin has no influence on the hoist brake function. For the selected hoist-brake problem, that air-conditioning component is off-path.

It could still have a separate fault. Selecting an air-conditioning symptom would create a different diagnostic context in which it might become relevant.

That is why off-path should not be read as another form of green. The model excludes it from the current problem path; the investigation has not necessarily tested it.

Good and bad: conclusions with a defined scope

Green and red are stronger conclusions than yellow or blue, but their scope still matters.

Good means the evidence supports operation within specified parameters. A voltage must meet its tolerance, a mechanical adjustment must fall within its specified range, or a functional response must satisfy its test criteria. A passing result may also support conclusions about necessary upstream dependencies when the validated model justifies that inference.

It does not establish that every output, operating mode or load condition is healthy. An intermittent fault may also be absent during the test. These limits are explored in What a Passing Test Really Tells You.

Bad means a specified requirement is not met or a physical failure is established. But distinguish a bad observation from a confirmed faulty replaceable part. An incorrect output can result from an incorrect input; the iTech diagnostic-logic guide explains how inputs and outputs affect the conclusions that can be drawn about a component.

Even when a component is identified as bad, the appropriate remedy depends on the failure and the approved procedure. As the status guide notes, repair may involve calibration rather than total replacement.

Worked example: an actuator does not move

Illustrative example only—not a customer installation or a recorded iTech session. Assume a validated model represents a power supply, a control path and an actuator. The actuator requires the specified supply and command to perform its tested movement. A separate cabin-lighting circuit has no influence on that movement.

1. The symptom is selected. Relevant components whose condition is unresolved may remain suspect. The unrelated lighting circuit is off-path for this symptom.
2. An approved supply-path test finds a bad input at the actuator. The failed test establishes that the input is outside its specified requirement. It does not, on its own, prove which physical item in the supply path caused the failure.
3. The actuator cannot be assessed from its lack of movement. With a required input bad, the downstream actuator is indeterminate rather than proven faulty.
4. Further approved tests isolate the supply-path fault, and it is corrected. The actuator can then be evaluated under the required input conditions.
5. The functional test is repeated. A pass supports a good conclusion for the tested function and necessary dependencies within the model's scope. If all required inputs are verified good but the output remains bad, the evidence supports a bad conclusion for the actuator's modeled function.

The exact displayed states depend on the actual model and evidence. This example illustrates why the same lack of movement can lead to different conclusions as the investigation progresses.

All real-system testing and repair must follow approved safety, isolation and operating procedures.

Read the state before deciding on the action

Before acting on a diagnostic display, ask:

1. Which symptom and equipment configuration are being investigated?
2. Is this item confirmed good or bad, still suspect, indeterminate because of a bad input, or outside the current problem path?
3. Which observations or modeled dependencies justify that state?
4. Were the required test conditions and tolerances satisfied?
5. What evidence would resolve the remaining uncertainty?

Accurate models and validated procedures are essential: a color cannot compensate for a missing dependency, an unreliable measurement or a test performed under the wrong conditions.

A diagnostic state describes the conclusion supported by the current evidence and model. It is not automatically a repair instruction. Keeping suspect, indeterminate and off-path distinct helps technicians investigate the right items without treating uncertainty as proof of failure.

For how iTech selects evidence to narrow the remaining possibilities, continue with How iTech Chooses the Next Best Test.