@uipath/skills 1.201.0-preview.621 → 1.202.0-preview.635

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

@@ -4,6 +4,8 @@
 
 Compares the compliance standard's recommended settings against what is currently deployed on the tenant. Does NOT require the standard to be enabled first. Does NOT certify compliance — it identifies which settings from the standard are not yet configured.
 
+`<packId>` / `<packName>` below = the standard being checked, resolved via [`../catalog/impl.md` § Pack ID lookup](../catalog/impl.md#pack-id-lookup). Coverage is per standard — if the user asked about posture without naming one, resolve it there first; do not default to whichever pack is listed first.
+
 ## Command
 
 **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`.
@@ -109,11 +111,11 @@ Coverage compares the pack against **whatever policies the tenant already has**,
 
 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.
+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 <packName> settings'`, `'Apply High impact <packName> 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.
+   - **3a. If `Summary.DriftedControlCount > 0` OR any product is `unverifiable`:** offer `'Reset the changed <packName> 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 <packName> 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.
 
@@ -151,7 +153,7 @@ Terminology rules:
 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>
+<packName> Posture — <tenantName>  ·  <date>
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 SUMMARY
@@ -168,7 +170,7 @@ SUMMARY
 │ Quickest win            │ <clauseName with fewest gaps AND ≥1 High setting>│
 └─────────────────────────┴──────────────────────────────────────┘
 
-<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)>
+<call-to-action per Next-action suggestion (this template renders for cases 1 and 3): case 1 (pack not applied) → 'Apply <packName> settings' / 'Apply High impact <packName> settings' / 'Apply only <specific area> settings'; case 3 (applied, gaps remain) → in order: 'Reset the changed <packName> settings back to the standard' (when ⟳ settings or a Cannot-Be-Checked product exist), then 'Configure the manual <packName> settings' (when ⚙ settings exist)>
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 DETAILS
@@ -225,9 +227,9 @@ Applied  (<N> of <total>)  ✓
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Next action (state-aware — see "Next-action suggestion"):
-  · 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'
+  · any ⟳ settings or Cannot-Be-Checked → 'Reset the changed <packName> settings back to the standard'
+  · Active == true, partial gaps        → 'Configure the manual <packName> settings'   ·   'What does [clause name] require?'
+  · nothing applied yet                 → 'Apply <packName> settings' (y/n)   ·   'Just fix the High impact gaps'   ·   'Apply only <specific area> settings'
 ```
 
 ## All settings applied
@@ -235,10 +237,10 @@ Next action (state-aware — see "Next-action suggestion"):
 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>.
+All <packName> recommended settings are Applied on <tenantName>.
 <fullyDeployedCount> / <totalClauses> clauses fully deployed  ·  all settings Applied ✓
 
-To remove them: 'Remove ISO 42001 settings'
+To remove them: 'Remove <packName> settings'
 ```
 
 Do NOT call `state enable` in this case.
@@ -247,7 +249,7 @@ Do NOT call `state enable` in this case.
 
 ## 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).
+When the user accepts `'Configure the manual <packName> 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.
 
@@ -264,7 +266,7 @@ Graceful degrade: if the AOps guides are unavailable, present the ⚙ list (sett
 Ask for values — known recommended value → offer to confirm it; org-specific gate → ask for the value. Never show policy ids or CLI:
 
 ```
-3 settings need a value only you can set — I'll update the existing ISO 42001 policies in place.
+3 settings need a value only you can set — I'll update the existing <packName> policies in place.
 
 1. Studio Web — Publish Outside Personal Workspace  (AI system deployment · High)
    Recommended: Development only · currently: Anywhere        → set to recommended? (yes / other)

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

@@ -4,6 +4,8 @@
 
 Removes all policy deployments configured by the compliance standard.
 
