diff --git a/explore-analyze/workflows/_snippets/schema-location-legend.md b/explore-analyze/workflows/_snippets/schema-location-legend.md
new file mode 100644
index 0000000000..fe62dac780
--- /dev/null
+++ b/explore-analyze/workflows/_snippets/schema-location-legend.md
@@ -0,0 +1,5 @@
+**Schema convention.** In each schema table below, the `Location` column indicates where each parameter sits in the YAML:
+
+- `top level` — Alongside `type` and `name`, at the top of the step or trigger definition.
+- `` `with` `` — Inside the step's `with:` block.
+- `` `on` `` — Inside the trigger's `on:` block.
diff --git a/explore-analyze/workflows/steps/ai-steps.md b/explore-analyze/workflows/steps/ai-steps.md
index dad0649ed0..765054abe6 100644
--- a/explore-analyze/workflows/steps/ai-steps.md
+++ b/explore-analyze/workflows/steps/ai-steps.md
@@ -28,6 +28,9 @@ AI steps let workflows call a large language model (LLM) for reasoning, classifi
 `connector-id`, `agent-id`, and `inference-id` are **top-level step fields** (alongside `name`, `type`, `if`, `foreach`), written in **kebab-case**. They are not nested under `with`, and not `connectorId`. Inside `with`, most AI parameters use `camelCase` (`systemPrompt`, `maxLength`, `includeRationale`). Authentication-style references stay at the top level in kebab-case; content parameters stay inside `with` in camelCase.
 :::
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## `ai.prompt` [ai-prompt]
 
 ```{applies_to}
diff --git a/explore-analyze/workflows/steps/cases.md b/explore-analyze/workflows/steps/cases.md
index 7887de7c2f..aeacd5d46d 100644
--- a/explore-analyze/workflows/steps/cases.md
+++ b/explore-analyze/workflows/steps/cases.md
@@ -41,6 +41,9 @@ Every `cases.*` step shares the same conventions, so once you learn one step the
     severity: high
 ```
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 % Ben Ironside Goldstein, 2026-04-27: Engineering review (Janmonschke) noted that not all 27 steps
 % support push-case. A complete list of which steps support it would strengthen this section once
 % available. For now the page documents the optional flag generally and leaves per-step support
diff --git a/explore-analyze/workflows/steps/composition.md b/explore-analyze/workflows/steps/composition.md
index e5587747d9..4cbf9b99b4 100644
--- a/explore-analyze/workflows/steps/composition.md
+++ b/explore-analyze/workflows/steps/composition.md
@@ -52,6 +52,9 @@ The execution engine enforces a maximum composition depth to prevent infinite re
 
 ---
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## `workflow.execute` [workflow-execute]
 
 Run a child workflow synchronously. The parent waits for the child to finish and receives its validated outputs.
