Workflows nested-inputs sweep: schema change is now live in serverless

The schema change moving inputs: from the workflow root to under
the manual trigger is now live in serverless. Updates the applies-
switch labels, dependent prose, and the migration guide section
to reflect this on all the pages this PR added or modified.

Changes:

Applies-switch labels (5 Tier 1 pages — templating.md, manual-
triggers.md, context-variables.md, composition.md, compose-
workflows.md):

- Legacy form: { stack: ga 9.4, serverless: ga } -> stack: ga 9.4
- New form: stack: ga 9.5+ -> { stack: ga 9.5+, serverless: ga }

Orientation prose on the same 5 pages: "On 9.4 and earlier (and
on serverless today), inputs sits at the top level. On 9.5+,
inputs sits inside the manual trigger." -> "On 9.4, inputs sits
at the top level. On 9.5+ and serverless, inputs sits inside
the manual trigger."

Tier 2 prose-only updates (4 pages — workflows.md, cheat-sheet.md,
enrich-alert-with-threat-intel.md, run-rules-on-demand.md): same
shape ("9.4 and serverless today" -> "9.4 only", "9.5+ structure"
-> "9.5+ and serverless structure").

Migration guide (migrate-from-9-3.md):

- Section title: "Looking ahead to 9.5: inputs schema change" ->
  "inputs schema change in 9.5 and serverless".
- applies_to: stack: ga 9.5+ -> stack: ga 9.5+, serverless: ga.
- Removed the "The change is not yet live in serverless." line.
- YAML comment headers updated to mention serverless.

Closes #6812. The corresponding update on anatomy.md ships on the
#6669 fix-up commit (still on the workflows-authoring-guidance
branch, not yet pushed).

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: benironside

explore-analyze/workflows.md

@@ -49,7 +49,7 @@ Some key concepts to understand while working with workflows:
 
 ## Workflow structure [workflow-structure]
 
-Workflows are defined in YAML. In the YAML editor, describe _what_ the workflow should do, and the platform handles execution. The example below uses the 9.5+ structure, where `inputs` is defined under the `manual` trigger. On 9.4 and serverless today, `inputs` sits at the workflow root. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for both forms.
+Workflows are defined in YAML. In the YAML editor, describe _what_ the workflow should do, and the platform handles execution. The example below uses the 9.5+ and serverless structure, where `inputs` is defined under the `manual` trigger. On 9.4, `inputs` sits at the workflow root. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for both forms.
 
 ```yaml
 # ═══════════════════════════════════════════════════════════════

explore-analyze/workflows/authoring-techniques/compose-workflows.md

@@ -45,11 +45,11 @@ A child workflow is a unit of code with a public interface. Treat it like one.
 
 Use the `inputs` and `outputs` fields to spell out the contract. The engine validates inputs at invocation and outputs at `workflow.output` time, so callers can rely on shape without guarding against missing keys.
 
-The location of `inputs` in the YAML depends on your version. On 9.4 and earlier (and on serverless today), `inputs` sits at the top level of the workflow. On 9.5+, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference.
+The location of `inputs` in the YAML depends on your version. On 9.4, `inputs` sits at the top level of the workflow. On 9.5+ and serverless, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference.
 
 ::::{applies-switch}
 
-:::{applies-item} { stack: ga 9.4, serverless: ga }
+:::{applies-item} stack: ga 9.4
 ```yaml
 name: shared--enrich-alerts
 description: Enrich alerts with threat intel and geo data.
@@ -79,7 +79,7 @@ steps:
 ```
 :::
 
-:::{applies-item} stack: ga 9.5+
+:::{applies-item} { stack: ga 9.5+, serverless: ga }
 ```yaml
 name: shared--enrich-alerts
 description: Enrich alerts with threat intel and geo data.

explore-analyze/workflows/authoring-techniques/migrate-from-9-3.md

@@ -212,20 +212,19 @@ Beyond the breaking changes, 9.4 adds many capabilities that don't require you t
 - **Expanded AI steps.** `ai.classify` and `ai.summarize` join `ai.prompt` and `ai.agent`. To learn more, refer to [AI steps](/explore-analyze/workflows/steps/ai-steps.md).
 - **Data transformation steps.** 11 `data.*` steps for inline data work: filter, map, aggregate, parse JSON, regex extract, and more. To learn more, refer to [Data action steps](/explore-analyze/workflows/steps/data.md).
 
