diff --git a/docs/src/content/docs/enterprise/lifecycle-scripts.md b/docs/src/content/docs/enterprise/lifecycle-scripts.md
index 5427f9188..fdb1a7220 100644
--- a/docs/src/content/docs/enterprise/lifecycle-scripts.md
+++ b/docs/src/content/docs/enterprise/lifecycle-scripts.md
@@ -30,8 +30,8 @@ and can delay the operation until they finish or their timeout elapses.
 Scripts are defined in three tiers. The **project tier** uses the repository `apm.yml`
 manifest under a top-level `lifecycle:` key. The **user tier** uses
 `~/.apm/apm.yml` (or `$APM_HOME/apm.yml`) under the same `lifecycle:` key.
-The **admin** tier uses `/etc/apm/policy.d/*.json` on POSIX systems, or
-`C:\ProgramData\APM\policy.d\*.json` on Windows. It is suited for
+The **admin** tier uses `/etc/apm/policy.d/*.json` on Linux and macOS,
+or `C:\ProgramData\APM\policy.d\*.json` on Windows. It is suited for
 machine- and fleet-managed deployment.
 
 ## Supported events
@@ -49,9 +49,9 @@ machine- and fleet-managed deployment.
 
 Project and user manifests embed lifecycle scripts under a top-level
 `lifecycle:` key in `apm.yml`. The admin tier keeps the versioned JSON
-`{version: 1, scripts: {...}}` wrapper in the platform-specific policy
-directory shown below. All entries share the same field names and `type`
-discriminator.
+`{version: 1, scripts: {...}}` wrapper in `/etc/apm/policy.d/*.json`
+(or `C:\ProgramData\APM\policy.d\*.json` on Windows). All
+entries share the same field names and `type` discriminator.
 
 Each entry declares its kind via `type: command` (shell subprocess) or
 `type: http` (HTTPS webhook). An optional `description` field documents
@@ -168,7 +168,7 @@ disabled; the global kill switches below suppress all lifecycle scripts.
 
 | Priority     | Path                                                                        | Who controls     | Format |
 |--------------|-----------------------------------------------------------------------------|------------------|--------|
-| 1 (highest)  | POSIX: `/etc/apm/policy.d/*.json`<br />Windows: `C:\ProgramData\APM\policy.d\*.json` | Platform/IT team | JSON   |
+| 1 (highest)  | Linux/macOS: `/etc/apm/policy.d/*.json`<br />Windows: `C:\ProgramData\APM\policy.d\*.json` | Platform/IT team | JSON   |
 | 2            | `~/.apm/apm.yml`                                                           | Individual user  | YAML   |
 | 3            | `apm.yml` `lifecycle:`                                                     | Project          | YAML   |
 
@@ -198,8 +198,7 @@ POST body.
 
 Lifecycle scripts from different sources are subject to different trust rules:
 
-- **Policy scripts** (`/etc/apm/policy.d/*.json` on POSIX systems or
-  `C:\ProgramData\APM\policy.d\*.json` on Windows) -- controlled by
+- **Policy scripts** (`/etc/apm/policy.d/*.json` on Linux/macOS, `C:\ProgramData\APM\policy.d\*.json` on Windows) -- controlled by
   your platform/IT team. Run without any consent gate; they cannot be
   individually disabled by the developer. `APM_NO_SCRIPTS=1` suppresses
   all lifecycle-script tiers for that run.
@@ -231,10 +230,8 @@ The canonical use case for lifecycle scripts is installation analytics.
 An enterprise platform team can deploy an org-wide webhook via the
 policy directory to track which packages are actively used:
 
-Create `analytics.json` in the platform admin directory:
-
-- POSIX: `/etc/apm/policy.d/analytics.json`
-- Windows: `C:\ProgramData\APM\policy.d\analytics.json`
+Create `/etc/apm/policy.d/analytics.json` on Linux or macOS, or
+`C:\ProgramData\APM\policy.d\analytics.json` on Windows:
 
 ```json
 {