Dev to main, 17th August, 2026

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.
 
+<img src="/images/docs/protect/guides/review-guardrail-activity.png" alt="The Guardrails Analytics tab on the 30d range, showing the Trigger Rate, Blocked, Warned and Avg Latency cards above the Guardrail Triggers Over Time chart and the start of the Top Triggered Rules table" style={{ borderRadius: '5px' }} />
+*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

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).
 
+<video
+  autoPlay
+  muted
+  loop
+  playsInline
+  className="w-full rounded-xl shadow-lg"
+  src="/images/docs/protect/guides/turn-on-a-guardrail.mp4"
+/>
+*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,23 +27,23 @@ 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**.
 
 <Note>
 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.
 </Note>
 
 ## 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