+`<packId>` / `<packName>` below = the standard to remove, resolved via [`../catalog/impl.md` § Pack ID lookup](../catalog/impl.md#pack-id-lookup). Disable is per standard — removing one leaves any other configured standard untouched. If the user did not name one and `state list` shows more than one active, ask which before touching anything.
+
 ## Check current state first
 
 ```bash
@@ -12,13 +14,13 @@ uip gov compliance-packs state get tenant $TENANT_ID <packId> --output json
 ```
 
 Decide from the `state get` result:
-- **Confirmed inactive** — a successful response with `Data.active == false`, or a 404: reply "ISO 42001 recommended settings are not currently configured on this tenant." and stop (nothing to remove).
+- **Confirmed inactive** — a successful response with `Data.active == false`, or a 404: reply "<packName> recommended settings are not currently configured on this tenant." and stop (nothing to remove).
 - **State could not be read** — `state get` failed with an auth/connection error (401 / 5xx) so `active` is unknown: do NOT claim "not configured." Proceed to the disable step and report whatever error that call surfaces. (A **403** → preview gate: see [preview-gate.md](../preview-gate.md).)
 
 ## Confirmation
 
 ```
-This will remove all ISO 42001 recommended settings from <tenantName>.
+This will remove all <packName> recommended settings from <tenantName>.
 
 Policies that will be removed:
   <list Data.policies[].policyType: Data.policies[].externalPolicyId>
@@ -36,4 +38,4 @@ uip gov compliance-packs state disable tenant $TENANT_ID <packId> --output json
 
 ## Report
 
-"ISO 42001 recommended settings removed from `<tenantName>`. All associated policy deployments have been deleted."
+"<packName> recommended settings removed from `<tenantName>`. All associated policy deployments have been deleted."

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

@@ -4,7 +4,9 @@
 
 Applies the entire compliance standard in one command. Backend creates and deploys all recommended settings.
 
-**Note:** This configures settings recommended by ISO 42001. Your organization's auditor determines compliance status — UiPath does not certify compliance.
+`<packId>` / `<packName>` below = the standard being applied — `Data.PackId` / `Data.PackName` from the session `catalog.json`, resolved via [`../catalog/impl.md` § Pack ID lookup](../catalog/impl.md#pack-id-lookup).
+
+**Note:** This configures settings recommended by <packName>. Your organization's auditor determines compliance status — UiPath does not certify compliance.
 
 ## Pre-condition
 
@@ -15,7 +17,7 @@ Coverage (posture analysis) has been run and presented. At least one policy has
 Build this table from `catalog.clauses[].editorialPolicies[].controls[]` filtered to products where `coverage.deploymentPolicies[].status == "new"`. Group settings by impact. For settings needing user-supplied values (flagged by `synthesize-formdata` notEmpty warnings), list them with a plain-English prompt.
 
 ```
-Configure ISO 42001 settings on <tenantName>?
+Configure <packName> settings on <tenantName>?
 
 ┌──────────┬─────────────────────────────────────────────────────┐
 │ Impact   │ Settings                                            │
@@ -59,7 +61,7 @@ Parse `Data.active` (must be `true`) and `Data.policies[]` (policy UUIDs created
 ## Report
 
 ```
-ISO 42001 settings configured on <tenantName> ✓
+<packName> settings configured on <tenantName> ✓
 
 SUMMARY
 ┌───────────────────────────────────┬───────────┐
@@ -107,7 +109,7 @@ Aggregate results: note how many tenants have gaps vs are already fully Applied.
 ### Step 3 — Confirmation
 
 ```
-Configure ISO 42001 settings across all tenants in <UIPATH_ORGANIZATION_NAME>?
+Configure <packName> settings across all tenants in <UIPATH_ORGANIZATION_NAME>?
 
 Tenants to configure:
   <tenantName1> — <N> settings Not Applied
@@ -139,7 +141,7 @@ for each configured tenant:
 ### Report
 
 ```
-ISO 42001 settings configured across <N> tenants in <UIPATH_ORGANIZATION_NAME> ✓
+<packName> settings configured across <N> tenants in <UIPATH_ORGANIZATION_NAME> ✓
 
 ┌──────────────────┬──────────────────┐
 │ Tenant           │ Status           │

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

@@ -4,7 +4,9 @@
 
 Synthesizes and deploys AOPS policies for the NLP-matched clause/product subset only. Used when the user asked for specific settings rather than the full standard.
 
-**Note:** This configures a subset of ISO 42001 recommended settings. Your organization's auditor determines compliance status.
+`<packId>` / `<packName>` below = the standard being applied — `Data.PackId` / `Data.PackName` from the `catalog.json` already in the session dir. Never hardcode a standard.
+
+**Note:** This configures a subset of <packName> recommended settings. Your organization's auditor determines compliance status.
 
 ## Inputs from planning.md
 
@@ -119,13 +121,13 @@ The compliance pack is the source of what values to set. The AOps plugin is the
 1. **Skip bootstrap** (already done). Set `SESSION_DIR = $SESSION_TEMP`.
 2. **Case A** — product already known. Skip intent inference.
 3. **Skip form.io traversal** — policy data is already composed. Copy `$SESSION_TEMP/merged/<product>.json` to `$SESSION_TEMP/aops-policy-data.json`.
-4. **Policy name:** `iso-42001-2023-<scopeToken>-<product-kebab>` — see Internal policy naming note below.
+4. **Policy name:** `<packId>-<scopeToken>-<product-kebab>` — see Internal policy naming note below.
 5. **Proceed to review gate** (AOps Critical Rules #15/#16):
    - AOps compares `aops-policy-data.json` against `products/<product>/form-data.json` defaults — the diff is exactly the compliance standard-recommended settings for the targeted clauses, nothing more.
    - Show the confirmation gate using this template:
 
 ```
-Configure ISO 42001 settings on <tenantName>?
+Configure <packName> settings on <tenantName>?
 
 <clauseName>  (<clauseId>)
 ┌───────────────────────────────────┬─────────────────────┬────────┐
@@ -143,7 +145,7 @@ Other products will NOT be affected.
   • <controlDisplayName>  →  <configLocation from catalog>
 (omit ⚠ block if no SKIPped settings)
 
-These settings improve your posture towards ISO 42001 requirements.
+These settings improve your posture towards <packName> requirements.
 Proceed? (y/n)
 ```
 
@@ -151,7 +153,12 @@ Build setting rows from: `catalog.clauses[].editorialPolicies[].controls[]` filt
 
 Require y. Halt on anything else.
 
-> **Internal policy naming:** `iso-42001-2023-<scopeToken>-<product-kebab>` — scopeToken per product: `aitl` (AITrustLayer), `dev` (Development), `robot` (Robot), `asst` (Assistant), `stw` (StudioWeb), `is` (IntegrationService); per clause subset: `a628` (A.6.2.8), `a92` (A.9.2); per impact subset: `high`.
+> **Internal policy naming:** `<packId>-<scopeToken>-<product-kebab>`. The `<packId>` prefix keeps each standard's policies in its own namespace — never hardcode `iso-42001-2023`, or two standards' policies collide on the same tenant.
+> scopeToken per product: `aitl` (AITrustLayer), `dev` (Development), `robot` (Robot), `asst` (Assistant), `stw` (StudioWeb), `is` (IntegrationService). **Any product not in that list** — standards differ in which products they touch — take the `ProductIdentifier` lowercased (`Orchestrator` → `orchestrator`). Never skip the product or invent an abbreviation; an unrecognised product is a naming case, not an error.
+> Per clause subset: the clauseId lowercased with dots and dashes stripped (`A.6.2.8` → `a628`, `A.9.2` → `a92`, `6.1.4` → `614`). Per impact subset: `high`.
+> Per **topic subset** — the category keywords in [`planning.md`](planning.md) (traceability, guardrails/PII, model governance, robot allowlists): use the fixed token for that row — `trace`, `pii`, `models`, `uiauto`. Do NOT coin a new word per request: the policy name is what makes a re-apply update the existing policy instead of creating a second one, so the same topic must always produce the same token.
+>
+> If a scope matches none of the four cases above, fall back to the clause-id form for the clauses actually being applied. Never invent a free-form token.
 6. On `yes` → AOps runs `aops-policy create` → **return the policy UUID to partial apply**.
 7. On failure or skip → log product as `skipped`, continue to next product.
 
@@ -235,7 +242,7 @@ uip gov aops-policy deployment tenant configure $TENANT_ID \
 ## Report (after successful apply)
 
 ```
-ISO 42001 settings configured on <tenantName>.
+<packName> settings configured on <tenantName>.
 
 ┌───────────────────────────────────┬───────────┐
 │ Settings configured               │ <N>       │
@@ -253,7 +260,7 @@ ISO 42001 settings configured on <tenantName>.
 
 Applied by: <UIPATH_USER from ~/.uipath/.auth>  ·  <tenantName>  ·  <date>
 
-To configure all ISO 42001 settings: 'Apply the full ISO 42001 standard'
+To configure all <packName> settings: 'Apply the full <packName> standard'
 ```
 
 ## Error handling

package/skills/uipath-governance/references/compliance-pack/partial-apply/planning.md

@@ -2,6 +2,8 @@
 
 Enter this plugin when the user explicitly scoped their request to a subset of the pack's recommended settings.
 
+`<packName>` below = the standard's display name, resolved via [`../catalog/impl.md` § Pack ID lookup](../catalog/impl.md#pack-id-lookup). Resolve the standard BEFORE matching clauses or products — clause ids and product names are pack-specific, and matching them against the wrong catalog silently targets the wrong settings.
+
 > **Critical:** Partial apply uses `synthesize-formdata.mjs` + `aops-policy create`. Do NOT call `uip gov compliance-packs state enable` — that applies the full standard and cannot be scoped.
 
 ## Strong signals → route silently to partial apply
@@ -66,7 +68,7 @@ After identifying target clauses and products, always show:
 ```
 You asked for: <user's phrase>
 I matched: <N> recommended settings across <M> product(s)
-Note: The full ISO 42001 pack covers <total> recommended settings across <total products>.
+Note: The full <packName> pack covers <total> recommended settings across <total products>.
 Configuring this selection will NOT apply settings for the other products.
 ```
 

package/skills/uipath-governance/references/compliance-pack/preview-gate.md

@@ -1,6 +1,6 @@
 # Compliance Standards — Preview Gate & Disclaimer
 
-Compliance Standards (ISO 42001 and any future standard) is a **preview feature**, available only to
+Compliance Standards (every standard in the catalog — ISO 42001, ISO 27001, and any future one) is a **preview feature**, available only to
 organizations enrolled in the UiPath preview program. This applies to **every** compliance-pack flow —
 catalog, coverage, full-apply, partial-apply, disable, query, state list, diagnose. This file is the
 single source of truth for both behaviors below; other plugins link here rather than restating them.

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

@@ -4,6 +4,8 @@
 
 Pure information — no state commands, no mutations. Uses `catalog get` data only.
 
+`<packId>` / `<packName>` below = the standard the user asked about, resolved via [`../catalog/impl.md` § Pack ID lookup](../catalog/impl.md#pack-id-lookup). If the question names no standard and more than one pack is available, ask which before fetching — a clause id alone does not identify the pack.
+
 ## When to use
 
 - "What does clause A.6.2.8 recommend?"
@@ -20,7 +22,7 @@ SESSION_TEMP=$(cat "$HOME/.uipath-compliance-current-session" 2>/dev/null) || {
   SESSION_TEMP=$(mktemp -d)
   echo "$SESSION_TEMP" > "$HOME/.uipath-compliance-current-session"
 }
-uip gov compliance-packs catalog get iso-42001-2023 --output json > "$SESSION_TEMP/catalog.json"
+uip gov compliance-packs catalog get <packId> --output json > "$SESSION_TEMP/catalog.json"
 ```
 
 ## Filter from catalog
@@ -52,7 +54,7 @@ For each matched clause:
 [repeat per matched clause]
 
 Current posture on <tenantName>: <appliedControlCount> / <checkableControlCount> settings Applied
-→ 'Check my ISO 42001 posture'  to see all gaps
+→ 'Check my <packName> posture'  to see all gaps
 → 'Apply <clauseName> settings'  to configure these
 ```
 

package/skills/uipath-governance/references/diagnose/CAPABILITY.md

@@ -32,21 +32,21 @@ Capability index for diagnosing AOps product-policy and Access tool-use-policy f
 
 | Journey | Read |
 |---------|------|
-| Triage a governance failure (sequential ladder) | [references/troubleshooting-guide.md](references/troubleshooting-guide.md) |
-| Recognize a known failure pattern (lookup) | [references/failure-modes.md](references/failure-modes.md) |
+| Triage a governance failure (sequential ladder) | [references/troubleshooting-guide.md](troubleshooting-guide.md) |
+| Recognize a known failure pattern (lookup) | [references/failure-modes.md](failure-modes.md) |
 
 ## Common tasks
 
 | I need to... | Read |
 |---|---|
-| Investigate why a deployed AOps policy isn't enforced | [troubleshooting guide → Step 2](references/troubleshooting-guide.md#step-2-check-whats-deployed) |
-| Debug deployment precedence (user > group > tenant) | [troubleshooting guide → Step 3](references/troubleshooting-guide.md#step-3-check-precedence) |
-| Diagnose wrong policy applied | [failure modes → Wrong policy applied](references/failure-modes.md#wrong-policy-applied-license-type-mismatch) |
-| Investigate blocked tool invocation | [failure modes → Access policy blocking legitimate invocation](references/failure-modes.md#access-policy-blocking-legitimate-tool-invocation) |
-| Investigate access policy not blocking | [failure modes → Access policy not blocking](references/failure-modes.md#access-policy-not-blocking) |
-| Diagnose empty deployed-policy result | [failure modes → Deployed policy returns empty](references/failure-modes.md#deployed-policy-returns-empty) |
-| Troubleshoot policy create/update rejection | [failure modes → Policy create/update rejected](references/failure-modes.md#policy-createupdate-rejected) |
-| Evaluate access-policy rules against test inputs | [troubleshooting guide → Step 4](references/troubleshooting-guide.md#step-4-for-access-evaluate-with-test-inputs) |
+| Investigate why a deployed AOps policy isn't enforced | [troubleshooting guide → Step 2](troubleshooting-guide.md#step-2-check-whats-deployed) |
+| Debug deployment precedence (user > group > tenant) | [troubleshooting guide → Step 3](troubleshooting-guide.md#step-3-check-precedence) |
+| Diagnose wrong policy applied | [failure modes → Wrong policy applied](failure-modes.md#wrong-policy-applied-license-type-mismatch) |
+| Investigate blocked tool invocation | [failure modes → Access policy blocking legitimate invocation](failure-modes.md#access-policy-blocking-legitimate-tool-invocation) |
+| Investigate access policy not blocking | [failure modes → Access policy not blocking](failure-modes.md#access-policy-not-blocking) |
+| Diagnose empty deployed-policy result | [failure modes → Deployed policy returns empty](failure-modes.md#deployed-policy-returns-empty) |
+| Troubleshoot policy create/update rejection | [failure modes → Policy create/update rejected](failure-modes.md#policy-createupdate-rejected) |
+| Evaluate access-policy rules against test inputs | [troubleshooting guide → Step 4](troubleshooting-guide.md#step-4-for-access-evaluate-with-test-inputs) |
 
 ## Anti-patterns
 
@@ -60,8 +60,8 @@ Capability index for diagnosing AOps product-policy and Access tool-use-policy f
 
 ### Diagnose-scoped
 
-- [troubleshooting-guide.md](references/troubleshooting-guide.md) — diagnostic priority ladder
-- [failure-modes.md](references/failure-modes.md) — recurring failure patterns
+- [troubleshooting-guide.md](troubleshooting-guide.md) — diagnostic priority ladder
+- [failure-modes.md](failure-modes.md) — recurring failure patterns
 
 ### Cross-capability
 

package/skills/uipath-governance/references/diagnose/{references/failure-modes.md → failure-modes.md}

@@ -63,7 +63,7 @@ Named failure patterns with symptom → cause → investigation → fix. Match t
    ```bash
    uip gov aops-policy deployment tenant get "$TENANT_ID" --output json
    ```
-3. Verify the product is included in the target license type (see [aops-policy-deploy-guide.md — License-type → product compatibility](../../aops-policy/aops-policy-deploy-guide.md#license-type--product-compatibility)).
+3. Verify the product is included in the target license type (see [aops-policy-deploy-guide.md — License-type → product compatibility](../aops-policy/aops-policy-deploy-guide.md#license-type--product-compatibility)).
 
 **Fix:** Cause 1 → redeploy to a license type that includes the target product. Cause 2 → deploy to the license type the affected users actually hold. Cause 3 → deploy to all relevant license types.
 
@@ -100,7 +100,7 @@ Named failure patterns with symptom → cause → investigation → fix. Match t
    uip gov access-policy list --filter "status in ('Active')" --output json
    ```
 
-**Fix:** Cause 1 → narrow selector `resourceType`/`tags`. Cause 2 → add the calling user/group to `actorRule`. Cause 3 → add the actor process type to `executableRule`. Cause 4 → adjust tags on the resource or policy. Cause 5 → see [plugins/actor/impl.md — Robot intent](../../access-policy/plugins/actor/impl.md) for the User-fallback pattern.
+**Fix:** Cause 1 → narrow selector `resourceType`/`tags`. Cause 2 → add the calling user/group to `actorRule`. Cause 3 → add the actor process type to `executableRule`. Cause 4 → adjust tags on the resource or policy. Cause 5 → see [plugins/actor/impl.md — Robot intent](../access-policy/plugins/actor/impl.md) for the User-fallback pattern.
 
 ---
 
@@ -133,7 +133,7 @@ Named failure patterns with symptom → cause → investigation → fix. Match t
    ```
 4. Verify the resource's tags in the Resource Catalog match the selector's tag filter.
 
-**Fix:** Cause 1 → broaden selector or add a new policy covering the gap. Cause 2 → update status to `Active`. Cause 3 → correct tags on resource or policy. Cause 4 → reframe deny intent as allow-only (see [plugins/tags/planning.md — Deny-to-Allow flip](../../access-policy/plugins/tags/planning.md#deny-to-allow-flip)). Cause 5 → use correct enum values from [plugins/selector/impl.md](../../access-policy/plugins/selector/impl.md).
+**Fix:** Cause 1 → broaden selector or add a new policy covering the gap. Cause 2 → update status to `Active`. Cause 3 → correct tags on resource or policy. Cause 4 → reframe deny intent as allow-only (see [plugins/tags/planning.md — Deny-to-Allow flip](../access-policy/plugins/tags/planning.md#deny-to-allow-flip)). Cause 5 → use correct enum values from [plugins/selector/impl.md](../access-policy/plugins/selector/impl.md).
 
 ---
 
@@ -165,7 +165,7 @@ Named failure patterns with symptom → cause → investigation → fix. Match t
    uip gov aops-policy deployment user get "$USER_ID" --output json
    ```
 
-**Fix:** Cause 1 → deploy a policy via [aops-policy-deploy-guide.md](../../aops-policy/aops-policy-deploy-guide.md). Cause 2 → redeploy to the correct tenant. Cause 3 → use the product `name` (not label) from `product list`. Cause 4 → remove the `null` override or deploy a policy at a broader scope.
+**Fix:** Cause 1 → deploy a policy via [aops-policy-deploy-guide.md](../aops-policy/aops-policy-deploy-guide.md). Cause 2 → redeploy to the correct tenant. Cause 3 → use the product `name` (not label) from `product list`. Cause 4 → remove the `null` override or deploy a policy at a broader scope.
 
 ---
 
@@ -198,4 +198,4 @@ Named failure patterns with symptom → cause → investigation → fix. Match t
    ```
 4. For Access — check error message in response `Data.errors`.
 
-**Fix:** Cause 1 → use `name` from `product list`. Cause 2 → fix JSON (validate with `jq`). Cause 3 → switch to `enforcement: "Allow"`. Cause 4 → add `"values": ["*"]` to selector entries. Cause 5 → choose a different name. Cause 6 → regenerate from template via [configure-aops-policy-data-guide.md](../../aops-policy/configure-aops-policy-data-guide.md).
+**Fix:** Cause 1 → use `name` from `product list`. Cause 2 → fix JSON (validate with `jq`). Cause 3 → switch to `enforcement: "Allow"`. Cause 4 → add `"values": ["*"]` to selector entries. Cause 5 → choose a different name. Cause 6 → regenerate from template via [configure-aops-policy-data-guide.md](../aops-policy/configure-aops-policy-data-guide.md).

package/skills/uipath-governance/references/diagnose/{references/troubleshooting-guide.md → troubleshooting-guide.md}

@@ -16,7 +16,7 @@ Determine whether the symptom belongs to AOps (product-layer) or Access (tool-us
 | "Policy create/update rejected" | Either | Step 5 (inspect definition) |
 | "Deployed-policy returns empty" | AOps | Step 2 (check deployed) |
 
-If the branch is unclear, ask the user: "Is this about product behavior (Studio/Robot features) or tool invocation (one workflow calling another)?" See [disambiguation-guide.md](../../disambiguation-guide.md).
+If the branch is unclear, ask the user: "Is this about product behavior (Studio/Robot features) or tool invocation (one workflow calling another)?" See [disambiguation-guide.md](../disambiguation-guide.md).
 
 ## Step 2: Check What's Deployed
 
@@ -98,7 +98,7 @@ List all active policies:
 uip gov access-policy list --filter "status in ('Active')" --output json
 ```
 
-Check whether a robot/external-app actor is involved — `actorRule` only matches `User`/`Group`. See [plugins/actor/impl.md](../../access-policy/plugins/actor/impl.md).
+Check whether a robot/external-app actor is involved — `actorRule` only matches `User`/`Group`. See [plugins/actor/impl.md](../access-policy/plugins/actor/impl.md).
 
 ## Step 5: Inspect the Policy Definition
 

package/skills/uipath-governance/references/disambiguation-guide.md

@@ -11,16 +11,24 @@ The two branches:
 
 **Before evaluating Branch A / B signals**, check for compliance standard framing:
 
-If the request contains a **standard name** (`ISO 42001`) **AND** a scope-limiting phrase (`just that area`, `only that part`, `not the whole standard`, `just that control`, `just the traceability`, `only the AI provider controls`, `just that compliance piece`), it is a **partial-apply** request regardless of whether the content words also match a Branch A model-gate signal.
+A **standard name** is any name resolving to a pack in `catalog list` — `ISO 42001` / `ISO/IEC 42001` / `AI Management System`, `ISO 27001` / `ISO/IEC 27001` / `ISMS` / `Information Security Management System`, `GDPR`, `HIPAA`, `SOC 2`, `EU AI Act`, or a bare standard number. Routing here does not mean the standard is usable: some catalog entries are announced with no bundle behind them. Which ones differ by environment, so the compliance flow reads it from `catalog list` and tells the user — never assume from the name. More than one standard is available, so the standard name is a routing signal, never an assumption: resolve which one via [`compliance-pack/catalog/impl.md` § Pack ID lookup](./compliance-pack/catalog/impl.md#pack-id-lookup) before running any pack-scoped command.
+
+If the request contains a **standard name** **AND** a scope-limiting phrase (`just that area`, `only that part`, `not the whole standard`, `just that control`, `just the traceability`, `only the AI provider controls`, `just that compliance piece`), it is a **partial-apply** request regardless of whether the content words also match a Branch A model-gate signal.
+
+The content-word rows below are examples of the shape, not a closed list — the standard name plus a scope phrase is what routes, whatever the subject matter. Clause topics differ per standard (42001 is AI-management-shaped; 27001 is information-security-shaped), so never infer the standard from the content words.
 
 | Request shape | Route |
 |---|---|
-| ISO 42001 + "make AI usage traceable / logged" + "not the full standard" | Compliance standard → partial-apply (AITrustLayer traceability clauses) |
-| ISO 42001 + "lock down AI model providers / approved providers" + "just that control" | Compliance standard → partial-apply (AITrustLayer model-governance clauses) |
-| ISO 42001 + "robot allowlists / URL allowlists / application allowlists" + scoped | Compliance standard → partial-apply (Robot UIAutomation clauses) |
-| ISO 42001 + no scope-limiting phrase | Compliance standard → full-apply or posture check |
-
-Do **not** route ISO 42001 + model/traceability intents to `aops-policy` directly — even though those intents look like Branch A model-gate signals, the standard-framing signals the catalog-based path that understands which clauses apply.
+| standard name + "make AI usage traceable / logged" + "not the full standard" | Compliance standard → partial-apply (traceability clauses) |
+| standard name + "lock down AI model providers / approved providers" + "just that control" | Compliance standard → partial-apply (AITrustLayer model-governance clauses) |
+| standard name + "robot allowlists / URL allowlists / application allowlists" + scoped | Compliance standard → partial-apply (Robot UIAutomation clauses) |
+| standard name + "access control / who can sign in / least privilege" + scoped | Compliance standard → partial-apply (access-control clauses) |
+| standard name + "audit logging / retention / evidence trail" + scoped | Compliance standard → partial-apply (logging clauses) |
+| standard name + "encryption / crypto / secrets handling" + scoped | Compliance standard → partial-apply (cryptography clauses) |
+| standard name + no scope-limiting phrase | Compliance standard → full-apply or posture check |
+| Compliance framing with NO standard name ("check my compliance posture", "am I compliant") | Compliance standard → resolve which standard first (ask, listing `catalog list` packs), then route |
+
+Do **not** route a standard name + model/traceability/access-control intent to `aops-policy` directly — even though those intents look like Branch A signals, the standard-framing signals the catalog-based path that understands which clauses apply.
 
 ## Strong signals — Branch A (AOps)