diff --git a/explore-analyze/workflows/steps/data.md b/explore-analyze/workflows/steps/data.md
index 33ab3d5ec5..59f8564a4f 100644
--- a/explore-analyze/workflows/steps/data.md
+++ b/explore-analyze/workflows/steps/data.md
@@ -62,6 +62,9 @@ Refer to [Pass data and handle errors](/explore-analyze/workflows/authoring-tech
 
 ---
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## Variables and mapping
 
 ### `data.set` [data-set]
diff --git a/explore-analyze/workflows/steps/kibana.md b/explore-analyze/workflows/steps/kibana.md
index 281a410b8d..96f1de3739 100644
--- a/explore-analyze/workflows/steps/kibana.md
+++ b/explore-analyze/workflows/steps/kibana.md
@@ -25,6 +25,9 @@ All {{kib}} actions are automatically authenticated using the permissions or API
 The detection alert step type IDs use **PascalCase**, not lowercase or snake_case: `kibana.SetAlertsStatus`, `kibana.SetAlertTags`. The editor rejects lowercase variants. This is the most common authoring surprise on the {{kib}} namespace.
 :::
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## Step types
 
 - [`kibana.SetAlertsStatus`](#kibana-setalertsstatus): Change the status of one or more detection alerts.
diff --git a/explore-analyze/workflows/steps/loop-break.md b/explore-analyze/workflows/steps/loop-break.md
index aa1696dbe2..b82ba5350f 100644
--- a/explore-analyze/workflows/steps/loop-break.md
+++ b/explore-analyze/workflows/steps/loop-break.md
@@ -17,6 +17,9 @@ products:
 
 The `loop.break` step exits the innermost enclosing [`foreach`](/explore-analyze/workflows/steps/foreach.md) or [`while`](/explore-analyze/workflows/steps/while.md) loop immediately. Use it to stop iterating once a condition is met, for example when you want to process items until you find the first critical match and then move on.
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## Parameters
 
 The `loop.break` step takes no step-specific parameters; only the standard `name` and `type` fields required on every step.
diff --git a/explore-analyze/workflows/steps/loop-continue.md b/explore-analyze/workflows/steps/loop-continue.md
index 232389b5d8..ddc2eaec04 100644
--- a/explore-analyze/workflows/steps/loop-continue.md
+++ b/explore-analyze/workflows/steps/loop-continue.md
@@ -17,6 +17,9 @@ products:
 
 The `loop.continue` step skips the rest of the current iteration in the innermost enclosing [`foreach`](/explore-analyze/workflows/steps/foreach.md) or [`while`](/explore-analyze/workflows/steps/while.md) loop and moves on to the next iteration. Use it to skip items that don't meet a filter, without nesting the remaining logic inside an `if`.
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## Parameters
 
 `loop.continue` takes no parameters.
diff --git a/explore-analyze/workflows/steps/streams.md b/explore-analyze/workflows/steps/streams.md
index 19ca9f1998..06e3ee79f9 100644
--- a/explore-analyze/workflows/steps/streams.md
+++ b/explore-analyze/workflows/steps/streams.md
@@ -21,6 +21,9 @@ Streams action steps operate on Observability [Streams](/solutions/observability
 Streams action steps, along with the Streams feature itself, are in technical preview in 9.4. Schemas and semantics can change in future releases. Use these steps for prototypes and investigation workflows; hold off on critical automation until Streams reaches GA.
 :::
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## Step types
 
 - [`kibana.streams.list`](#kibana-streams-list): Enumerate available streams.
diff --git a/explore-analyze/workflows/steps/switch.md b/explore-analyze/workflows/steps/switch.md
index 3687919466..53464486d0 100644
--- a/explore-analyze/workflows/steps/switch.md
+++ b/explore-analyze/workflows/steps/switch.md
@@ -17,6 +17,9 @@ products:
 
 The `switch` step evaluates an expression once and compares its value against each case's `match` field in order, then dispatches to the first matching case and executes its `steps`. Use it for multi-way branching where an `if` chain would be awkward (for example, routing by alert category, severity tier, or environment name).
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## Parameters
 
 | Parameter | Location | Type | Required | Description |
diff --git a/explore-analyze/workflows/steps/wait-for-input.md b/explore-analyze/workflows/steps/wait-for-input.md
index 1655d73f6f..53ff65bd42 100644
--- a/explore-analyze/workflows/steps/wait-for-input.md
+++ b/explore-analyze/workflows/steps/wait-for-input.md
@@ -19,6 +19,9 @@ The `waitForInput` step pauses workflow execution until a human submits input. I
 
 For the end-to-end pattern including resume API details and design guidance, refer to [Human-in-the-loop](/explore-analyze/workflows/authoring-techniques/human-in-the-loop.md).
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## Parameters
 
 | Parameter | Location | Type | Required | Description |
diff --git a/explore-analyze/workflows/steps/while.md b/explore-analyze/workflows/steps/while.md
index 9952262b87..c709f31014 100644
--- a/explore-analyze/workflows/steps/while.md
+++ b/explore-analyze/workflows/steps/while.md
@@ -19,6 +19,9 @@ The `while` step runs its nested steps repeatedly as long as a {{kib}} Query Lan
 
 Use `while` for polling patterns: checking a status until it reaches `ready`, retrying an operation until it succeeds, or waiting for an external job to complete. For iterating over a known collection, use [`foreach`](/explore-analyze/workflows/steps/foreach.md) instead.
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## Parameters
 
 | Parameter | Location | Type | Required | Description |
diff --git a/explore-analyze/workflows/triggers/event-driven-triggers.md b/explore-analyze/workflows/triggers/event-driven-triggers.md
index 9ef2ec27e3..747135956d 100644
--- a/explore-analyze/workflows/triggers/event-driven-triggers.md
+++ b/explore-analyze/workflows/triggers/event-driven-triggers.md
@@ -24,6 +24,9 @@ Event-driven triggers let workflows react to events elsewhere in {{kib}}. Two tr
 The event-driven trigger system is in technical preview, including the triggers documented on this page. The schema and semantics can change in future releases.
 :::
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 ## `workflows.failed`
 
 Fires when any workflow execution reaches the `failed` terminal state. Use this trigger to build handler workflows that react to failures in your production workflows, for example by paging on-call, opening a case, or logging to a dedicated index for observability.
@@ -163,8 +166,6 @@ Cases triggers fire when cases change. Use them to react to case lifecycle event
 - `event.caseId` — The case ID, the alphanumeric identifier that is unique to each case.
 - `event.owner` — The solution that owns the case. It can be `securitySolution` for {{elastic-sec}} cases, `observability` for Observability cases, or `cases` for Stack cases.
 
-**Schema convention.** In each trigger's schema table below, the `Location` column indicates where each parameter sits in the trigger YAML. `top level` means the parameter sits alongside `type`; `` `on` `` means it sits inside the `on:` block, parallel to how `workflows.failed` uses `on:` for its condition.
-
 Use `event.owner` in `on.condition` to filter by solution. For example, a workflow that only fires for {{elastic-sec}} cases:
 
 ```yaml