website/docs: address review feedback for stages cleanup

Co-authored-by: Codex <codex@openai.com>

website/docs/add-secure-apps/flows-stages/stages/authenticator_totp/index.md

@@ -2,7 +2,7 @@
 title: TOTP authenticator setup stage
 ---
 
-The TOTP Authenticator Setup stage enrolls a time-based one-time password device for the user, such as Google Authenticator, Authy, 1Password, or similar authenticator apps.
+The TOTP Authenticator Setup stage enrolls a time-based one-time password authenticator for the user, such as Google Authenticator, Authy, 1Password, or similar authenticator apps.
 
 ## Overview
 
@@ -18,9 +18,9 @@ The enrolled TOTP authenticator can then be used with the [Authenticator Validat
 
 ## Flow integration
 
-Use this stage in an enrollment or user-settings flow where the user can add a TOTP device.
+Use this stage in an enrollment or user-settings flow where the user can add a TOTP authenticator.
 
-To require that device during login, add an [Authenticator Validation stage](../authenticator_validate/index.md) to the authentication flow and allow the **TOTP** device class.
+To require that authenticator during login, add an [Authenticator Validation stage](../authenticator_validate/index.md) to the authentication flow and allow the **TOTP** device class.
 
 ## Notes
 

website/docs/add-secure-apps/flows-stages/stages/authenticator_validate/index.md

@@ -82,9 +82,9 @@ If you select multiple **Configuration stages** on a single validation stage, us
 
 ### Less-frequent validation
 
-Set **Last validation threshold** to a non-zero value to avoid prompting on every login. Any compatible device within the allowed classes can satisfy that threshold.
+Set **Last validation threshold** to a non-zero value to avoid prompting on every login. Any compatible authenticator within the allowed classes can satisfy that threshold.
 
-For code-based devices such as TOTP, Static, and SMS, values below `seconds=30` are not useful because those devices do not store exact validation timestamps at sub-window precision.
+For code-based authenticators such as TOTP, Static, and SMS, values below `seconds=30` are not useful because those authenticators do not store exact validation timestamps at sub-window precision.
 
 ### Passwordless authentication
 
@@ -92,7 +92,7 @@ For code-based devices such as TOTP, Static, and SMS, values below `seconds=30`
 Firefox has known issues with some Touch ID and platform-authenticator flows. See Mozilla bug `1536482` for one longstanding example.
 :::
 
-Passwordless authentication in this stage currently relies on **WebAuthn** devices.
+Passwordless authentication in this stage currently relies on **WebAuthn** authenticators.
 
 To build a dedicated passwordless flow:
 

website/docs/add-secure-apps/flows-stages/stages/identification/index.md

@@ -84,7 +84,7 @@ authentik automatically falls back to the normal identification flow when passke
 
 1. Create or edit an [Authenticator Validation stage](../authenticator_validate/index.md) that allows the **WebAuthn** device class.
 2. Set the Identification stage's **WebAuthn Authenticator Validation stage** to that stage.
-3. Make sure users have already enrolled a WebAuthn device, for example with the [WebAuthn / FIDO2 / Passkeys Authenticator setup stage](../authenticator_webauthn/index.md).
+3. Make sure users have already enrolled a WebAuthn authenticator, for example with the [WebAuthn / FIDO2 / Passkeys Authenticator setup stage](../authenticator_webauthn/index.md).
 
 If the user has multiple passkeys, the browser shows its own picker. In the default authentication flow, authentik skips the MFA validation stage after a passkey login with an expression policy; adjust that policy if you still want a second factor after passkey login.
 
@@ -92,4 +92,4 @@ If the user has multiple passkeys, the browser shows its own picker. In the defa
 
 - If no passkey prompt appears, check HTTPS, browser support, and that the validation stage is configured. The browser normally triggers the passkey suggestion when the user focuses the username field.
 - If no passkey prompt appears, make sure the login page is not embedded in an iframe because some browsers block conditional UI outside top-level browsing contexts.
-- If the prompt appears but falls back to username/password, check that the referenced validation stage allows WebAuthn and that the user has a valid enrolled device.
+- If the prompt appears but falls back to username/password, check that the referenced validation stage allows WebAuthn and that the user has a valid enrolled authenticator.

website/docs/add-secure-apps/flows-stages/stages/password/index.md

@@ -23,7 +23,7 @@ The stage supports authentik's built-in password database, app passwords, LDAP-b
 
 ## Flow integration
 
-This stage is typically bound after [Identification](../identification/index.md) and before [Authenticator Validation](../authenticator_validate/index.md) or [User Login](../user_login/index.md).
+This stage is typically bound after an [Identification](../identification/index.md) stage and before a [Authenticator Validation](../authenticator_validate/index.md) or [User Login](../user_login/index.md) stage.
 
 If the [Identification stage](../identification/index.md) has its **Password stage** option set, the password prompt is rendered as part of the identification step and the Password stage should not also be bound separately in the same flow.
 
@@ -37,7 +37,7 @@ Service accounts have automatically generated app passwords. Those can be viewed
 
 There are two common ways to avoid prompting for a password:
 
-- Use [Authenticator Validation](../authenticator_validate/index.md#passwordless-authentication) with WebAuthn for a dedicated passwordless flow.
+- Use an [Authenticator Validation](../authenticator_validate/index.md#passwordless-authentication) stage with WebAuthn for a dedicated passwordless flow.
 - Conditionally skip the Password stage by binding a policy to its stage binding.
 
 If you want users to be able to pick a passkey from the browser's passkey/autofill UI without entering a username first, configure **Passkey autofill (WebAuthn conditional UI)** in the [Identification stage](../identification/index.md#passkey-autofill-webauthn-conditional-ui). This is separate from configuring a dedicated passwordless flow, and can be used alongside normal identification flows.

website/docs/add-secure-apps/flows-stages/stages/prompt/index.md

@@ -68,11 +68,11 @@ Some field types also have special behavior:
 
 Use this stage anywhere a flow needs user-provided input.
 
-Common follow-up stages include:
+Common follow-ups include:
 
-- [User Write](../user_write/index.md) to persist collected values
-- [Email](../email/index.md) or [Invitation](../invitation/index.md) to act on collected data
-- policy checks that read from `request.context["prompt_data"]`
+- A [User Write](../user_write/index.md) stage to persist collected values
+- An [Email](../email/index.md) or [Invitation](../invitation/index.md) stage to act on collected data
+- Policy checks that read from `request.context["prompt_data"]`
 
 ## Notes
 

website/docs/add-secure-apps/flows-stages/stages/user_delete/index.md

@@ -14,7 +14,7 @@ This stage has no stage-specific configuration options.
 
 ## Flow integration
 
-Use this stage near the end of an unenrollment flow after any confirmation, re-authentication, or policy checks have already happened.
+Use this stage near the end of an unenrollment flow after any confirmation, re-authentication, or policy checks have occurred.
 
 ## Notes
 

website/docs/add-secure-apps/flows-stages/stages/user_login/index.md

@@ -24,8 +24,8 @@ Use this stage near the end of flows that should create an authenticated browser
 
 Common placements include:
 
-- after [Password](../password/index.md) or [Authenticator Validation](../authenticator_validate/index.md) in authentication flows
-- after [User Write](../user_write/index.md) in enrollment flows
+- after a [Password](../password/index.md) or [Authenticator Validation](../authenticator_validate/index.md) stage in authentication flows
+- after a [User Write](../user_write/index.md) stage in enrollment flows
 
 ## Notes
 
@@ -47,7 +47,7 @@ Valid keys in those duration strings include:
 - days
 - weeks
 
-- If **Remember me offset** is greater than `seconds=0`, authentik shows the user a remember-me choice during login.
+- If **Remember me offset** is greater than `seconds=0`, authentik shows the user a **Remember me on this device** option during login.
 
 ![](./stay_signed_in.png)
 
@@ -94,7 +94,7 @@ When a session is terminated because a binding is broken, the generated logout e
 }
 ```
 
-For alerting and policy use, authentik can also classify a login as coming from a known or unknown device based on the remember-device cookie and related session information.
+For alerting and policy use, authentik can also classify a login as coming from a known or unknown device based on the "Remember me on this device" cookie and related session information.
 
 See the notification policy examples for [logins from unknown devices](../../../../sys-mgmt/events/notification_rule_expression_policies.mdx#trigger-alert-when-user-logs-in-from-unknown-device).
 

website/docs/add-secure-apps/flows-stages/stages/user_logout/index.md

@@ -29,4 +29,4 @@ When this stage runs, authentik can inject additional logout stages for active p
 - front-channel native logout stages
 - back-channel logout execution
 
-This lets provider-specific logout happen automatically without manually adding those stages to the flow.
+This enables automatic provider-specific logout without manually adding those stages to the flow.

website/docs/add-secure-apps/flows-stages/stages/user_write/index.md

@@ -13,16 +13,16 @@ It is commonly used in enrollment, recovery, and profile-update flows after a [P
 ## Configuration options
 
 - **User creation mode**: control whether the stage never creates users, creates them only when required, or always creates them.
-- **Create users as inactive**: mark newly created users inactive.
+- **Create users as inactive**: mark newly created users as inactive.
 - **Create users group**: optionally add newly created users to a specific group.
-- **User type**: select the user type applied to newly created users.
-- **User path template**: optional template used to place newly created users into a path.
+- **User type**: select the user type for newly created users: Internal, External, or Service Account.
+- **User path template**: optionally set the path new users will be created under. If left blank, the default path will be used.
 
 ## Flow integration
 
-Use this stage after one or more stages that populate flow context, usually a [Prompt stage](../prompt/index.md), [Identification stage](../identification/index.md), or [Email stage](../email/index.md).
+Use this stage after one or more stages that populate flow context, usually a [Identification stage](../identification/index.md), [Prompt stage](../prompt/index.md), or [Email stage](../email/index.md).
 
-In enrollment flows, this stage is often followed by [User Login](../user_login/index.md) so the newly created user is signed in immediately.
+In enrollment flows, this stage is often followed by a [User Login](../user_login/index.md) stage so the newly created user is immediately signed in.
 
 ## Notes
 

website/docs/users-sources/user/user_basic_operations.md

@@ -21,7 +21,7 @@ The following topics are for the basic management of users: how to create, modif
 5. Fill the **_optional_** fields if needed:
 
 - **Name**: The display name of the user.
-- **Email**: The email address of the user. Email addresses are used in [email stages](../../add-secure-apps/flows-stages/stages/email/index.md) and to receive [notifications](../../sys-mgmt/events/notifications.md), if configured.
+- **Email**: The email address of the user. Email addresses are used in [email stages](../../add-secure-apps/flows-stages/stages/email/index.md) and, if configured, to receive [notifications](../../sys-mgmt/events/notifications.md).
 - **Is active**: Define if the newly created user account is active. Selected by default.
 - **Attributes**: Custom attributes definition for the user, in YAML or JSON format. These attributes can be used to enforce additional prompts on authentication stages or define conditions to enforce specific policies if the current implementation does not fit your use case. The value is an empty dictionary by default.