-## Looking ahead to 9.5: `inputs` schema change [workflows-migrate-inputs-9-5]
+## `inputs` schema change in 9.5 and serverless [workflows-migrate-inputs-9-5]
 
 ```{applies_to}
 stack: ga 9.5+
+serverless: ga
 ```
 
-On 9.5+, `inputs` is defined under the `manual` trigger instead of at the workflow root. The reference form `{{ inputs.<name> }}` is the same in either placement; only the declaration moves.
+On 9.5+ and serverless, `inputs` is defined under the `manual` trigger instead of at the workflow root. The reference form `{{ inputs.<name> }}` is the same in either placement; only the declaration moves.
 
-Existing workflows continue to run on 9.5+ with `inputs` at the root, but new workflows can't be enabled with the root-level form. The {{kib}} editor flags root-level `inputs` as an error on 9.5+ even though the engine still accepts it.
-
-The change is not yet live in serverless.
+Existing workflows continue to run with `inputs` at the root, but new workflows can't be enabled with the root-level form. The {{kib}} editor flags root-level `inputs` as an error even though the engine still accepts it.
 
 ```yaml
-# Old (9.4 — also works on 9.5+ for existing workflows)
+# Old (9.4 — also works on 9.5+ and serverless for existing workflows)
 inputs:
   - name: alert_id
     type: string
@@ -236,7 +235,7 @@ triggers:
 ```
 
 ```yaml
-# New (9.5+)
+# New (9.5+ and serverless)
 triggers:
   - type: manual
     inputs:

explore-analyze/workflows/reference/cheat-sheet.md

@@ -33,7 +33,7 @@ settings: { ... }        # optional
 steps: [ ... ]           # required
 ```
 
-On 9.4 and serverless today, `inputs:` also sits at the workflow root. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for both forms.
+On 9.4, `inputs:` also sits at the workflow root. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for both forms.
 
 ## Triggers [workflows-cheat-triggers]
 

explore-analyze/workflows/reference/context-variables.md

@@ -23,11 +23,11 @@ This page is the canonical reference. For the mental model and the `{{ }}` vs. `
 
 ### `inputs.<name>` [workflows-ctx-inputs]
 
-Values provided at workflow invocation time. The location of the `inputs` block in the YAML depends on your version. On 9.4 and earlier (and on serverless today), `inputs` sits at the top level of the workflow. On 9.5+, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference. The reference form `{{ inputs.<name> }}` is the same in either placement.
+Values provided at workflow invocation time. The location of the `inputs` block in the YAML depends on your version. On 9.4, `inputs` sits at the top level of the workflow. On 9.5+ and serverless, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference. The reference form `{{ inputs.<name> }}` is the same in either placement.
 
 ::::{applies-switch}
 
-:::{applies-item} { stack: ga 9.4, serverless: ga }
+:::{applies-item} stack: ga 9.4
 ```yaml
 inputs:
   - name: service_name
@@ -42,7 +42,7 @@ steps:
 ```
 :::
 
-:::{applies-item} stack: ga 9.5+
+:::{applies-item} { stack: ga 9.5+, serverless: ga }
 ```yaml
 triggers:
   - type: manual

explore-analyze/workflows/steps/composition.md

@@ -152,11 +152,11 @@ If the workflow was invoked by a parent through `workflow.execute`, the parent r
 
 A common pattern: a platform team maintains a set of `shared--<verb>-<noun>` workflows, each with a clean manual trigger and a documented input and output schema. Product teams then compose those shared workflows into their own domain-specific automation.
 
-The location of `inputs` in the YAML depends on your version. On 9.4 and earlier (and on serverless today), `inputs` sits at the top level of the workflow. On 9.5+, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference.
+The location of `inputs` in the YAML depends on your version. On 9.4, `inputs` sits at the top level of the workflow. On 9.5+ and serverless, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference.
 
 ::::{applies-switch}
 
