Choosing the Right Diagnostic Boundary: Component, Module or Assembly?

Start with the decision the service team can make

A detailed diagnostic model can represent individual components inside a module. That does not automatically make component-level fault isolation the right objective for every service team.

A field technician may be authorized to replace a sealed module but not open it. A workshop may have the fixtures, procedures and qualifications to investigate its internal components. Both teams can work on the same equipment while needing different diagnostic outcomes.

The useful diagnostic boundary is the level at which evidence supports an authorized service decision—not simply the smallest item shown on a drawing.

This article focuses on choosing that boundary. For the distinction between connectivity and diagnostic dependencies, see Why a Circuit Diagram Is Not a Diagnostic Model.

Separate three boundaries before selecting a repair level

The word “component” can hide several different meanings. Make these three boundaries explicit:

Boundary	Question to answer	What can go wrong if it is ignored?
Modeled item	What function or item does the model represent?	A detailed representation is mistaken for evidence that every internal fault can be isolated.
Evidence	Which items can the available observations actually distinguish?	A result names one internal item even though several explanations remain possible.
Authorized repair	What may this team repair, adjust or replace in this environment?	Diagnosis continues toward an action the technician cannot safely or legitimately perform.

These boundaries need not coincide. A module may contain several modeled elements while remaining the smallest permitted field replacement. Conversely, knowing that a team can replace a part does not mean that the available tests can justify selecting it.

The iTech components guide describes including items that need diagnosis or could cause failure. It also distinguishes those modeled components from a flat spare-parts list, which does not describe their particular function in the system. The parts catalogue alone therefore does not determine the diagnostic boundary.

Compare service settings, not just physical sizes

“Component,” “module” and “assembly” are relative terms. Define what they mean for the product rather than assuming that an assembly is always too broad or a component is always the best answer.

Service setting	Evidence and access to establish	Potentially appropriate outcome
Field service with approved module replacement	External inputs and outputs can be tested, but internal access is restricted.	A justified module-level conclusion, followed by replacement and functional verification.
Equipped repair workshop	Approved fixtures and procedures can distinguish internal candidates.	Component-level isolation where the evidence supports it, followed by the required repair and acceptance tests.
Site with limited test access	Available observations cannot separate a module from its connections or supporting items.	An explicit unresolved group and an approved escalation—not a falsely precise diagnosis.

These are engineering decision examples, not claims that iTech automatically creates separate field and workshop workflows.

The setting also affects which information is worth collecting. An additional internal measurement may be valuable in a workshop and unavailable on site. That difference is a reason to define the service strategy, not a reason to infer an internal result without testing.

Worked example: a cooling module in two service environments

Illustrative example only—not a customer installation or a recorded iTech session. Consider a cooling module containing a fan, a local control board and internal wiring. Its external power, command and operating conditions must be valid before a functional test can meaningfully assess the module.

Assume that an approved procedure establishes those external conditions and finds that the module fails its specified functional check. Also assume that field personnel may replace the complete module but may not open it.

For that team, the evidence may support a module-level repair decision without identifying whether the internal fan, board or wiring failed. Calling the fan faulty would claim more than the test established.

At a qualified workshop, additional approved tests might distinguish the internal candidates. If those tests are unavailable or inconclusive, the workshop must retain the uncertainty too. Having permission to open the unit does not itself provide discriminating evidence.

Now change the field evidence: suppose the technician cannot establish that the external command is correct. The same symptom no longer justifies treating the module as faulty. The supported outcome may remain a group containing the command path and module, with an escalation to obtain the missing evidence.

The repair boundary has not changed, but the strength of the diagnostic conclusion has. That distinction prevents “replaceable” from becoming a synonym for “proven faulty.”

Make the stopping rule explicit

For each intended service setting, write down when investigation should stop and what happens next:

1. Define the required outcome. Is the purpose to select a field-replaceable module, identify an internal workshop repair, or determine whether escalation is needed?
2. Specify the evidence. State the operating conditions, measurements and tolerances required to support that outcome.
3. Check practical access. Confirm that the responsible team has the approved tools, qualifications and safe access needed to collect that evidence.
4. Define unresolved outcomes. If the tests cannot separate the remaining candidates, identify the permitted next action rather than forcing a single-item result.
5. Define repair verification. Specify how the repaired equipment will be checked before return to service.

Treat this as a service-engineering decision record, not a description of an automatic iTech policy engine.

The iTech repair-procedures guide includes information for repair and return to operation, such as safety isolation, replacement, adjustment, calibration and reset. Selecting a replacement item is therefore not the end of the service procedure.

Follow the equipment's approved safety and operating instructions. A desire for finer resolution never justifies bypassing an interlock, opening restricted equipment or performing an unauthorized live measurement.

Decide whether finer resolution changes the next action

More detailed isolation can be useful when it changes a permitted repair decision. It may be less useful on site when every possible internal result leads to the same approved module replacement.

That does not make internal detail worthless. It may support workshop repair, engineering investigation or later design improvements. The question is whether the additional test belongs in this service setting and this investigation.

Consider the extra access, setup, equipment, disturbance and repair-verification work alongside the value of the distinction. Do not assume that the smallest replacement item produces the lowest total service cost. Equally, do not use convenience as a substitute for adequate evidence before replacing an assembly.

If a finer distinction is important but impossible with current access, record it as a testability gap. The related design-for-testability article explains how such gaps can inform product and test design.

Validate the boundary as part of the diagnostic application

Validation should include cases that reach the intended repair level and cases that must stop short of it.

Review representative examples where:

• The evidence justifies the permitted replacement or repair.
• An external dependency fails, so the downstream module cannot yet be assessed.
• Two internal causes remain indistinguishable with the available tests.
• The necessary test is unavailable in the intended service environment.
• The repair has been completed but return-to-service verification fails.

The iTech model-validation guide calls for expert review and simulated troubleshooting, followed by real-system validation where possible. Any real-system fault testing must be controlled, authorized and safe.

A useful diagnostic boundary produces a justified next action and an honest statement of what remains unknown. That may be a component repair, a module replacement or an escalation. The right choice depends on the evidence and the service environment—not the apparent precision of the model.

To discuss appropriate diagnostic resolution for your equipment and service organization, request an iTech demonstration.