diff --git a/public/images/docs/protect/guides/review-guardrail-activity.png b/public/images/docs/protect/guides/review-guardrail-activity.png
new file mode 100644
index 00000000..8ff755ce
Binary files /dev/null and b/public/images/docs/protect/guides/review-guardrail-activity.png differ
diff --git a/public/images/docs/protect/guides/turn-on-a-guardrail.mp4 b/public/images/docs/protect/guides/turn-on-a-guardrail.mp4
new file mode 100644
index 00000000..6f63a77b
Binary files /dev/null and b/public/images/docs/protect/guides/turn-on-a-guardrail.mp4 differ
diff --git a/src/pages/docs/protect/guides/review-guardrail-activity.mdx b/src/pages/docs/protect/guides/review-guardrail-activity.mdx
index 6c1666a3..bc99d2cf 100644
--- a/src/pages/docs/protect/guides/review-guardrail-activity.mdx
+++ b/src/pages/docs/protect/guides/review-guardrail-activity.mdx
@@ -22,6 +22,9 @@ Four numbers sit at the top. Together they say how often guardrails are firing,
Below the numbers, the **Guardrail Triggers Over Time** chart plots trigger volume across the selected range, so you can spot a spike or a change in behavior.
+
+*Trigger Rate is a share of every request, not a count, so a couple of blocks against a month of traffic still rounds to 0.0%*
+
The **Top Triggered Rules** table breaks that volume down by rule. Use it to see which check is driving the volume, and whether that check is mostly blocking or mostly warning. One rule taking up most of the Share is usually the one worth investigating first, and that's what the next section walks through.
## Find the requests in Logs
diff --git a/src/pages/docs/protect/guides/turn-on-a-guardrail.mdx b/src/pages/docs/protect/guides/turn-on-a-guardrail.mdx
index 3fef620e..4df383aa 100644
--- a/src/pages/docs/protect/guides/turn-on-a-guardrail.mdx
+++ b/src/pages/docs/protect/guides/turn-on-a-guardrail.mdx
@@ -7,6 +7,16 @@ Every check in Protect's guardrail catalog starts out switched off. This guide f
This guide assumes Agent Command Center, where Protect's guardrails live under Gateway, is already set up with at least one provider connected. If it isn't yet, start with the [Agent Command Center Quickstart](/docs/command-center/quickstart).
+
+*PII Detection sits below every AI-Powered check, so expect to scroll a fair way down the Rules catalog before you reach it*
+
## Find the check in Rules
Go to **Gateway** > **Guardrails** > **Rules**. The Rules tab lists the full guardrail catalog as a list of check cards, split between **AI-Powered Checks** and **Rule-Based Checks**. **PII Detection** sits under **Rule-Based Checks**; find its card there. Each card carries a **Switch** and a pencil icon button.
@@ -17,15 +27,15 @@ Click the **Switch** on the **PII Detection** card. This only stages the change:
## Set how it behaves
-Click the pencil icon button on the card to open the check's dialog, then set:
+Click the pencil icon button on the card to open **Configure: PII Detection**, then set:
1. **Enabled**: leave it on (it mirrors the card's **Switch**, so it already matches what you just set)
2. **Action**: set to **Block**
-3. **Confidence Threshold**: leave at its default of 0.8
+3. **Confidence Threshold**: a slider running 0.0 to 1.0, with the current value shown in the label; leave it at its default of 0.80
For provider-backed checks, the dialog also has a Provider Settings section (see the note below). It always has Cancel and Save buttons. For what action and threshold actually do to a request, see [Understanding Protect](/docs/protect/concepts/understanding-protect).
-Click **Save** to close the dialog.
+Click **Save** to close the dialog. The card changes to show it's now carrying your settings: its badge flips from **Inherited** to **Custom**, a **Reset** button appears beside the pencil, and a summary line reads **Action: block** and **Threshold: 0.80**.
If the check calls out to an external provider, **Provider Settings** is where that check's own provider connection lives (not the model provider connected during Agent Command Center setup). **PII Detection**'s dialog has no Provider Settings section, so skip it. (See [Guardrail checks](/docs/protect/reference/guardrail-checks) for which checks are provider-backed.) For a check that does use a provider, a credential you've already saved shows up masked; click into the field and it clears, ready for you to enter a new one.
@@ -33,7 +43,7 @@ If the check calls out to an external provider, **Provider Settings** is where t
## Push the change to the gateway
-Nothing you set in the check's dialog reaches the gateway until you save here. Back on the Rules tab, an info banner now reads "You have unsaved changes. Save to push guardrail config to the gateway.", with **Reset** and **Save & Activate** buttons. This **Reset** discards the unsaved changes shown in the banner, not the check's saved configuration. It's a separate control from the **Reset** button that appears on a check's card once the check has been customized: that one clears the customization, switching the check back off and its action and threshold back to the defaults (**Block**, **0.8**). Click **Save & Activate**; while the save is in flight the button reads **Saving...**.
+Nothing you set in the check's dialog reaches the gateway until you save here. Back on the Rules tab, an info banner now reads "You have unsaved changes. Save to push guardrail config to the gateway.", with **Reset** and **Save & Activate** buttons. This **Reset** discards the unsaved changes shown in the banner, not the check's saved configuration. It's a separate control from the **Reset** button that appears on a check's card once the check has been customized: that one clears the customization, switching the check back off and its action and threshold back to the defaults (**Block**, **0.8**). Click **Save & Activate**; while the save is in flight the button reads **Saving...**, and a toast confirms with "Config saved and activated".
## Confirm it in Overview