# Expected Diagnosis: region-unavailable-escalation-during-incident-window

This case is about diagnosis path quality, not only raw evidence collection.

The expected answer should make a two-layer distinction:

- `direct cause`: why users saw `Region is unavailable` during the incident
- `deeper root cause` or `strongest current hypothesis`: the component-level
  failure path that drove the pending-peer buildup, rather than stopping at the
  region-health symptom itself

The answer should:

- identify pending-peer or equivalent region-health buildup as the direct
  trigger behind the user-visible error
- avoid treating pending-peer alone as the final root cause
- escalate into a component-level panic / restart / assertion path
- explain that the value of the diagnosis is the escalation from symptom-level
  evidence to component-level fault evidence
- keep evidence boundaries honest if the deepest internal mechanism is not
  fully confirmed from the currently available artifacts

What should fail this case:

- stopping at `pending-peer-region-count` and declaring the root cause closed
- giving only a generic region-health explanation without a component-level
  failure path
- mixing direct cause and deeper root cause into one shallow statement
- overstating certainty when the deepest mechanism still needs confirmation