@uipath/skills 1.199.0 → 1.200.0

package/skills/uipath-functions/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: uipath-functions
-description: "UiPath Coded Functions — deterministic Python units built via `uip functions` (new/init/run/pack/publish); the `functions` map in `uipath.json`, `entry-points.json`, Pydantic Input/Output. Rule-based logic, data transforms, ERP/Integration Service connector calls — no LLM reasoning or agent loop. For LLM/agentic projects (LangGraph, LlamaIndex, OpenAI Agents, `agent.json`)→uipath-agents."
+description: "UiPath Coded Functions — deterministic Python units built via `uip function` (new/init/run/pack/publish); the `functions` map in `uipath.json`, `entry-points.json`, Pydantic Input/Output. Rule-based logic, data transforms, ERP/Integration Service connector calls — no LLM reasoning or agent loop. For LLM/agentic projects (LangGraph, LlamaIndex, OpenAI Agents, `agent.json`)→uipath-agents."
 allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion
 ---
 
@@ -23,7 +23,7 @@ A Python Coded Function can be invoked from any UiPath surface:
 | Coded Agents (LangGraph / LlamaIndex / OpenAI Agents) | Called as a tool or step |
 | Other Coded Functions | Direct Python call or Orchestrator job |
 | Orchestrator API | `POST /Jobs/StartJobs` |
-| CLI | `uip functions pack` → `uip functions publish` |
+| CLI | `uip function pack` → `uip function publish` |
 
 ### Python Functions vs JS Functions
 
@@ -33,9 +33,9 @@ A Python Coded Function can be invoked from any UiPath surface:
 | **Invocation** | Maestro, Flow, Agents, Orchestrator API | HTTP endpoint (BFF for Coded Apps) |
 | **Runtime** | Serverless or Local Unattended Robot | Serverless HTTP shared tier |
 | **SDK access** | Full UiPath Python SDK (assets, buckets, queues, connections) | Workload token forwarding only |
-| **Scaffold** | `uip functions new <name> --language py` | `uip functions new <name> --language ts` (default) |
-| **Init** | `uip functions init` (generates entry-points.json) | Not needed |
-| **Local dev** | `uip functions run` | `uip functions serve` + `uip functions run` |
+| **Scaffold** | `uip function new <name> --language py` | `uip function new <name> --language ts` (default) |
+| **Init** | `uip function init` (generates entry-points.json) | Not needed |
+| **Local dev** | `uip function run` | `uip function serve` + `uip function run` |
 | **Best for** | Agentic process steps, ERP integration, document AI, data pipelines | Backend-for-Frontend for Coded Apps |
 
 Use Python when the logic needs job semantics, platform SDK access, or is invoked from Maestro/agents. Use JS when the caller is a Coded App frontend and low HTTP latency matters.
@@ -44,17 +44,17 @@ Use Python when the logic needs job semantics, platform SDK access, or is invoke
 
 ## CLI Reference
 
-All Python Coded Function lifecycle commands use `uip functions`:
+All Python Coded Function lifecycle commands use `uip function`:
 
 ```bash
-uip functions new <name> -l py     # scaffold a new Python Functions project (--language py required)
-uip functions init                 # Python only — generate entry-points.json, bindings.json, project.uiproj
-uip functions pack                 # pack to .nupkg for deployment
-uip functions publish              # upload .nupkg to Orchestrator (prompts for feed, or use --feed-id)
-uip functions push                 # sync project to Studio Web
+uip function new <name> -l py     # scaffold a new Python Functions project (--language py required)
+uip function init                 # Python only — generate entry-points.json, bindings.json, project.uiproj
+uip function pack                 # pack to .nupkg for deployment
+uip function publish              # upload .nupkg to Orchestrator (prompts for feed, or use --feed-id)
+uip function push                 # sync project to Studio Web
 ```
 
-> `uip functions run` works for both Python and JS/TS. `uip functions serve` is **JS/TS only** — it starts the local HTTP server that `run` invokes against.
+> `uip function run` works for both Python and JS/TS. `uip function serve` is **JS/TS only** — it starts the local HTTP server that `run` invokes against.
 
 ---
 
@@ -63,9 +63,9 @@ uip functions push                 # sync project to Studio Web
 ### Step 1: Scaffold
 
 ```bash
-uip functions new <name> --language py       # Python Coded Function
-uip functions new <name> --language ts       # TypeScript Function (JS/TS, no job semantics)
-uip functions new <name> --language js       # JavaScript Function (JS/TS, no job semantics)
+uip function new <name> --language py       # Python Coded Function
+uip function new <name> --language ts       # TypeScript Function (JS/TS, no job semantics)
+uip function new <name> --language js       # JavaScript Function (JS/TS, no job semantics)
 ```
 
 **`--language py` is required for Python.** The default language is TypeScript — omitting `--language` scaffolds a JS/TS project. Always pass `-l py` or `--language py` when building a Python Coded Function.
@@ -174,7 +174,7 @@ No `[build-system]` section. The project is identified as a Coded Function by th
 ### Step 6: Generate Entry Points
 
 ```bash
-uip functions init
+uip function init
 ```
 
 Python only. Discovers entrypoints and generates `entry-points.json`, `bindings.json`, and `project.uiproj`. Must run before `pack` or `push`. Re-run whenever Input/Output schemas or the entrypoint registration in `uipath.json` changes.
@@ -226,28 +226,28 @@ class Input(BaseModel):
     attachment: Attachment
 ```
 
-`uip functions init` recognizes the `Attachment` type and emits `x-uipath-resource-kind: JobAttachment` in `entry-points.json` — the schema Studio Web and Orchestrator read to render a file picker for that field. Access fields snake_case: `attachment.full_name`, `attachment.content`.
+`uip function init` recognizes the `Attachment` type and emits `x-uipath-resource-kind: JobAttachment` in `entry-points.json` — the schema Studio Web and Orchestrator read to render a file picker for that field. Access fields snake_case: `attachment.full_name`, `attachment.content`.
 
 ### Step 8: Pack and Publish
 
 ```bash
-uip functions pack                            # creates .nupkg
-uip functions publish                         # upload to Orchestrator (interactive feed picker)
-uip functions publish --feed-id <FEED_ID>     # CI/non-interactive
+uip function pack                            # creates .nupkg
+uip function publish                         # upload to Orchestrator (interactive feed picker)
+uip function publish --feed-id <FEED_ID>     # CI/non-interactive
 ```
 
 To sync to Studio Web instead of publishing to Orchestrator:
 
 ```bash
-uip functions push
+uip function push
 ```
 
 ## Important Notes
 
 - `UiPath()` must never be instantiated at module level — always inside a function body
 - The `functions` map in `uipath.json` marks the project as a Coded Function (`determine_project_type()` reads the entrypoint type from `uipath.json`)
-- `uip functions init` must run before `pack` or `push` — it generates `entry-points.json`
+- `uip function init` must run before `pack` or `push` — it generates `entry-points.json`
 - Python Functions have full job semantics: Orchestrator job ID, audit trail, retry, scheduling
 - JS Functions have no job semantics and cannot be started as Orchestrator jobs — use Python when the caller is Maestro, a Flow, or an agent
-- `uip functions run` works for both Python and JS/TS local execution; `uip functions serve` is JS/TS only (starts the local HTTP server that `run` invokes against)
+- `uip function run` works for both Python and JS/TS local execution; `uip function serve` is JS/TS only (starts the local HTTP server that `run` invokes against)
 - If cloud-backed work requires authentication, run `uip login --organization "<ORG>" --tenant "<TENANT>" --output json`.

package/skills/uipath-governance/SKILL.md

@@ -50,7 +50,7 @@ Activate on **any** governance / policy / rule intent — even when the user did
 2. **Classification lives at the top.** Mechanic libraries assume the branch is chosen. Do not let those flows ask "did you mean the other branch?" — that question belongs here.
 3. **One branch per mutation.** A single user request produces a policy on one branch only. If the user wants both, run two sequential flows with two confirmation gates.
 4. **Each mechanic owns its own Critical Rules.** Once routed, follow the branch's rules — do not relax them from this top level.
-5. **Never apply compliance settings without posture analysis + user confirmation.** Run posture analysis first, show the plan (summary + detail), require `y` before any settings are configured.
+5. **Never apply, restore, or remove compliance settings without user confirmation.** For apply: run posture analysis first, show the plan (summary + detail). In every case: ask, then END YOUR REPLY — never run the mutating command in the same response as the confirmation question. Proceed only on an explicit `y` in the user's next message. The user's original request is intent, not consent. Sole exception: the user explicitly waived confirmation in advance (e.g., "don't ask for confirmation") — treat the waiver as `y`.
 6. **Always show a receipt after any apply.** Present the post-apply report (settings configured, manual steps needed, Applied by / date) so the user has a record. No local file write is needed — the CLI and UiPath platform are the source of truth.
 7. **Compliance Standards is a preview feature — gate every compliance-pack flow.** Append the preview disclaimer to user-facing compliance-standard responses, and on any `uip gov compliance-packs …` call returning **HTTP 403 / Forbidden**, stop immediately (do not retry, run no further compliance commands) and tell the user the feature requires enrolling in the preview program. Exact wording + placement in [`references/compliance-pack/preview-gate.md`](./references/compliance-pack/preview-gate.md). A **403** is preview-not-enabled; a **401** is a normal login failure — do NOT conflate them.
 8. **Always `uip login` before any `uip gov …` command.** `evaluate` (Access) additionally requires tenant-scoped login — see [`access-policy-overview-guide.md` § Critical Rules](./references/access-policy/access-policy-overview-guide.md#critical-rules).
@@ -58,7 +58,7 @@ Activate on **any** governance / policy / rule intent — even when the user did
 
 ## Workflow
 
-1. **Classify the intent silently — never announce routing to the user.** Internal flow labels (AOps / Access / Compliance standard) are implementation details; the user sees only the outcome. Read [`references/disambiguation-guide.md`](./references/disambiguation-guide.md) — it lists the strong signals for each flow, the phrase patterns that need disambiguation, and the canonical worked example. If a strong signal matches, route silently. If the phrasing is ambiguous (matches AOps or Access), ask the [disambiguation question](#disambiguation-question) and wait for a digit reply. If the user replies with anything other than `1` or `2`, treat it as a re-statement of intent and re-classify. **Do not run any CLI command before classification is settled** — the disambiguation question itself does not need `uip`, and an unrelated request (platform ops, agent authoring) must redirect to a sibling skill before any setup happens here. If the request contains a standard name (`ISO 42001`), `apply standard`, `compliance posture`, `drift check`, `am I compliant`, `is my tenant compliant`, `what packs are available`, `what packs are configured`, `which standards are enabled`, `organization-wide`, or `disable standard` → route silently to the appropriate compliance standard plugin. Read `partial-apply/planning.md` for scoped requests; `coverage/impl.md` for posture checks; `catalog/impl.md` for discovery; `query/impl.md` for information queries; `full-apply/impl.md` after confirming the posture plan; `disable/impl.md` for removal; `catalog/impl.md` + `state list` for listing currently configured packs.
+1. **Classify the intent silently — never announce routing to the user.** Internal flow labels (AOps / Access / Compliance standard) are implementation details; the user sees only the outcome. Read [`references/disambiguation-guide.md`](./references/disambiguation-guide.md) — it lists the strong signals for each flow, the phrase patterns that need disambiguation, and the canonical worked example. If a strong signal matches, route silently. If the phrasing is ambiguous (matches AOps or Access), ask the [disambiguation question](#disambiguation-question) and wait for a digit reply. If the user replies with anything other than `1` or `2`, treat it as a re-statement of intent and re-classify. **Do not run any CLI command before classification is settled** — the disambiguation question itself does not need `uip`, and an unrelated request (platform ops, agent authoring) must redirect to a sibling skill before any setup happens here. If the request contains a standard name (`ISO 42001`), `apply standard`, `compliance posture`, `drift check`, `am I compliant`, `is my tenant compliant`, `what packs are available`, `what packs are configured`, `which standards are enabled`, `organization-wide`, `disable standard`, or `reset` / `restore` / `undo drift on a standard` → route silently to the appropriate compliance standard plugin. Read `partial-apply/planning.md` for scoped requests; `coverage/impl.md` for posture checks; `catalog/impl.md` for discovery; `query/impl.md` for information queries; `full-apply/impl.md` after confirming the posture plan; `disable/impl.md` for removal; `restore/impl.md` for resetting a configured standard back to its recommended settings; `catalog/impl.md` + `state list` for listing currently configured packs.
 2. **Verify `uip` and login** *(only after classification routes to a governance flow).*
    ```bash
    which uip && uip --version
@@ -69,7 +69,7 @@ Activate on **any** governance / policy / rule intent — even when the user did
 3. **Route to the chosen mechanic** and follow its flow end-to-end.
    - AOps product policy → [`references/aops-policy/aops-policy-overview-guide.md`](./references/aops-policy/aops-policy-overview-guide.md)
    - Access ToolUsePolicy → [`references/access-policy/access-policy-overview-guide.md`](./references/access-policy/access-policy-overview-guide.md)
-   - Compliance standard → use plugin routing from step 1 above (catalog / coverage / full-apply / partial-apply / disable / query)
+   - Compliance standard → use plugin routing from step 1 above (catalog / coverage / full-apply / partial-apply / disable / restore / query)
 
 ## Disambiguation Question
 
@@ -107,7 +107,8 @@ The canonical ambiguous prompt is *"Block ChatGPT for my finance team using Stud
 | **Apply full compliance pack** | Run coverage first, then [`references/compliance-pack/full-apply/impl.md`](./references/compliance-pack/full-apply/impl.md) |
 | **Apply specific controls / clauses** | [`references/compliance-pack/partial-apply/planning.md`](./references/compliance-pack/partial-apply/planning.md) |
 | **Remove compliance standard settings** | [`references/compliance-pack/disable/impl.md`](./references/compliance-pack/disable/impl.md) |
-| **Query — what does a clause / control recommend?** | [`references/compliance-pack/query/impl.md`](./references/compliance-pack/query/impl.md) |
+| **Reset / restore a standard to its recommended settings (undo drift)** | [`references/compliance-pack/restore/impl.md`](./references/compliance-pack/restore/impl.md) |
+| **Query — what does a clause / control recommend?** | `uip gov compliance-packs catalog get <packId> --output json` (e.g. `iso-42001-2023`), then [`references/compliance-pack/query/impl.md`](./references/compliance-pack/query/impl.md) |
 | **Preview disclaimer + 403 opt-in gate (all compliance flows)** | [`references/compliance-pack/preview-gate.md`](./references/compliance-pack/preview-gate.md) |
 
 ## Anti-patterns

package/skills/uipath-governance/references/cli-cheatsheet.md

@@ -186,7 +186,7 @@ All halts write a deploy record (Apply) or patch record (Diagnose).
 uip gov compliance-packs catalog list --output json
 uip gov compliance-packs catalog get <packId> --output json
 
-# State (tenant-scoped; Policy:Read for coverage/get/list; Policy:Write for enable/disable)
+# State (tenant-scoped; Policy:Read for coverage/get/list; Policy:Write for enable/disable/restore)
 TENANT_ID=$(grep '^UIPATH_TENANT_ID=' ~/.uipath/.auth | cut -d'=' -f2-)
 ORG_ID=$(grep '^UIPATH_ORGANIZATION_ID=' ~/.uipath/.auth | cut -d'=' -f2-)
 
@@ -194,6 +194,7 @@ ORG_ID=$(grep '^UIPATH_ORGANIZATION_ID=' ~/.uipath/.auth | cut -d'=' -f2-)
 uip gov compliance-packs state coverage tenant $TENANT_ID <packId> --output json
 uip gov compliance-packs state enable  tenant $TENANT_ID <packId> --output json
 uip gov compliance-packs state disable tenant $TENANT_ID <packId> --output json
+uip gov compliance-packs state restore tenant $TENANT_ID <packId> --output json  # overwrites live policies — confirm with user first (restore/impl.md)
 uip gov compliance-packs state get    tenant $TENANT_ID <packId> --output json
 uip gov compliance-packs state list   tenant $TENANT_ID          --output json
 

package/skills/uipath-governance/references/compliance-pack/coverage/impl.md

@@ -6,7 +6,7 @@ Compares the compliance standard's recommended settings against what is currentl
 
 ## Command
 
-**Pre-condition:** `$SESSION_TEMP/catalog.json` must exist — run `catalog get` first (see `catalog/impl.md`). Coverage joins with catalog data to display meaningful setting names.
+**Pre-condition:** `$SESSION_TEMP/catalog.json` must exist — run `catalog get` first (see `catalog/impl.md`). The coverage response does NOT carry display names for clauses (`ClauseName` comes back null) — the plain-English clause names the template requires come from joining coverage `Clauses[].ClauseId` to catalog `Clauses[].ClauseId` → `ClauseName` in `catalog.json`.
 
 ```bash
 # Read the session dir written by catalog get — never create a new one here.
@@ -14,6 +14,14 @@ SESSION_TEMP=$(cat "$HOME/.uipath-compliance-current-session")
 TENANT_ID=$(grep '^UIPATH_TENANT_ID=' ~/.uipath/.auth | cut -d'=' -f2-)
 uip gov compliance-packs state coverage tenant $TENANT_ID <packId> --output json \
   > "$SESSION_TEMP/coverage.json"
+
+# Whether the pack is APPLIED is a separate question from what is covered.
+# Coverage cannot answer it (it runs pack-on or pack-off) — this can.
+# A known pack that was never applied returns 200 with Active: false.
+# A 404 means the packId itself is not usable (unknown, or a catalog stub
+# with no bundle) — NOT "not applied"; check it against catalog list.
+uip gov compliance-packs state get tenant $TENANT_ID <packId> --output json \
+  > "$SESSION_TEMP/state.json"
 ```
 
 ```powershell
@@ -22,81 +30,125 @@ $tmpDir = (Get-Content "$env:TEMP\uipath-compliance-current-session.txt" -Raw).T
 $tenantId = (Select-String '^UIPATH_TENANT_ID=(.+)' "$env:USERPROFILE\.uipath\.auth").Matches[0].Groups[1].Value
 uip gov compliance-packs state coverage tenant $tenantId <packId> --output json |
   Set-Content "$tmpDir\coverage.json"
+
+# Applied-or-not is a separate question — coverage cannot answer it.
+uip gov compliance-packs state get tenant $tenantId <packId> --output json |
+  Set-Content "$tmpDir\state.json"
 ```
 
 ## Parse the response
 
 CLI output is **PascalCase**. Field names below are exactly as returned by `state coverage`.
 
-`Data.DeploymentPolicies[].Status` (product-grain; INTERNAL — never rendered to the user, never projected onto settings). Three disjoint values:
-- `"in-place"` — product fully satisfied · `"needs-manual-config"` — deployed but ≥1 control still needs manual setup · `"new"` — nothing deployed for this product
-- INTERNAL only; the user-facing posture is driven entirely by clauses + per-setting `controls[]`. Do NOT gate the all-applied case on `Summary.NewCount == 0` — with the disjoint counts a `needs-manual-config` product leaves `NewCount == 0` yet the pack is not fully applied.
+`Data.DeploymentPolicies[].Status` (product-grain; INTERNAL — never rendered to the user, never projected onto settings). Four disjoint values:
+- `"in-place"` — product fully satisfied · `"needs-manual-config"` — deployed but ≥1 control still needs manual setup · `"unverifiable"` — pack active but the product's policy is missing (deleted out-of-band), so nothing can be checked · `"new"` — none of the standard's settings are in place for this product
+- `"new"` does NOT mean "no policy". A product lands in `NewCount` either because nothing was ever deployed OR because a live policy has had **every** one of its controls changed away from the standard. In the second case the policy still exists, `PolicyId` is present, and `DriftedControls[]` is populated — the remedy is `restore`, not apply.
+- INTERNAL only; the user-facing posture is driven entirely by clauses + per-setting `Controls[]`. Do NOT gate the all-applied case on `Summary.NewCount == 0` — with the disjoint counts a `needs-manual-config` product leaves `NewCount == 0` yet the pack is not fully applied.
+- `PolicyId` may be **absent entirely** (not null) when the product has no live policy. Do not infer its presence from `Status` — a fully-drifted product is `"new"` and still carries a `PolicyId`. Any step that resolves a `PolicyId` must check for the key and skip the product when it is missing.
 
 `Data.Clauses[].Status` (per-control rollup):
 - `"fully-deployed"` — every checkable setting satisfied — display as **Applied** (✓)
-- `"partially-deployed"` — some but not all satisfied — display as **Partially Applied** (◐)
+- `"partially-deployed"` — some but not all satisfied, OR nothing satisfied yet but ⚙ manual configuration is pending — display as **Partially Applied** (◐). A clause showing `0/<n>` with this status is expected, not a data error: pending-manual controls keep a clause out of `"not-deployed"`.
 - `"not-deployed"` — none satisfied — display as **Not Applied** (✗)
 
-`Data.Clauses[].controls[]` (per-setting; present on updated CLI) — the truthful per-setting view:
-- `controlDisplayName` — setting name
-- `productIdentifier` — owning product
-- `impact` — `"High"` / `"Medium"` / `"Low"`
-- `recommendedSetting` — the recommended value
-- `status` — `"deployed"` (✓ Applied) / `"not-deployed"` (✗ Not Applied) / `"manual"` (⚙ Needs Manual Configuration — admin must set a value)
-
-`Data.Clauses[].manualConfigChecks[]` (the actionable "what to set" detail behind every `status == "manual"` control) — join to a `controls[]` entry by `controlDisplayName`:
-- `controlDisplayName` — the setting
-- `productIdentifier` — owning product
-- `expected` — the value the standard requires, as a predicate object (`{eq}` / `{gte}` / `{lte}` / `{contains}`); render human-readable (`{gte: 30}` → "at least 30", `{eq: true}` → "Enabled")
-- `actual` — the value currently deployed on the tenant (absent / `null` when unset)
+`Data.Clauses[].Controls[]` (per-setting; present on updated CLI) — the truthful per-setting view:
+- `ControlDisplayName` — setting name
+- `ControlId` — stable id; the join key to `DriftedControls[]`
+- `ProductIdentifier` — owning product
+- `Impact` — `"High"` / `"Medium"` / `"Low"`
+- `RecommendedSetting` — the recommended value
+- `Status` — `"deployed"` (✓ Applied) / `"not-deployed"` (✗ Not Applied) / `"manual"` (⚙ Needs Manual Configuration — admin must set a value)
+
+`Data.Clauses[].ManualConfigChecks[]` (the actionable "what to set" detail behind every `Status == "manual"` control) — join to a `Controls[]` entry by `ControlId`, falling back to `ControlDisplayName` when `ControlId` is absent (pre-2.1.0 bundles omit it; the display name is always present):
+- `ControlDisplayName` / `ControlId` — the setting
+- `ProductIdentifier` — owning product
+- `Key` — the policy formData key to set
+- `Expected` — the value the standard requires, as a predicate object with a **PascalCase** operator key (`{Eq}` / `{Gte}` / `{Lte}` / `{Contains}`); render human-readable (`{Gte: 30}` → "at least 30", `{Eq: true}` → "Enabled")
+  - **Only the operator key is really PascalCase.** Keys *inside* a `{Contains: [...]}` entry are policy formData keys, which the CLI has also PascalCased on the way out — the real ones are kebab-case (`CodeEmbeddedRulesConfigRules` is really `code-embedded-rules-config-rules`). Read them for display only. When writing a value back, take the key from `Key` and the shape from the policy's own `aops-policy get` output — never from these.
+- `Actual` — the value currently deployed on the tenant (absent / `null` when unset)
+
+`Data.DeploymentPolicies[].DriftedControls[]` — settings that WERE applied by the standard and have since been changed away from it. This is the only field that separates drift from never-applied: a drifted control shows up in `Clauses[].Controls[]` as `Status: "not-deployed"`, identical to one that was never deployed. Join by `ControlId`; when `ControlId` is absent (packs authored before bundle schema 2.1.0 omit it), fall back to `ControlDisplayName` — the server dedups drift rows by the same key.
+- `ControlId` / `ControlDisplayName` — the setting
+- `PackValueDisplay` — the value the standard expects, already display-ready
+- `ImpactedClauseId` — the clause whose rollup this drift pulled down
+- `UnmetSettings[]` — `{ Key, Expected, Actual }`, same predicate shape as `ManualConfigChecks` above
 
 `Data.Summary` (PRODUCT-grain counts + a clause rollup — read these directly, do NOT recompute):
-- `DeploymentPolicyCount` — total products · three **disjoint** product tallies that sum to it: `InPlaceCount` (fully applied) + `NeedsManualConfigCount` (deployed, manual setup pending) + `NewCount` (nothing deployed). `NewCount == 0` does NOT mean fully applied — needs-manual-config products aren't counted in it.
+- `DeploymentPolicyCount` — total products · four **disjoint** product tallies that sum to it: `InPlaceCount` (fully applied) + `NeedsManualConfigCount` (deployed, manual setup pending) + `UnverifiableCount` (policy missing, nothing checkable) + `NewCount` (nothing deployed). `NewCount == 0` does NOT mean fully applied — needs-manual-config and unverifiable products aren't counted in it. Omitting `UnverifiableCount` makes the tallies not add up.
+- `DriftedControlCount` — total drifted settings across all products. `> 0` is the signal to offer `restore` (see next-action case 3a).
 - `ClauseSummary.FullyDeployedCount` / `PartiallyDeployedCount` / `NotDeployedCount` — the clause rollup driving the SUMMARY counts and the all-applied check
 
 `Data.PackId` / `ScopeLevel` / `ScopeTargetId` — identify the pack + tenant scope (internal; the user sees the tenant NAME from auth context, not the id).
 
 ## Posture plan presentation
 
-Build the per-setting table directly from `coverage.Data.Clauses[].controls[]` — do NOT derive setting state from product status:
-- ✓ Applied — `control.status == "deployed"`
-- ✗ Not Applied — `control.status == "not-deployed"`
-- ⚙ Needs Manual Configuration — `control.status == "manual"`
+Build the per-setting table directly from `coverage.Data.Clauses[].Controls[]` — do NOT derive setting state from product status:
+- ✓ Applied — `Control.Status == "deployed"`
+- ✗ Not Applied — `Control.Status == "not-deployed"` AND its `ControlId` is NOT in any `DriftedControls[]`
+- ⟳ Changed Since Applied — `Control.Status == "not-deployed"` AND its `ControlId` IS in some `DeploymentPolicies[].DriftedControls[]`
+- ⚙ Needs Manual Configuration — `Control.Status == "manual"`
+
+The ⟳ split matters: ✗ and ⟳ look identical in `Status`, but they have different fixes. ✗ needs the setting configured in the product; ⟳ is undone by one `state restore`. Never recommend hand-editing a ⟳ setting.
+
+Per-clause counts come from the clause's own `Controls[]` (or `DeployedControlCount` / `CheckableControlCount`). The SUMMARY clause counts come from `Data.Summary.ClauseSummary.*` directly.
+
+For each ⚙ `manual` control, look up its `Data.Clauses[].ManualConfigChecks[]` entry (match on `ControlId`, else `ControlDisplayName`) and show what to change: **`Expected`** value vs **`Actual`** deployed value. This is the actionable detail — surface it, don't stop at the ⚙ marker.
+
+For each ⟳ drifted control, show the same expected-vs-actual line from its `UnmetSettings[]` (or `PackValueDisplay` when you only need the expected side).
+
+**Next-action suggestion (state-aware).** Two INDEPENDENT axes decide the call-to-action. Read each from its own source — never derive one from the other:
 
-Per-clause counts come from the clause's own `controls[]` (or `deployedControlCount` / `checkableControlCount`). The SUMMARY clause counts come from `Data.Summary.ClauseSummary.*` directly.
+- **Is the pack applied?** — `state get` → `Data.Active`. This is the ONLY authority.
+- **What is covered?** — the coverage counts. Posture only.
 
-For each ⚙ `manual` control, look up its `Data.Clauses[].manualConfigChecks[]` entry (match on `controlDisplayName`) and show what to change: **expected** value vs **currently** deployed value. This is the actionable detail — surface it, don't stop at the ⚙ marker.
+Coverage compares the pack against **whatever policies the tenant already has**, applied or not (`Does NOT require the pack to be enabled`). So coverage numbers cannot tell you whether the pack is on, in either direction:
+- Pack ON, every setting changed away → every product `new`, every clause `not-deployed`. Reads as "never applied", but the remedy is `restore`, and suggesting apply would run `state enable` on an enabled pack.
+- Pack OFF, but the tenant's own pre-existing policies happen to satisfy part of the standard → `in-place` / `needs-manual-config` products and fully/partially-deployed clauses. Reads as "already applied", and the user asking to apply the standard gets told not to.
 
