A system may appear to be properly configured from all external indicators, but does not exhibit the expected behavior.

The first cause is that systems often have a limited ability to report their own state, or you have a limited ability to observe state.

The second cause is false assumptions.  You ''always'' make assumptions about the internal makeup of a system, based on what you can observe.

This pattern applies when a system does not exhibit expected behavior, and reasonable external observations yield no answers as to how to correct the behavior or whether to adjust expectations.

In such a case, you may need to find out "what's inside the case:"  examine the system's internal structure.

Examining the system's internal structure can correct for incorrect or vague documentation.  The system may have flaws of its own that you need to correct or work around.  Examining how a system is put together may give you insight into how the designers intended it to be used.

The danger in using this pattern is that you may replace a simple assumption about what a system does with a more intimate assumption about how it does it.  This assumption may be broken if the design changes.  Also (in cases where the system is a physical entity), playing around with a system is a good way to break it.

See ComputerTechPatterns

-- CraigPutnam