diff --git a/windows/welcome-app-spec.md b/windows/welcome-app-spec.md
index 89660f5..ab2be13 100644
--- a/windows/welcome-app-spec.md
+++ b/windows/welcome-app-spec.md
@@ -36,14 +36,14 @@ Each unit is independently testable: Welcome.Apply can run headless against a fl
 2. **First logon** (auto, as `sm-bootstrap`) → Welcome app launches. Wizard steps:
    - **Welcome** — brand intro.
    - **What's this device for?** — persona → selects a **flavour** (cards: Privacy-Max / Daily-Driver / Journalist / Developer).
-   - **Create your account** — username + password (+ confirm).
+   - **Create your account** — daily username + password (a **Standard User**), plus a separate **device-administrator password** (for the `SilverOS Admin` elevation account).
    - **Secure this device** — set a **BitLocker PIN** (≥ flavour-min).
    - **Preferences** — a few toggles (e.g. telemetry-floor confirmation, browser default, timezone).
    - **Apply** — progress UI while Welcome.Apply runs.
    - **Done** — "restart to finish."
 3. **Apply** (Welcome.Apply, elevated):
    - run the flavour's **hardening modules** (per manifest) + **app-set** install;
-   - **create the real account** (admin) with the entered credentials;
+   - **create the daily Standard account** + the separate **`SilverOS Admin`** account;
    - **enrol BitLocker TPM+PIN** with the entered PIN;
    - remove AutoLogon + the RunOnce.
 4. **Self-destruct + reboot** — delete the `sm-bootstrap` account, then **reboot** into the real account (also activates VBS/Credential Guard, which need a reboot).
@@ -68,11 +68,13 @@ A flavour is a JSON file in `windows/flavours/` baked into the image:
 
 **Welcome.Apply orchestrates the existing PowerShell §A–H modules** per `hardening.modules`/`params` — PowerShell stays the single source of truth for *what hardening does* (also reusable headless for the future silent SKU). *(Rejected alternative: re-implement hardening in a .NET library — cleaner for an all-.NET app but duplicates the proven logic.)* The Shell renders one card per manifest; adding a flavour = adding a JSON file.
 
-**Starter flavours (v1):** Privacy-Max, Daily-Driver, Journalist, Developer — differing in hardening strictness (e.g. WDAC enforce vs audit, relaxed dev tooling) and app set.
+**Hardened baseline applies to ALL flavours** — no flavour is unhardened. Every flavour runs the core §A–H baseline (telemetry floor, BitLocker+PIN, VBS/HVCI, firewall default-deny, Defender/ASR, etc.); flavours only **tune strictness above that baseline** and choose the app set. There is no "off."
+
+**Starter flavours (v1):** **Daily-Driver** *(the **default / recommended** — balanced: full baseline, WDAC in audit, everyday app set)*, **Privacy-Max** *(strictest: WDAC enforce, tightest toggles, removable-storage controls — opt-in, not default)*, **Journalist** *(privacy + duress/comms emphasis)*, **Developer** *(baseline + dev tooling allowances, e.g. WDAC audit + dev-signed allowances)*. The wizard pre-selects **Daily-Driver**.
 
 ## 5. Account & BitLocker integration
 
-- The **real account** is created as a local **Administrator** (personal-device owner). *(Standard-user/least-privilege as a flavour option is a later enhancement — persona was chosen as the role axis, not privilege.)*
+- The user's **daily account is a Standard User** (least-privilege by default — a real hardening win, and the SilverLABS default). Elevation uses a **separate local Administrator account** (`SilverOS Admin`) created alongside it; the user sets the admin password in the account step (distinct from their daily password). *(Single-admin/"personal-device owner" remains available as a flavour/pref option, but is not the default.)*
 - **BitLocker TPM+PIN** is enrolled with the user's PIN during Apply (`Enable-BitLocker -TpmAndPinProtector`), satisfying module C's interactive step. Recovery key stored offline / shown to the user (never cloud-escrowed) per `hardening-spec.md` §C.
 - The **bootstrap account** is admin only so the app can run hardening + manage accounts; it is deleted in step 4 so no standing extra admin remains.
 
@@ -99,11 +101,11 @@ A flavour is a JSON file in `windows/flavours/` baked into the image:
 - **SilverDESK / fleet enrollment** role.
 - **Shared flavour model with the Linux line.**
 - **Real Stack app installs** — the app-set installer is wired, but Stack entries remain stubs until native Windows Stack builds exist (M4).
-- **Standard-user/least-privilege** real account option.
+- **Single-admin / "personal-device owner"** account model as a selectable option (Standard-user daily + separate admin is the v1 default).
 
 ## 9. Open questions / risks
 
 - **WebView2 + .NET runtime in the image** — confirm WebView2 Evergreen is present on IoT Enterprise LTSC (or bundle the fixed-version runtime); self-contained publish covers .NET.
 - **Kiosk lock-down of the bootstrap session** — ensure the user can't escape the wizard to a privileged shell before the real account exists.
 - **Apply failure handling** — if a module fails mid-apply, the wizard must surface it and leave the device in a recoverable state (don't delete bootstrap until apply + account creation succeed).
-- **Naming** — "SilverOS Welcome" vs "SilverMetal Welcome" (the program is SilverMetal; "SilverOS" is the floated umbrella). Cosmetic; decide before first release.
+- **Admin-credential UX** — confirm the daily/admin two-password step is clear (vs. generating + showing the admin secret once); ensure password strength rules on both.