# Case Schema

Every reviewed evaluator case should normalize to this shape.

```json
{
  "incident_id": "GTOC-1234 or TICKET-8412",
  "source": "jira_gtoc or pingkai",
  "initial_symptom": "",
  "canonical_incident": {
    "title": "",
    "description_text": "",
    "cluster_id": "",
    "clinic_links": [],
    "grafana_links": [],
    "time_window": "",
    "l2_assignee": "",
    "assignee_or_l3": ""
  },
  "replay_inputs": {
    "used_fields": [],
    "excluded_fields": [],
    "notes": ""
  },
  "skill_conclusion": {
    "entry_mode": "",
    "activated_subcapabilities": [],
    "reference_files_consulted": [],
    "is_tikv_side": "",
    "scope": "",
    "path": "",
    "earliest_proven_bottleneck": "",
    "key_evidence": [],
    "missing_evidence": [],
    "uncertainty_statement": "",
    "provisional_conclusion": ""
  },
  "final_human_conclusion": {
    "status": "clear or human_conclusion_unclear",
    "owner_final_comment": "",
    "structured_conclusion": "",
    "evidence_references": [],
    "analysis_windows": [
      {
        "label": "window-1",
        "start_time": "",
        "end_time": "",
        "summary": "",
        "inferred_path": "",
        "inferred_bottleneck": "",
        "evidence": []
      }
    ]
  },
  "match_level": "matched | partially_matched | mismatched | human_conclusion_unclear",
  "mismatch_type": [],
  "comparison_notes": [],
  "improvement_suggestions": [],
  "window_reviews": [
    {
      "label": "window-1",
      "start_time": "",
      "end_time": "",
      "human_summary": "",
      "skill_summary": "",
      "assessment": "",
      "notes": []
    }
  ]
}
```

## Multi-Window Extension

Use `analysis_windows` and `window_reviews` when one incident clearly contains
multiple spikes, repeated duration rises, or separated diagnostic windows.

Typical examples:
- the same TiKV instance shows two cop-wait spikes inside one Grafana window
- the owner conclusion explicitly separates two latency windows with different
  or repeated mechanisms
- the maintainer wants to record that a replay got the overall route correct
  but still failed to distinguish repeated spikes inside the same incident

Current policy:
- case-level `match_level` remains the top-level verdict
- `window_reviews` are maintainers' structured evidence for later skill
  evolution, not a replacement for the top-level verdict
- lack of `window_reviews` alone does not create a new mismatch type in the
  first version

## Replay Checkpoints

The evaluator should normalize at least these replay checkpoints:
- `entry_mode`
- `activated_subcapabilities`
- `reference_files_consulted`
- `uncertainty_statement`

Allowed `entry_mode` values:
- `not_tikv_slow_diagnosis`
- `generic_tikv_slow`
- `leader_drop`
- `io_jitter`
- `network_issues`
- `flow_control`
- `snapshot_backlog`

Allowed `reference_files_consulted` values:
- `references/cross-cutting.md`
- `references/read-path.md`
- `references/write-path.md`
- `references/leader-drop.md`
- `references/io-jitter.md`
- `references/network-issues.md`
- `references/flow-control.md`
- `references/snapshot-backlog.md`