1# AKS Structured Input Modes
2 
3Use this reference when the troubleshooting request already contains structured inputs.
4 
5## Detector-backed Mode
6 
7Use when AKS-aware detectors or AppLens-style insights are available.
8 
9Decision rules:
10 
11- Ignore findings where the detector is `emergingIssues`.
12- Prefer critical findings over warnings.
13- Prefer findings with more concrete remediation detail when choosing the likely root problem.
14- Preserve per-insight output: problem summary, root-problem flag, affected resources, suggested commands.
15 
16## Warning Events Mode
17 
18Use when the request includes Kubernetes warning events.
19 
20Expected output:
21 
22- summary of the events and their impact
23- likely cause or causes
24- next kubectl checks
25- monitoring follow-up
26 
27## Metrics Scan Mode
28 
29Use when the request includes CPU or memory time-series data.
30 
31Expected output:
32 
33- healthy or unhealthy status
34- anomaly timestamps and explanations
35- suggestion tied to the observed metric pressure
36 
37## Generic Symptoms Mode
38 
39Use when the request includes resource symptoms but not detector results, warning events, or time-series metrics.
40 
41Expected output:
42 
43- symptom summary by resource
44- likely failure domain
45- next evidence-collection steps
46 
47## Learn Grounding Fallback
48 
49If the first troubleshooting pass is incomplete, search Microsoft Learn using:
50 
51- the user prompt
52- the parsed problem names
53- the AKS troubleshooting context
54 
55Use Learn grounding to refine or validate the root-cause hypothesis, not to replace observed evidence.
56