Now let me check the metrics subskill for TiKV resource control metrics:No resource control metrics in the pre-cataloged docs. Let me check the metrics help and query for the relevant TiKV resource control metric directly:That metric name didn't match. Let me try other likely metric names:Let me look at TiKV resource control metrics more carefully from the known metric schema and try a broader search:I found the key metric: `tikv_resource_control_priority_quota_limit`. Let me also check for the specific refill rate metric for the low-priority DAG throttle:Now let me look at the `tikv_resource_control_priority_quota_limit` metric in detail and search for any metrics specifically related to the refill rate for low-priority DAG:Still empty. This is a Premium cluster — let me check the cluster metadata and understand its topology first to determine the correct metric routing:This is a Premium resource pool cluster (`deployTypeV2: "premium resource pool"`) with no topology available. The key metadata: `parentID` is empty, which means it's the resource pool itself. Let me check the tidb-knowledge-base for Premium metric routing rules:Critical finding: for TiKV metrics on a Premium cluster, I need to use the `parent_id` (resource pool ID), not the premium cluster_id. The metadata shows `parentID: ""` which means this cluster IS the resource pool. Let me verify this and check TiKV metrics using the cluster's own ID since it's the resource pool:Excellent! Now I have confirmation:
- `2026948324023603200` is the **resource pool** (`premium resource pool`)
- `10748116073341772391` (`prod-c66-seamless-others`) is a child Premium cluster with `parent_id=2026948324023603200`

According to tier-architecture, for TiKV metrics in Premium, I need to use the **parent_id** (resource pool ID) as the `cluster_id`. Since the resource pool itself IS `2026948324023603200`, TiKV metrics should route to this same ID. The metrics returning empty may be because the metric name is wrong. Let me try broader PromQL with wildcard matching:The key note from the SUBSKILL: **"IMPORTANT: `tidb_cluster_id` is auto-injected for non-starter/essential clusters. If you suspect the metric is from shared Resource Pool components (Premium/BYOC), and the query returns no data, try adding `{tidb_cluster_id="{parentID}"}` manually."**

Since `2026948324023603200` is the resource pool itself (parentID is empty), TiKV metrics routing for this pool's cluster_id should work. But the metrics keep returning empty. Let me try using the Python ClinicAPI directly to do series discovery and check what resource control metrics actually exist:TiKV metrics do exist for this cluster. Now let me try discovering `tikv_resource_control_priority_quota_limit` with a prefix search:Excellent! Found it! The exact metric is `tikv_cpu_throttle_low_priority_dag_refill_rate_us_per_interval`. Now let me query this metric over the window to observe the actual values:The observed refill rate is consistently **992,000 µs/interval** across all 24 TiKV instances throughout the entire window. Now let me also check the global refill rate to understand what the expected value should be for ratio=0.5:Now I have all the data needed. Let me compute the expected value:

- Global refill rate = **2,480,000 µs/interval** (this is the total CPU capacity in µs per interval available to TiKV)
- `low-priority-dag-global-ratio = 0.5` means the low-priority DAG bucket should get 0.5 × 2,480,000 = **1,240,000 µs/interval**
- Observed refill rate = **992,000 µs/interval** (constant throughout entire window, including after the 22:00 UTC change time)

The observed value of 992,000 does NOT match the expected 1,240,000 for ratio=0.5. The config change did not take effect on TiKV.

```json
{
  "cluster_id": "2026948324023603200",
  "window": {
    "start": "2026-07-06T21:50:00Z",
    "end": "2026-07-07T01:00:00Z"
  },
  "requested_ratio": 0.5,
  "expected_refill_rate_us_per_interval": 1240000,
  "observed_refill_rate_us_per_interval": 992000,
  "applied": false,
  "evidence_sufficient": true
}
```