-:::{applies-item} { stack: ga 9.4, serverless: ga }
+:::{applies-item} stack: ga 9.4
 ```yaml
 # Platform team's shared workflow
 name: shared--enrich-alerts
@@ -186,7 +186,7 @@ steps:
 ```
 :::
 
-:::{applies-item} stack: ga 9.5+
+:::{applies-item} { stack: ga 9.5+, serverless: ga }
 ```yaml
 # Platform team's shared workflow
 name: shared--enrich-alerts

explore-analyze/workflows/templating.md

@@ -112,11 +112,11 @@ This section covers common patterns for accessing and transforming data in your
 
 Reference input parameters defined in the workflow using `{{inputs.<input_name>}}`. Inputs are values provided when the workflow is triggered manually.
 
-The location of `inputs` in the YAML depends on your version. On 9.4 and earlier (and on serverless today), `inputs` sits at the top level of the workflow. On 9.5+, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference.
+The location of `inputs` in the YAML depends on your version. On 9.4, `inputs` sits at the top level of the workflow. On 9.5+ and serverless, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference.
 
 ::::{applies-switch}
 
-:::{applies-item} { stack: ga 9.4, serverless: ga }
+:::{applies-item} stack: ga 9.4
 ```yaml
 inputs:
   - name: environment
@@ -141,7 +141,7 @@ steps:
 ```
 :::
 
-:::{applies-item} stack: ga 9.5+
+:::{applies-item} { stack: ga 9.5+, serverless: ga }
 ```yaml
 triggers:
   - type: manual

explore-analyze/workflows/triggers/manual-triggers.md

@@ -37,11 +37,11 @@ Refer to [](/explore-analyze/workflows/authoring-techniques/pass-data-handle-err
 :::
 
 
-The location of `inputs` in the YAML depends on your version. On 9.4 and earlier (and on serverless today), `inputs` sits at the top level of the workflow. On 9.5+, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference.
+The location of `inputs` in the YAML depends on your version. On 9.4, `inputs` sits at the top level of the workflow. On 9.5+ and serverless, `inputs` sits inside the `manual` trigger. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for the full reference.
 
 ::::{applies-switch}
 
-:::{applies-item} { stack: ga 9.4, serverless: ga }
+:::{applies-item} stack: ga 9.4
 ```yaml
 name: Manual Processing Workflow
 inputs:
@@ -78,7 +78,7 @@ steps:
 ```
 :::
 
-:::{applies-item} stack: ga 9.5+
+:::{applies-item} { stack: ga 9.5+, serverless: ga }
 ```yaml
 name: Manual Processing Workflow
 

explore-analyze/workflows/use-cases/security/automate-security-operations/enrich-alert-with-threat-intel.md

@@ -44,7 +44,7 @@ The workflow runs on demand, takes the indicator you want to enrich as an `input
 
 Inputs let you run the workflow against any indicator without editing YAML. Constants hold the API key and base URL.
 
-This example uses the 9.5+ structure, where `inputs` nests under the `manual` trigger. On 9.4 and serverless today, `inputs` sits at the workflow root. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for both forms.
+This example uses the 9.5+ and serverless structure, where `inputs` nests under the `manual` trigger. On 9.4, `inputs` sits at the workflow root. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for both forms.
 
 ```yaml
 consts:

explore-analyze/workflows/use-cases/security/manage-detection-rules/run-rules-on-demand.md

@@ -43,7 +43,7 @@ The workflow runs on demand with a list of rule IDs:
 
 Inputs make the workflow reusable without editing YAML. Declare both the list of rule IDs and the lookback window in minutes.
 
-This example uses the 9.5+ structure, where `inputs` nests under the `manual` trigger. On 9.4 and serverless today, `inputs` sits at the workflow root. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for both forms.
+This example uses the 9.5+ and serverless structure, where `inputs` nests under the `manual` trigger. On 9.4, `inputs` sits at the workflow root. Refer to [Workflow anatomy](/explore-analyze/workflows/authoring-techniques/anatomy.md#workflows-anatomy-inputs) for both forms.
 
 ```yaml
 triggers: