> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lumos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Role Mining Prompts

## Overview

Role mining in Albus follows a **layered approach**: start broad and add specificity only where the data justifies it. Each prompt uses a **birthright threshold** — the assignment % above which an app or entitlement should be granted automatically rather than requested. Higher thresholds mean stricter recommendations.

You'll work with two matrix types depending on the app:

* An **access matrix** answers *"which apps should this group of people get?"* Use it for license-based apps where having the license is the whole story — Zoom, Slack, Notion, 1Password.
* A **permissions matrix** answers *"which roles, groups, or entitlements within an app should this group get?"* Use it for apps with meaningful internal permission structures — Salesforce, Okta, AWS, GitHub, ServiceNow.

Customize the `[bracketed]` placeholders to match your environment — use whichever HR attribute names you actually have (Department, Business Unit, Cost Center, Team, Subsidiary, etc.). The example thresholds (80% / 70% / 60%) are a good starting point; adjust higher for stricter policies or lower if you want more apps surfaced as birthright candidates.

## Attribute Recommendations

Before building any matrix, ask Albus which attributes in your identity data actually predict access. The `/user-attribute-selection` skill scores every grouping attribute you have configured and returns a layered birthright, pre-approved and self-service model. It proposes a plan first and waits for your approval before running.

| **Label** | **Prompt** | **Expected Output** | **Value** |
| - | - | - | - |
| Generate the recommendation | `Using /user-attribute-selection which attribute combinations are best for defining access policies?` | A short plan to approve, then a measured analysis of every grouping attribute in your tenant. | Grounds policy design in your own data rather than an assumption about which attributes matter. |
| Approve the plan  (Click Approve CTA) | `This plan looks good, go ahead.` | Albus runs the full analysis and returns the recommended attribute set, a scorecard, and a coverage estimate. | The skill pauses before a long run so you can adjust the scope first. |
| Add context on the scale you expect | `We are an enterprise organization and I expect a sizable number of access policies. Show me what a finer, team-level attribute adds beyond the top anchor.` | A re-measure on absolute and residual contribution, showing what a finer attribute adds beyond the top anchor. | Albus tailors the analysis to the context you give it. Telling it the scale you are planning for gets you a deeper cut on the team-level layers. |
| Review the recommendation | `Give me a clear overview of the attribute combinations you recommend for building access policies. Use helpful diagrams eg. mermaid diagrams and explain why an attribute was valid or not.` | The recommended combinations, a diagram of how the layers stack, and the case for and against each attribute. | The reasoning is what you take into a working session, not just the answer. |
| Save the analysis | `Save the report to my Knowledge Hub.` | The analysis is written to your Knowledge Hub so later threads can read it. | Future conversations reference the same report instead of rerunning the analysis. |
| Check coverage before building | `What % of access can I cover with layers 1 and 2?` | The share of existing access captured as birthright, pre-approved, and self-service. | Tells you how much a policy set covers before you build a single policy. |

## Building Access Matrices (app-level)

| **Label** | **Prompt** | **Expected Output** | **Value** |
| - | - | - | - |
| Step 1 — the universal base | `let's do a matrix for the everyone attribute` | A single-column matrix across all active staff, showing the apps nearly everyone already holds. | Establishes the base so every layer after it only shows what it adds. |
| Step 2 — the top org layer | `yes let's drill into [top-level org attribute]` | The matrix for that layer across your business units. | Albus offers this at the end of the attribute overview, so you can answer in a few words. |
| Step 3 — the team layer | `let's drill into [team attribute], filter out apps from the layer before` | The team-level matrix, showing only access the layer above did not already grant. | Without the filter each layer repeats the apps above it and you cannot see what the layer contributes. |
| Step 4 — the carve-outs | `now let's do [carve-out attribute], filter out apps from the layers before` | The carve-out matrix, for example contingent workers or a region. | Completes the layered model. Albus keeps offering the next layer, so you can also just reply next. |
| Layer 1 — baseline by Employee Type | `Show me an access matrix for users with employee type = FTE with assignment % > 30%. Use birthright threshold of 80%.` | An access matrix for FTEs across all apps, with birthright vs. self-service recommendations. | Establish the company-wide baseline every full-time employee should get on Day 1. |
| Layer 2 — by department or business unit | `Show me an access matrix for users with [department attribute] = [Department Name] with assignment % > 30%. Use birthright threshold of 80%.`    Optional add below:  `Exclude apps already marked birthright above.` | An access matrix scoped to the department, showing incremental apps beyond the Layer 1 baseline. | Capture team-specific apps (Engineering → GitHub, Sales → Salesforce) without duplicating the company baseline. |
| Layer 3 — by team (only if needed) | `Show me an access matrix for users with [team attribute] = [Team Name] with assignment % > 30%. Use birthright threshold of 70%.`    Optional add below:  `Exclude apps already marked birthright above.` | An access matrix for the team, showing only the long-tail apps unique to that team. | Add team-level granularity for specialized tooling (e.g., Security → Datadog admin) without over-fragmenting policies. |
| Split by a secondary attribute | `Show me an access matrix for users with [attribute] = [Value] split by [secondary attribute].` | A matrix where rows are apps and columns are the distinct values of the secondary attribute. | Compare access patterns across subsidiaries, regions, or sub-teams in one view. |