-**Next-action suggestion (state-aware).** Choose the call-to-action from `Data.Summary.ClauseSummary`, evaluated IN THIS ORDER (first match wins — the cases overlap, so order matters) — NEVER suggest (re)applying a pack that is already enabled:
-1. **All applied** (`PartiallyDeployedCount == 0 && NotDeployedCount == 0`): every clause fully deployed — render the [All settings applied](#all-settings-applied) block instead of the gap template below. Nothing to apply.
-2. **Nothing applied yet** (`FullyDeployedCount == 0 && PartiallyDeployedCount == 0` — pack not enabled): the ONLY case where you suggest applying. Offer `'Apply ISO 42001 settings'`, `'Apply High impact ISO 42001 settings'`, or `'Apply only <specific area> settings'`.
-3. **Already applied, gaps remain** (otherwise — pack enabled, `state enable` already ran, `PartiallyDeployedCount > 0 || NotDeployedCount > 0`): do NOT suggest reapplying the standard or applying a subset. Point the user at the residual settings that need attention:
-   - If any ⚙ `manual` controls exist: `'Configure the manual ISO 42001 settings'` — the ⚙ items with expected/actual in DETAILS ARE the to-do list. When the user accepts, hand off to the AOps plugin to update the existing pack policy — see [Configuring manual settings (AOps handoff)](#configuring-manual-settings--aops-handoff).
-   - Any remaining ✗ `not-deployed` settings (and the case where there are NO ⚙ manual settings, only ✗): their product's policy isn't fully in place — tell the user to configure those settings in the product's own settings; reapplying the pack will not set them. Never present an empty "configure the manual settings" prompt when there are zero ⚙ items.
+`DriftedControlCount > 0` and any `unverifiable` product each prove the pack IS active (both only exist on an active pack), but their absence proves nothing. Call `state get` — do not guess.
+
+Evaluate IN THIS ORDER (first match wins):
+
+1. **Pack NOT active** (`Data.Active == false`; a never-applied known pack returns 200 with `Active: false`, not a 404 — a 404 from `state get` means the packId itself is not usable, so re-check it against `catalog list` and stop) — the pack is not applied, whatever the coverage numbers say. Offer `'Apply ISO 42001 settings'`, `'Apply High impact ISO 42001 settings'`, or `'Apply only <specific area> settings'`. If coverage already shows partial or full clause coverage, that is the tenant's own policies coinciding with the standard, NOT the pack — say so plainly ("some of these settings already match what the standard recommends; applying it will manage them going forward") and still offer to apply. Never suppress the apply offer because coverage looks good.
+2. **Pack active, everything covered** (`Data.Active == true` and `PartiallyDeployedCount == 0 && NotDeployedCount == 0`): render the [All settings applied](#all-settings-applied) block. Nothing to apply.
+3. **Pack active, gaps remain** (`Data.Active == true`, otherwise): do NOT suggest reapplying the standard or applying a subset. Point the user at the residual settings, checking the drift case FIRST:
+   - **3a. If `Summary.DriftedControlCount > 0` OR any product is `unverifiable`:** offer `'Reset the changed ISO 42001 settings back to the standard'` — the ⟳ items ARE that list, and restore also RECREATES the missing policy behind any Cannot-Be-Checked product (it resets every live pack policy to the bundle's suggested values and recreates deleted ones). Hand off to [`../restore/impl.md`](../restore/impl.md), which owns the confirmation gate — including the warning that restore also resets any ⚙ manual values an admin has already configured. Do NOT tell the user to hand-edit a ⟳ setting, and do NOT route ⟳ items into the AOps handoff below — that is the remedy for ⚙, not for drift.
+   - If any ⚙ `manual` controls exist: `'Configure the manual ISO 42001 settings'` — the ⚙ items with expected/actual in DETAILS ARE the to-do list. When the user accepts, hand off to the AOps plugin to update the existing pack policy — see [Configuring manual settings (AOps handoff)](#configuring-manual-settings--aops-handoff). When 3a also applies, sequence restore FIRST, then the manual values — restore would overwrite manual values configured before it.
+   - On an active pack there is no third remedy: a plain ✗ (not-deployed, not drifted) only occurs under a Cannot-Be-Checked product whose policy is missing — restore recreates it (3a). Never tell the user to configure an active pack's settings in the product's own UI. (Exception: an older server that doesn't return drift fields at all — then ✗ under an active pack is indistinguishable drift, and restore is still the remedy.)
+   - Fallback, if that ever fails to hold — ✗ settings on an active pack with no drift and no Cannot-Be-Checked product: do NOT leave them unexplained. Offer restore anyway (it re-asserts the standard's values on every live policy) and say the settings are not in place for a reason the posture data doesn't explain.
+
+   These are not exclusive — a tenant can have ⟳, ⚙, and ✗ at once. Offer each that applies, drift first.
+
+   **Degraded-response check:** the server computes drift and `unverifiable` only when its own internal pack-state read succeeds; on failure it silently returns coverage WITHOUT them (products with deleted policies then show as `new`). The tell: on an active pack, a `new` product ALWAYS carries drifted controls — so `Active == true` plus a `new` product with `DriftedControlCount == 0` means the response is degraded. Re-run coverage before acting on it.
+
+**If `state get` fails** (401 / 5xx, so `Active` is unknown): do NOT fall back to guessing from coverage counts. Present the posture, say the pack's applied state could not be read, and offer both directions rather than picking one.
 
 Never render product coverage — product grain is internal only.
 
-**Graceful degrade:** if `Clauses[].controls` is absent (older CLI/server), fall back to the clause-grain view (`Clauses[].Status` fully/partially/not-deployed) and add a one-line note that per-setting detail needs an updated `uip` CLI. Never fabricate per-setting state.
+**Graceful degrade:** if `Clauses[].Controls[]` is missing across every clause (older CLI/server; note a single clause with an empty `Controls[]` is normal — surface-only clauses have no checkable controls), fall back to the clause-grain view (`Clauses[].Status` fully/partially/not-deployed) and add a one-line note that per-setting detail needs an updated `uip` CLI. Never fabricate per-setting state.
 
-Progress bar: 5 cells scaled to the deployed ratio — filled = `round(deployedControlCount / checkableControlCount × 5)` `▓`, remainder `░` (2/5 → `▓▓░░░`, 1/4 → `▓░░░░`, 4/4 → `▓▓▓▓▓`).
+Progress bar: 5 cells scaled to the deployed ratio — filled = `round(DeployedControlCount / CheckableControlCount × 5)` `▓`, remainder `░` (2/5 → `▓▓░░░`, 1/4 → `▓░░░░`, 4/4 → `▓▓▓▓▓`).
 
-A setting is a **gap** when its `status != "deployed"` — i.e. both `not-deployed` (✗) and `manual` (⚙) count as gaps in the impact tallies and per-clause counts (a manual setting is not yet applied).
+A setting is a **gap** when its `Status != "deployed"` — i.e. `not-deployed` (✗), drifted (⟳) and `manual` (⚙) all count as gaps in the impact tallies and per-clause counts (a manual setting is not yet applied).
 
-**Biggest risk area:** clause with the most High-impact gap controls (`impact == "High" && status != "deployed"`).
-**Quickest win:** clause with the fewest gap controls (`status != "deployed"`) AND at least one is High impact.
+**Biggest risk area:** clause with the most High-impact gap controls (`Impact == "High" && Status != "deployed"`). Ties: the clause with the LOWER deployed ratio (`DeployedControlCount / CheckableControlCount` — furthest from done); still tied, the first in the order the API returned.
+**Quickest win:** clause with the fewest gap controls (`Status != "deployed"`) AND at least one is High impact. Ties: the clause with the HIGHER deployed ratio (closest to done); still tied, the first in the order the API returned.
+The two tie-breaks pull opposite ways on purpose — a single-clause tie must not name the same clause in both rows. If it still does (one clause is genuinely both), leave Quickest win blank rather than repeat it.
 
 Terminology rules:
 - Use "settings" NOT "controls" in output
-- Use plain-English clause names (from `clauses[].clauseName`) in headlines; clause IDs (e.g. A.6.2.8) as secondary reference in DETAILS only
-- Use `controls[].controlDisplayName` as setting name, NOT product identifiers
-- **NEVER write raw API status strings** — product `in-place`/`new`; clause `fully-deployed`/`partially-deployed`/`not-deployed`; control `deployed`/`not-deployed`/`manual` — in user-facing display output (posture_plan.txt, chat responses, report summaries) — translate EVERY occurrence before writing
+- Use plain-English clause names (joined from `catalog.json` by `ClauseId` — see the pre-condition; coverage's own `ClauseName` is null) in headlines; clause IDs (e.g. A.6.2.8) as secondary reference in DETAILS only
+- Use `Controls[].ControlDisplayName` as setting name, NOT product identifiers
+- **NEVER write raw API status strings** — product `in-place`/`needs-manual-config`/`unverifiable`/`new`; clause `fully-deployed`/`partially-deployed`/`not-deployed`; control `deployed`/`not-deployed`/`manual` — in user-facing display output (posture_plan.txt, chat responses, report summaries) — translate EVERY occurrence before writing
   - `"in-place"` → **Applied** (or ✓)
   - `"new"` → **Not Applied** (or ✗)
+  - `"unverifiable"` → **Cannot Be Checked** — the product's policy is missing, so say the settings can't be verified. Never report an unverifiable product as Applied.
+  - a drifted setting → **Changed Since Applied** (or ⟳) — never "not deployed"
 - **`coverage.json` is an internal session file** — save it as the raw `--output json` CLI response. Raw API values (`"in-place"`, `"new"`) are CORRECT and expected in this file. Do NOT translate status values when writing coverage.json.
 - Never say "compliance gaps" — say "settings not yet configured"
 - Never claim the tenant IS compliant
 
-Render this gap template ONLY for cases 2 and 3 above (gaps remain). For case 1 (all applied) use the [All settings applied](#all-settings-applied) block instead — never reach this template with zero gaps.
+Render this gap template ONLY for cases 1 and 3 above (pack not applied, or applied with gaps). For case 2 (active and fully covered) use the [All settings applied](#all-settings-applied) block instead — never reach this template with zero gaps.
 
 ```
 ISO 42001 Posture — <tenantName>  ·  <date>
@@ -108,15 +160,15 @@ SUMMARY
 │ Clauses fully covered   │ <clausesFullyDeployed> / <totalClauses>          │
 │ Clauses with gaps       │ <clausesWithGaps> / <totalClauses>               │
 ├─────────────────────────┼──────────────────────────────────────┤
-│ 🔴 High impact gaps     │ <highGapCount> settings Not Applied  across <highClauseCount> clauses  │
-│ 🟡 Medium impact gaps   │ <medGapCount> settings Not Applied   across <medClauseCount> clauses   │
-│ 🟢 Low impact gaps      │ <lowGapCount> settings Not Applied   across <lowClauseCount> clauses   │
+│ 🔴 High impact gaps     │ <highGapCount> settings across <highClauseCount> clauses  │
+│ 🟡 Medium impact gaps   │ <medGapCount> settings across <medClauseCount> clauses    │
+│ 🟢 Low impact gaps      │ <lowGapCount> settings across <lowClauseCount> clauses    │
 ├─────────────────────────┼──────────────────────────────────────┤
-│ Biggest risk area       │ <clauseName with most High-impact settings Not Applied>          │
+│ Biggest risk area       │ <clauseName with most High-impact gap settings>  │
 │ Quickest win            │ <clauseName with fewest gaps AND ≥1 High setting>│
 └─────────────────────────┴──────────────────────────────────────┘
 
-<call-to-action per Next-action suggestion (this template only renders for cases 2/3): case 2 (nothing applied) → 'Apply ISO 42001 settings' / 'Apply High impact ISO 42001 settings' / 'Apply only <specific area> settings'; case 3 (enabled, gaps remain) → 'Configure the manual ISO 42001 settings'>
+<call-to-action per Next-action suggestion (this template renders for cases 1 and 3): case 1 (pack not applied) → 'Apply ISO 42001 settings' / 'Apply High impact ISO 42001 settings' / 'Apply only <specific area> settings'; case 3 (applied, gaps remain) → in order: 'Reset the changed ISO 42001 settings back to the standard' (when ⟳ settings or a Cannot-Be-Checked product exist), then 'Configure the manual ISO 42001 settings' (when ⚙ settings exist)>
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 DETAILS
@@ -128,16 +180,40 @@ Needs Configuration  (<N> of <total>)
   ┌───────────────────────────────────┬─────────────────────┬────────┐
   │ Setting                           │ Recommendation      │ Impact │
   ├───────────────────────────────────┼─────────────────────┼────────┤
-  │ ✗ <controlDisplayName>            │ <recommendedSetting>│ High   │
-  │ ⚙ <controlDisplayName>            │ <recommendedSetting>│ Medium │
-  │ ✓ <controlDisplayName>            │ Applied             │ Medium │
+  │ ✗ <ControlDisplayName>            │ <RecommendedSetting>│ High   │
+  │ ⟳ <ControlDisplayName>            │ <RecommendedSetting>│ High   │
+  │ ⚙ <ControlDisplayName>            │ <RecommendedSetting>│ Medium │
+  │ ✓ <ControlDisplayName>            │ Applied             │ Medium │
   └───────────────────────────────────┴─────────────────────┴────────┘
-  Marker = `control.status`: ✓ deployed · ✗ not-deployed · ⚙ manual
-  For each ⚙ row, add a sub-line from manualConfigChecks (expected vs actual):
-    ⚙ <controlDisplayName> — set to <expected>; currently <actual, or "not set">
+  Marker = `Control.Status` + drift join: ✓ deployed · ✗ not-deployed · ⟳ not-deployed AND in `DriftedControls[]` · ⚙ manual
+  For each ⚙ row, add a sub-line from `ManualConfigChecks` (`Expected` vs `Actual`):
+    ⚙ <ControlDisplayName> — set to <Expected>; currently <Actual, or "not set">
+  For each ⟳ row, add a sub-line from `DriftedControls[].UnmetSettings[]`:
+    ⟳ <ControlDisplayName> — standard expects <PackValueDisplay>; currently <Actual>
+  Rendering `Actual` — never print it verbatim, whatever its type:
+  - Scalar tokens (`yes`/`no`/`true`/`false`/`null`): translate into the vocabulary of
+    the displayed recommendation (expected `{Eq: "yes"}`, actual `"no"`, under "Display
+    EDR Status: Enabled" → "currently Disabled").
+  - Arrays and objects (common — an `Expected` of `{Contains: [...]}` has an `Actual`
+    that is the whole live array, often hundreds of characters): NEVER print the
+    structure. Say whether the required entry is present: "currently not configured"
+    when the array has no matching entry, or "configured, but not with the value the
+    standard requires" when other entries exist. Dumping the array violates the
+    no-raw-output rule.
+  - Can't tell: "currently not set to the recommended value". Never the raw token.
+  The Recommendation column, and the expected side of BOTH ⚙ and ⟳ sub-lines, always
+  show the editorial value (`RecommendedSetting` / `PackValueDisplay`), never the raw
+  predicate — the predicate is for machine comparison; the two can differ in units
+  (e.g. "Development only" vs `{Eq: true}`).
 
   [repeat per clause with gaps]
 
+  When any product is Cannot Be Checked (unverifiable), add ONE note after the last
+  clause block, naming the affected ✗ settings without exposing product status values:
+  "Note: the ✗ settings above (<their display names or products>) sit behind a policy
+  that is missing from the tenant, so they can't currently be verified. Resetting the
+  standard recreates that policy with the recommended values."
+
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 Applied  (<N> of <total>)  ✓
@@ -149,13 +225,14 @@ Applied  (<N> of <total>)  ✓
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Next action (state-aware — see "Next-action suggestion"):
-  · pack already enabled / partial gaps → 'Configure the manual ISO 42001 settings'   ·   'What does [clause name] require?'
+  · any ⟳ settings or Cannot-Be-Checked → 'Reset the changed ISO 42001 settings back to the standard'
+  · Active == true, partial gaps        → 'Configure the manual ISO 42001 settings'   ·   'What does [clause name] require?'
   · nothing applied yet                 → 'Apply ISO 42001 settings' (y/n)   ·   'Just fix the High impact gaps'   ·   'Apply only <specific area> settings'
 ```
 
 ## All settings applied
 
-If `Summary.ClauseSummary.PartiallyDeployedCount == 0 && NotDeployedCount == 0` (every clause fully deployed). Do NOT use `Summary.NewCount == 0` for this — with disjoint product counts a `needs-manual-config` product leaves `NewCount == 0` while settings still need manual setup:
+Next-action case 2 only: `state get` says `Data.Active == true` **AND** `Summary.ClauseSummary.PartiallyDeployedCount == 0 && NotDeployedCount == 0` (every clause fully deployed). Do NOT use `Summary.NewCount == 0` for this — with disjoint product counts a `needs-manual-config` product leaves `NewCount == 0` while settings still need manual setup:
 
 ```
 All ISO 42001 recommended settings are Applied on <tenantName>.
@@ -166,17 +243,19 @@ To remove them: 'Remove ISO 42001 settings'
 
 Do NOT call `state enable` in this case.
 
+**The `Active` half is not optional.** With full clause coverage but `Active == false`, the tenant's own policies happen to match the standard — the pack is not managing anything. Use case 1 instead: say the settings already line up, and still offer to apply. Never print "To remove them" for a pack that was never applied — there is nothing to remove.
+
 ## Configuring manual settings — AOps handoff
 
 When the user accepts `'Configure the manual ISO 42001 settings'` (offered ONLY in the already-applied / partial state), hand off to this skill's AOps policy mechanic to update the EXISTING deployed policy. Do NOT re-enable the pack (`state enable`) and do NOT create a new policy — the pack already deployed one policy per product; a `manual` setting is just an org-specific formData key on that policy that automation could not fill. This mutation happens on the **AOps branch** (Critical Rule 3: one branch per mutation).
 
-Each ⚙ setting is a `Data.Clauses[].manualConfigChecks[]` entry: `{ productIdentifier, key, expected, actual }`. Group them by `productIdentifier` — one policy per product, updated once.
+Each ⚙ setting is a `Data.Clauses[].ManualConfigChecks[]` entry: `{ ProductIdentifier, Key, Expected, Actual }`. Group them by `ProductIdentifier` — one policy per product, updated once.
 
 Per product:
 1. **Resolve the pack's policy id for the product.** `uip gov aops-policy deployment tenant get <TENANT_ID> --output json` → the `TenantPolicies[]` entry whose `ProductIdentifier` matches → its `PolicyIdentifier`. Cross-check it belongs to the pack against `state get tenant <TENANT_ID> <packId>` `Policies[].ExternalPolicyId`.
-2. **Collect the org-specific value(s).** `expected` is a predicate (`{eq}`/`{gte}`/`{lte}`/`{contains}`); `manual` means the concrete value is org-specific (an allowlist, a package set, a threshold). Ask the user, and confirm the value satisfies `expected`.
-3. **Update via the AOps plugin.** Follow [`../../aops-policy/aops-policy-manage-guide.md`](../../aops-policy/aops-policy-manage-guide.md): `aops-policy get <PolicyIdentifier>` → set each `key` in the returned formData to the collected value (build `--input` per [`../../aops-policy/configure-aops-policy-data-guide.md`](../../aops-policy/configure-aops-policy-data-guide.md)) → `aops-policy update` (**full replacement** — pass `--identifier <PolicyIdentifier>` plus every existing field back: `--name`, `--product-name`, `--description`, `--priority`, `--availability`, `--input` — omitting any clears it, per [`../../aops-policy/aops-policy-commands.md`](../../aops-policy/aops-policy-commands.md)). Never call `state enable`.
-4. **Receipt + confirm.** Show a post-update receipt (Critical Rule 6), then re-run coverage; each fixed ⚙ setting should flip to ✓ (`controls[].status == "deployed"`).
+2. **Collect the org-specific value(s).** `Expected` is a predicate (`{Eq}`/`{Gte}`/`{Lte}`/`{Contains}`); `manual` means the concrete value is org-specific (an allowlist, a package set, a threshold). Ask the user, and confirm the value satisfies `Expected`. For a `{Contains: [...]}` predicate, compare against the live policy's own formData from step 3's `aops-policy get` — the keys inside the predicate entry are CLI-PascalCased formData keys, not the real ones (see the `Expected` note above), so building an entry from them writes keys the policy does not have.
+3. **Update via the AOps plugin.** Follow [`../../aops-policy/aops-policy-manage-guide.md`](../../aops-policy/aops-policy-manage-guide.md): `aops-policy get <PolicyIdentifier>` → set each `Key` in the returned formData to the collected value (build `--input` per [`../../aops-policy/configure-aops-policy-data-guide.md`](../../aops-policy/configure-aops-policy-data-guide.md)) → `aops-policy update` (**full replacement** — pass `--identifier <PolicyIdentifier>` plus every existing field back: `--name`, `--product-name`, `--description`, `--priority`, `--availability`, `--input` — omitting any clears it, per [`../../aops-policy/aops-policy-commands.md`](../../aops-policy/aops-policy-commands.md)). Never call `state enable`.
+4. **Receipt + confirm.** Show a post-update receipt (Critical Rule 6), then re-run coverage; each fixed ⚙ setting should flip to ✓ (`Controls[].Status == "deployed"`).
 
 Graceful degrade: if the AOps guides are unavailable, present the ⚙ list (setting, expected, current) and tell the user to set each value on the product's deployed policy in Automation Ops — never leave the manual settings as a dead-end suggestion.
 
@@ -219,7 +298,13 @@ Always run fresh before presenting a posture plan. Coverage reflects live tenant
 
 ## Anti-patterns
 
-- **Writing raw API status strings in user-facing display output** — product `in-place`/`new`; clause `fully-deployed`/`partially-deployed`/`not-deployed`; control `deployed`/`not-deployed`/`manual` — must NEVER appear in user-facing display output (posture_plan.txt, chat responses, report summaries). Translate every status before writing. `coverage.json` is an internal session file — raw API values are correct there.
+- **Writing raw API status strings in user-facing display output** — product `in-place`/`needs-manual-config`/`unverifiable`/`new`; clause `fully-deployed`/`partially-deployed`/`not-deployed`; control `deployed`/`not-deployed`/`manual` — must NEVER appear in user-facing display output (posture_plan.txt, chat responses, report summaries). Translate every status before writing. `coverage.json` is an internal session file — raw API values are correct there.
 - **Partial translation** — translating the summary section but leaving raw values in the DETAILS or verification section. ALL sections must use the translated labels.
 - **Quoting API values for context** — avoid notes like "Status is still 'new'". Rephrase to "AI Trust Layer shows as Not Applied" instead.
-- **Deriving per-setting state from product status** — use `Clauses[].controls[].status` (`deployed`/`not-deployed`/`manual`). Never mark a setting Applied because its product is `in-place`.
+- **Deriving per-setting state from product status** — use `Clauses[].Controls[].Status` (`deployed`/`not-deployed`/`manual`). Never mark a setting Applied because its product is `in-place`.
+- **Treating a drifted setting as never-applied** — telling the user to go configure a ⟳ setting in the product's own settings. It was applied and then changed; `state restore` puts it back. Always join `Controls[]` to `DriftedControls[]` (by `ControlId`, falling back to `ControlDisplayName`) before writing a remedy.
+- **Sending the user to the product's own settings UI for an active pack's gaps** — on an active pack every gap routes to `restore` (⟳ drift and missing policies) or the AOps handoff (⚙ manual). Hand-editing product settings is never the remedy while the pack manages them.
+- **Summing only three product counts** — `InPlaceCount + NeedsManualConfigCount + NewCount` does NOT equal `DeploymentPolicyCount` when any product is `unverifiable`. Read the counts; never recompute a total from a subset.
+- **Reading `PolicyId` on every product** — it can be absent when there is no live policy. Check for the key; never infer its presence from `Status` (a fully-drifted product is `"new"` and does have one).
+- **Inferring whether the pack is applied from coverage numbers** — the single most damaging mistake here, and it fails in both directions. Zero coverage can mean an enabled pack whose settings were all changed away (remedy: `restore`, not apply). Partial or full coverage can mean the tenant's own pre-existing policies coincide with the standard while the pack is off (so the apply offer must still be made). Coverage runs pack-on or pack-off by design — read `Data.Active` from `state get` and nothing else.
+- **Suppressing the apply offer because coverage looks good** — a user asking to apply a standard on a tenant that merely happens to satisfy part of it must still be offered the apply. Coincidental coverage is not an applied pack.

package/skills/uipath-governance/references/compliance-pack/restore/impl.md

@@ -0,0 +1,61 @@
+# Restore — Reset to Recommended Settings
+
+**Preview gate:** Compliance Standards is a preview feature. Append the disclaimer to user-facing output; on any compliance-packs **403**, stop (org not enrolled). See [preview-gate.md](../preview-gate.md).
+
+Resets an already-active compliance standard's policies back to the values the standard recommends — undoing any local drift. It resets live policies to the suggested config, recreates any that were deleted, and re-asserts the tenant bindings. Only works while the standard is active; custom (Rego) policies are left untouched.
+
+Use this when the user wants to undo changes made to a configured standard, or after a `coverage` posture check shows drift (`Data.Summary.DriftedControlCount > 0`, detail in `Data.DeploymentPolicies[].DriftedControls[]` — the ⟳ rows in the posture table).
+
+`<packName>` below = the standard's display name (e.g. "ISO 42001") — from the user's request or `Data.Packs[].PackName` in `catalog list`.
+
+## Check current state first
+
+```bash
+TENANT_ID=$(grep '^UIPATH_TENANT_ID=' ~/.uipath/.auth | cut -d'=' -f2-)
+uip gov compliance-packs state get tenant $TENANT_ID <packId> --output json
+```
+
+Decide from the `state get` result:
+- **Not active** — a successful response with `Data.Active == false` (a never-applied known pack returns 200 with `Active: false`, `PackStateId: null`): the standard isn't configured, so there is nothing to restore. Reply "<packName> is not currently configured on this tenant — enable it first with `state enable`." and stop.
+- **404** — the packId itself is not usable (unknown, or a catalog entry with no bundle). Do NOT suggest `state enable` — it would 404 too. Re-check the id with `catalog list` and stop.
+- **Active** — `Data.Active == true`: proceed.
+- **State could not be read** — `state get` failed with an auth/connection error (401 / 5xx) so `Active` is unknown: do NOT claim a state. Proceed to Confirmation, then the restore step, and report whatever error the restore call surfaces. (A **403** → preview gate: see [preview-gate.md](../preview-gate.md).)
+
+## Confirmation
+
+```
+This will reset all <packName> recommended settings on <tenantName> back to the values the standard recommends, overwriting any local changes to those policies.
+This includes any values you configured for the standard's manual settings — those go back to the bundle defaults and will need to be configured again. Policies that were deleted are recreated.
+
+Are you sure? (y/n)
+```
+
+Ask, then STOP — end your reply. Never run `state restore` in the same response as this question. Proceed only on an explicit `y` in the user's next message; halt on anything else. The user's original request ("reset my settings") is intent, not consent. Sole exception: the user explicitly waived confirmation in advance (e.g., "don't ask for confirmation") — treat the waiver as `y`.
+
+## Restore
+
+```bash
+uip gov compliance-packs state restore tenant $TENANT_ID <packId> --output json
+```
+
+On failure, read the status the error carries:
+- **404** — the packId is not in the loaded catalog. List valid packs with `uip gov compliance-packs catalog list`.
+- **409** — either the standard is not active (enable it first with `state enable`) or another operation on this pack is already in progress (wait a few seconds and retry).
+
+## Report
+
+Success returns the full state detail (`Data.Active`, `Data.Policies[]`). Report:
+
+"<packName> recommended settings on `<tenantName>` reset to the standard's suggested values."
+
+## Arriving from a coverage drift check
+
+When `coverage` routed here (its next-action case 3a — `Summary.DriftedControlCount > 0` or an `unverifiable` product), the ⟳ settings and Cannot-Be-Checked products it listed ARE what this call fixes. Two changes to the flow above:
+
+- **Skip the `state get` pre-check.** Coverage already proves the pack is active — drift and `unverifiable` both exist only on an active pack. Go straight to Confirmation, and name the ⟳ settings (and any product whose policy will be recreated) so the user sees exactly what is about to change.
+- **Verify after.** Re-run `coverage` and confirm the ⟳ settings flipped back to ✓ and no product is Cannot-Be-Checked anymore. If any is still ⟳, it did not reset — report that plainly rather than claiming success. ⚙ manual items reappearing IS expected (restore resets their values to bundle defaults); do not report those as a failure.
+
+What restore does and does not fix, per the server's own semantics (it resets every live pack policy to the bundle's suggested formData — a FULL replacement — and recreates deleted ones):
+- ⟳ drifted settings — fixed.
+- Cannot-Be-Checked products (policy deleted out-of-band) — fixed: the policy is recreated with the bundle's values.
+- ⚙ manual settings — NOT fixed, and worse: any value an admin had already configured for them is wiped back to the bundle default. After a restore, expect the ⚙ list to be back in full; say so, and point at the manual-settings flow to (re)configure them AFTER the restore, never before.