A device coupled to another far off in the hierarchy needs a direct jump, not a walk up and down

What it is

A cross-hierarchy link connects the object currently on screen directly to an upstream or downstream device, an interlocked object, a backup unit, or a controlling asset that has a genuine task dependency with it, even when that object sits in a different branch of the navigation tree and would otherwise take several levels to reach. What is being linked is a dependency that exists in the task itself, not a recently visited screen or a system-generated "related content" suggestion.

Why it happens

Faults and anomalies propagate along physical piping, electrical connections, and logical interlocks, and that propagation path is often unrelated to how the navigation tree is grouped. A tree is usually organized by physical area or equipment type to make single objects easy to find by location or category, but a device's interlocked partner, backup pump, or upstream supply point can sit in an entirely different area branch. When the two structures diverge, the operator has to climb back from the current device to the common ancestor of both branches and drill down again to find the related object — this interrupts an ongoing line of diagnostic reasoning, and clues already confirmed can get lost during the climb-and-redescend. A contextual cross-hierarchy link surfaces this otherwise hidden dependency directly on the object page: one click reaches the related object, instead of the operator having to hold "what else does this connect to" in their own head.

Where it stops holding

Turning every plausibly related object into a link quickly produces a page that is itself a network of pointers, and the links then need time to read and choose among — at that point the shortcut's benefit is cancelled out by the new selection burden, which is just navigation maze in a different shape. When the dependency is inferred automatically, say from historical action sequences or visit frequency, it goes stale as equipment is modified or piping is rerouted, and needs deliberate maintenance rather than a one-time generation. Security zoning and access control can legitimately restrict whether an operator can actually enter a related object's control screen, but even when access is restricted, the link itself — where it points and who owns it — should stay visible; a permission boundary should not be used to hide the dependency's existence.

Applying it

Draw a small, fixed set of relationship types from hazard analysis documents and real diagnostic cases — upstream supply, downstream effect, interlock trigger, backup/standby switchover, controlling asset — and implement only these, not a generic "related items" feature. Label the direction and type of each link explicitly on the object page rather than showing an unlabeled arrow. Preserve the point of origin when a link is followed, so the operator can return the way they came. To validate, use simulated faults that propagate across areas and compare the number of backtracks and wrong-object visits with and without these links.

Related

• Same group: Y3.11.1 Overview-to-equipment drill-down · Y3.11.2 Direct return from deep views · Y3.11.3 Costs of excessive navigation depth
• Nearby: Y3.06 Process diagrams and topology representation · Y4.02 Redundancy and voting
• Search terms: contextual navigation · interlock · topology-aware linking · process control HMI