## Building Permissions Matrices (entitlement-level)

| **Label** | **Prompt** | **Expected Output** | **Value** |
| - | - | - | - |
| Permissions matrix — by Employee Type | `Show me a permissions matrix for [App Name] for users with employee type = FTE with assignment % > 20%. Use birthright threshold of 80%. Exclude groups containing '_dl', 'location', or 'all-employees'.` | An entitlement-level matrix showing which groups, roles, or profiles should be birthright across the FTE population. | Define the right level of access inside an app, not just whether someone gets the license. |
| Permissions matrix — by department or team | `Show me a permissions matrix for [App Name] for users with [department attribute] = [Department Name] with assignment % > 20%. Use birthright threshold of 70%. Exclude entitlements already marked birthright at Layer 1.` | A department- or team-scoped entitlement matrix layered on top of the Layer 1 baseline. | Handle apps like Salesforce where Sales needs profiles other departments don't, or where one engineering sub-team needs admin roles. |
| Permissions matrix — filtered by entitlement name | `Show me a permissions matrix for [App Name] filtered to groups with [prefix] in the name.` | An entitlement-level matrix limited to the groups matching that naming pattern. | Cuts a large app down to the entitlement family you care about instead of every group it has. |
| Find the groups that actually hold the access | `Find user groups with the highest [App Name] assignment percentages.` | Assigned over total per cohort, at both department and cost-centre grain, ignoring groups under ten members. | Scope the matrix to teams that genuinely hold the access rather than reading a wall of self-service. |
| Lower the bar on sparse access | `Lower birthright % to 20.` | The matrix re-rendered, showing which entitlements qualify at a lower threshold. | Role-specific apps rarely clear 80% in any team. Qualifying only at 20% signals pre-approval, not birthright. |
| Test whether a finer attribute helps | `Does adding [attribute] as a combo attribute help increase percentages?` | A comparison showing whether the combination concentrates the cohorts or fragments them. | A finer attribute only lifts percentages when it lines up with who holds the access. Usually it does not. |

## \[Optional] Decision Helpers

| **Label** | **Prompt** | **Expected Output** | **Value** |
| - | - | - | - |
| Decide policy depth (5-user rule) | `For my access policies: if only one team in a department has 5+ users and all others have <5, build at department level. If two or more teams have 5+ users, build at department + team level. Show both groups as tree diagrams with user counts.` | Two grouped trees — departments to handle at department level vs. departments to break out by team. | Avoid over-fragmenting (one policy per tiny team) and under-fragmenting (one policy hiding real variance). |
| Compare attribute granularity | `Do sub-teams under [Department Name] have meaningfully different access? Compare the access matrix at the department level vs. the team level for this department.` | A side-by-side or summary showing whether breaking out by team surfaces meaningfully different access. | Know when to stop adding layers — if the deeper level looks the same, don't build it. |

## Teaching Albus Your Environment

| **Label** | **Prompt** | **Expected Output** | **Value** |
| - | - | - | - |
| Teach a naming convention | `Remember: any group name containing '_dl' is a distribution list and should be excluded from permissions matrices by default.` | Confirmation Albus has stored the rule; future matrices apply it automatically. | Train Albus on your conventions once instead of repeating exclusions every prompt. |
| Teach a location pattern | `Remember: groups starting with a country or city name (e.g., 'usa_', 'london_') are location-based distribution lists, not access controls.` | Confirmation the rule is stored. | Filter out noise from location-based groups across every future matrix. |
| Teach an exclusion rule | `Remember: apps labeled "deprecated" should never appear in birthright recommendations.` | Confirmation the rule is stored. | Keep retired apps out of policy recommendations. |
| Exclude an app entirely | `Remember: ignore [App Name] and exclude it from matrices.` | Confirmation the app will be filtered from future matrices. | Pull noisy or out-of-scope apps (sandboxes, test environments, internal tools) out of every recommendation. |

## Gap and Coverage Analysis

| **Label** | **Prompt** | **Expected Output** | **Value** |
| - | - | - | - |
| Identify gaps in existing policies | `Identify potential gaps in existing access policies by analyzing application assignment coverage. Look for apps assigned to 60–90% of [employee group] — that range often indicates a missing policy.` | A table of apps with partial coverage, with coverage % and a suggestion for whether to promote to birthright. | Surface near-birthright apps that should be promoted, and inconsistencies in current assignments. |
| Top-requested apps segmentation | `For the top 5 most-requested apps in the last quarter, show me recommended access policy segmentation and the rationale for each.` | A breakdown of the top 5 apps with proposed segmentation and reasoning grounded in request data. | Prioritize policy work where it eliminates the most tickets. |
| Find apps missing access groups | `Looking at my Okta apps, which entitlements are missing a corresponding access group? Use the naming convention "APP-[app name]" to check.` | A list of Okta apps without a backing access group. | Prep work for moving birthright orchestration off of IdP rules and into Lumos policies. |