# SKOS TAXONOMY EXTRACTOR™ v1.1 --- ## PRE-FLIGHT CHECK All four INPUT fields are present and populated. No HALT conditions detected. No FLAG conditions detected. Proceeding to extraction. --- ## SECTION 1 — CORPUS PROFILE ``` CORPUS TYPE: document ESTIMATED SCOPE: ~170 words DOMAIN: Identity and Access Management (IAM) policies within an enterprise IT security program. Scope includes account lifecycle, access controls, and policy enforcement. Excludes network security and endpoint protection. STAKES: HIGH (domain is enterprise IT security) DEPTH REQUESTED: standard (3 levels) OUTPUT FORMAT: plain-labeled SUBJECT CLUSTERS: 1. Account lifecycle management (quarterly review, inactive accounts, deprovisioning, temporary access, service accounts) 2. Access control governance (RBAC, privileged access, manager approval, SoD) 3. Authentication requirements (two-factor authentication, service accounts) 4. Policy enforcement and incident management (policy violations, security incidents, IT tickets, notifications) 5. Access request process (access request form, documentation, approval workflow) PRIMARY CLUSTER: Account lifecycle management — governs the largest share of corpus sentences and anchors the other clusters. ``` No contradiction detected between DOMAIN specification and corpus content. --- ## SECTION 2 — CONCEPT CANDIDATE INVENTORY ``` CANDIDATE: Access Review EVIDENCE: "All user accounts must be reviewed quarterly under the access review policy." FREQUENCY: 2–4 times (also implied by quarterly review cadence) STATE: CONFIRMED CANDIDATE: Privileged Access EVIDENCE: "Privileged access is granted only after manager approval and documented in the access request form." FREQUENCY: 2–4 times STATE: CONFIRMED CANDIDATE: Access Request Form EVIDENCE: "Privileged access is granted only after manager approval and documented in the access request form." FREQUENCY: Appears once with substantial definitional context STATE: CONFIRMED CANDIDATE: Temporary Access EVIDENCE: "Temporary access expires automatically after 30 days." FREQUENCY: Appears once with substantial definitional context STATE: CONFIRMED CANDIDATE: Service Account EVIDENCE: "Service accounts require two-factor authentication." FREQUENCY: 2–4 times (referenced in authentication and deprovisioning contexts) STATE: CONFIRMED CANDIDATE: Two-Factor Authentication EVIDENCE: "Service accounts require two-factor authentication." FREQUENCY: Appears once with substantial definitional context STATE: CONFIRMED CANDIDATE: Deprovisioning EVIDENCE: "Accounts inactive for 90 days are flagged for deprovisioning. The deprovisioning workflow triggers an IT ticket." FREQUENCY: 2–4 times STATE: CONFIRMED CANDIDATE: Role-Based Access Control (RBAC) EVIDENCE: "Role-based access control (RBAC) governs permissions across all production systems." FREQUENCY: Appears once with substantial definitional context STATE: CONFIRMED CANDIDATE: Separation of Duties (SoD) EVIDENCE: "Separation of duties (SoD) is enforced for finance and payroll systems." FREQUENCY: Appears once with substantial definitional context STATE: CONFIRMED CANDIDATE: Policy Violation EVIDENCE: "Policy violations are logged as security incidents under Incident Category: SEC-VIOL." FREQUENCY: Appears once with substantial definitional context STATE: CONFIRMED CANDIDATE: Security Incident EVIDENCE: "Policy violations are logged as security incidents under Incident Category: SEC-VIOL." FREQUENCY: Appears once with substantial definitional context STATE: CONFIRMED CANDIDATE: Deprovisioning Workflow EVIDENCE: "The deprovisioning workflow triggers an IT ticket (Ticket Type: IAM-DEPR) and notifies the account owner via email." FREQUENCY: Appears once with substantial definitional context STATE: CONFIRMED CANDIDATE: Manager Approval EVIDENCE: "Privileged access is granted only after manager approval." FREQUENCY: Appears once STATE: INSUFFICIENT EVIDENCE REASON: Appears once as a process prerequisite for privileged access; no further context or process definition provided in corpus to constitute a standalone concept. CANDIDATE: Inactive Account EVIDENCE: "Accounts inactive for 90 days are flagged for deprovisioning." FREQUENCY: Appears once STATE: AMBIGUOUS REASON: Appears as a trigger condition for deprovisioning rather than as a defined concept in its own right; unclear whether it represents a distinct account state or is simply a threshold parameter of the deprovisioning rule. CANDIDATE: IT Ticket EVIDENCE: "The deprovisioning workflow triggers an IT ticket (Ticket Type: IAM-DEPR)." FREQUENCY: Appears once STATE: OUT OF SCOPE REASON: IT ticketing is an IT service management concept; the corpus references it only as an output mechanism of the deprovisioning workflow, and the DOMAIN explicitly scopes to IAM policies — not IT service management tooling. ``` --- ## SECTION 3 — SKOS CONCEPT SCHEME ``` ConceptScheme: Identity and Access Management (IAM) Taxonomy scopeNote: "Taxonomy extracted from a document corpus. Domain: Identity and Access Management (IAM) policies within an enterprise IT security program. Scope includes account lifecycle, access controls, and policy enforcement. Excludes network security and endpoint protection. Extraction date: 20 May 2026. All concepts are corpus-derived; see Section 6 for gap disclosure." ``` **Top Concepts (skos:topConceptOf):** - Account Lifecycle Management - Access Control - Policy Enforcement --- ``` ───────────────────────────────────────────────── CONCEPT: Account Lifecycle Management ───────────────────────────────────────────────── prefLabel: Account Lifecycle Management altLabel: (none) definition: The set of processes governing user accounts from provisioning through deprovisioning, including periodic review and status-based actions. | Evidence: "All user accounts must be reviewed quarterly under the access review policy" and "Accounts inactive for 90 days are flagged for deprovisioning." (INFERRED from corpus pattern — no single sentence defines the lifecycle as a whole; definition constructed from dominant corpus cluster) scopeNote: In this taxonomy, Account Lifecycle Management is the top concept anchoring all account-state and review processes. Authentication requirements attached to specific account types (e.g., Service Account) are treated as lifecycle properties, not as access control rules. notation: N/A: no codes present in corpus for this concept broader: top concept narrower: Access Review, Deprovisioning, Service Account, Temporary Access related: Access Control, Policy Enforcement Evidence basis: CONFIRMED — governs the largest subject cluster in the corpus ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Access Review ───────────────────────────────────────────────── prefLabel: Access Review altLabel: (none) definition: A mandatory periodic examination of all user accounts, conducted quarterly, to verify appropriateness of access. | Evidence: "All user accounts must be reviewed quarterly under the access review policy." (CORPUS-DERIVED) scopeNote: Scoped to the quarterly review cadence as defined in the corpus. Does not cover ad hoc or event-triggered reviews, which are not mentioned. notation: N/A: no codes present in corpus for this concept broader: Account Lifecycle Management narrower: none at this depth related: Deprovisioning, Policy Enforcement Evidence basis: CONFIRMED — explicit corpus statement with defined cadence and policy reference ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Deprovisioning ───────────────────────────────────────────────── prefLabel: Deprovisioning altLabel: (none) definition: The process of revoking account access for accounts that have been inactive for 90 days, initiated via a defined workflow. | Evidence: "Accounts inactive for 90 days are flagged for deprovisioning. The deprovisioning workflow triggers an IT ticket (Ticket Type: IAM-DEPR) and notifies the account owner via email." (CORPUS-DERIVED) scopeNote: In this taxonomy, Deprovisioning is scoped to inactivity-triggered revocation only. The corpus does not describe voluntary or role-change-driven deprovisioning. notation: IAM-DEPR (Ticket Type referenced in corpus) broader: Account Lifecycle Management narrower: Deprovisioning Workflow related: Access Review, Policy Enforcement Evidence basis: CONFIRMED — appears twice with process definition and a corpus-supplied notation code ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Deprovisioning Workflow ───────────────────────────────────────────────── prefLabel: Deprovisioning Workflow altLabel: (none) definition: The automated procedural sequence triggered when an account is flagged for deprovisioning, including IT ticket creation and account owner notification. | Evidence: "The deprovisioning workflow triggers an IT ticket (Ticket Type: IAM-DEPR) and notifies the account owner via email." (CORPUS-DERIVED) scopeNote: Scoped strictly to the two corpus-described steps: ticket creation and email notification. No further workflow steps are evidenced. notation: IAM-DEPR (associated Ticket Type) broader: Deprovisioning narrower: none at this depth related: Policy Enforcement Evidence basis: CONFIRMED — single sentence with substantial procedural definition ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Service Account ───────────────────────────────────────────────── prefLabel: Service Account altLabel: (none) definition: A non-personal account used by systems or applications, subject to two-factor authentication requirements. | Evidence: "Service accounts require two-factor authentication." (CORPUS-DERIVED; account type is inferred from contrast with user accounts — INFERRED for the non-personal qualifier) scopeNote: Placed under Account Lifecycle Management because the corpus characterises service accounts via their authentication and deprovisioning properties, not via access permissions. notation: N/A: no codes present in corpus for this concept broader: Account Lifecycle Management narrower: Two-Factor Authentication related: Deprovisioning Evidence basis: CONFIRMED — appears in corpus with a distinct mandatory control assigned to it ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Two-Factor Authentication ───────────────────────────────────────────────── prefLabel: Two-Factor Authentication altLabel: (none) definition: An authentication requirement mandating two verification factors, applied to service accounts. | Evidence: "Service accounts require two-factor authentication." (CORPUS-DERIVED) scopeNote: Scoped in this taxonomy to service accounts only. The corpus does not extend this requirement to user accounts or privileged access. notation: N/A: no codes present in corpus for this concept broader: Service Account narrower: none at this depth related: Access Control Evidence basis: CONFIRMED — single sentence with clear mandatory control definition; placed narrower under Service Account because corpus presents it as a property of that account type ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Temporary Access ───────────────────────────────────────────────── prefLabel: Temporary Access altLabel: (none) definition: A time-limited access grant that expires automatically after 30 days. | Evidence: "Temporary access expires automatically after 30 days." (CORPUS-DERIVED) scopeNote: Expiry is automatic per corpus. Relationship to the Access Request Form is not explicitly stated for temporary access — not inferred. notation: N/A: no codes present in corpus for this concept broader: Account Lifecycle Management narrower: none at this depth related: Privileged Access, Access Request Form Evidence basis: CONFIRMED — single sentence with explicit definitional property (30-day expiry) ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Access Control ───────────────────────────────────────────────── prefLabel: Access Control altLabel: (none) definition: The governance of permissions and access rights across systems, implemented via role-based models and duty-separation rules. | Evidence: "Role-based access control (RBAC) governs permissions across all production systems. Separation of duties (SoD) is enforced for finance and payroll systems." (INFERRED as top concept grouping two corpus-confirmed mechanisms) scopeNote: In this taxonomy, Access Control is the top concept for permission governance mechanisms. Account-level access properties (e.g., Temporary Access) are placed under Account Lifecycle Management, not here. notation: N/A: no codes present in corpus for this concept broader: top concept narrower: Role-Based Access Control, Separation of Duties, Privileged Access, Access Request Form related: Account Lifecycle Management, Policy Enforcement Evidence basis: CONFIRMED — corpus explicitly names two access control mechanisms (RBAC, SoD) and one access control process (privileged access grant) ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Role-Based Access Control ───────────────────────────────────────────────── prefLabel: Role-Based Access Control altLabel: RBAC definition: A permission model in which access rights are assigned based on roles, applied across all production systems. | Evidence: "Role-based access control (RBAC) governs permissions across all production systems." (CORPUS-DERIVED) scopeNote: (none — corpus usage aligns with standard meaning) notation: N/A: no codes present in corpus for this concept broader: Access Control narrower: none at this depth related: Separation of Duties Evidence basis: CONFIRMED — explicit definition and scope (production systems) provided in corpus ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Separation of Duties ───────────────────────────────────────────────── prefLabel: Separation of Duties altLabel: SoD definition: A control requiring that conflicting responsibilities be divided among different individuals, enforced for finance and payroll systems. | Evidence: "Separation of duties (SoD) is enforced for finance and payroll systems." (CORPUS-DERIVED) scopeNote: Scoped in this taxonomy to finance and payroll systems only, per corpus. Not stated as a universal control. notation: N/A: no codes present in corpus for this concept broader: Access Control narrower: none at this depth related: Role-Based Access Control, Policy Enforcement Evidence basis: CONFIRMED — explicit enforcement statement with named system scope ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Privileged Access ───────────────────────────────────────────────── prefLabel: Privileged Access altLabel: (none) definition: A category of elevated access that requires manager approval and formal documentation before being granted. | Evidence: "Privileged access is granted only after manager approval and documented in the access request form." (CORPUS-DERIVED) scopeNote: Distinct from Temporary Access: Privileged Access is defined by its approval requirement, not a time limit. The corpus does not state whether Privileged Access can also be temporary. notation: N/A: no codes present in corpus for this concept broader: Access Control narrower: none at this depth related: Access Request Form, Temporary Access Evidence basis: CONFIRMED — explicit grant condition and documentation requirement stated in corpus ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Access Request Form ───────────────────────────────────────────────── prefLabel: Access Request Form altLabel: (none) definition: A formal document used to record the approval and grant of privileged access. | Evidence: "Privileged access is granted only after manager approval and documented in the access request form." (CORPUS-DERIVED) scopeNote: Referenced only in the context of privileged access documentation. Not stated as the form for all access requests. notation: N/A: no codes present in corpus for this concept broader: Access Control narrower: none at this depth related: Privileged Access Evidence basis: CONFIRMED — single sentence with clear functional definition as documentation artefact ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Policy Enforcement ───────────────────────────────────────────────── prefLabel: Policy Enforcement altLabel: (none) definition: The detection, logging, and incident classification of IAM policy violations as security incidents. | Evidence: "Policy violations are logged as security incidents under Incident Category: SEC-VIOL." (CORPUS-DERIVED) scopeNote: In this taxonomy, Policy Enforcement is scoped to the logging and classification of violations. The corpus does not describe remediation or escalation beyond incident logging. notation: SEC-VIOL (Incident Category referenced in corpus) broader: top concept narrower: Policy Violation, Security Incident related: Account Lifecycle Management, Access Control Evidence basis: CONFIRMED — explicit logging and classification rule with corpus-supplied notation code ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Policy Violation ───────────────────────────────────────────────── prefLabel: Policy Violation altLabel: (none) definition: A breach of IAM policy rules that triggers classification as a security incident. | Evidence: "Policy violations are logged as security incidents under Incident Category: SEC-VIOL." (CORPUS-DERIVED) scopeNote: (none — corpus usage is direct) notation: SEC-VIOL (Incident Category under which violations are logged) broader: Policy Enforcement narrower: none at this depth related: Security Incident, Access Review Evidence basis: CONFIRMED — explicit statement linking violations to security incident classification ───────────────────────────────────────────────── ───────────────────────────────────────────────── CONCEPT: Security Incident ───────────────────────────────────────────────── prefLabel: Security Incident altLabel: (none) definition: A logged event resulting from an IAM policy violation, classified under a defined incident category. | Evidence: "Policy violations are logged as security incidents under Incident Category: SEC-VIOL." (CORPUS-DERIVED) scopeNote: In this taxonomy, Security Incident is scoped to IAM policy violation outcomes only. The corpus does not describe other incident types within this text. notation: SEC-VIOL (Incident Category assigned in corpus) broader: Policy Enforcement narrower: none at this depth related: Policy Violation, Deprovisioning Workflow Evidence basis: CONFIRMED — explicitly named as the output classification of a policy violation ───────────────────────────────────────────────── ``` --- ## SECTION 4 — HIERARCHY MAP ``` IAM Taxonomy ├── Account Lifecycle Management │ ├── Access Review │ ├── Deprovisioning │ │ └── Deprovisioning Workflow │ ├── Service Account │ │ └── Two-Factor Authentication │ └── Temporary Access ├── Access Control │ ├── Role-Based Access Control │ ├── Separation of Duties │ ├── Privileged Access │ └── Access Request Form └── Policy Enforcement ├── Policy Violation └── Security Incident ``` ``` RELATED LINKS (skos:related): Account Lifecycle Management ↔ Access Control | Evidence: "Privileged access is granted only after manager approval" connects access grant process to lifecycle Account Lifecycle Management ↔ Policy Enforcement | Evidence: "All user accounts must be reviewed quarterly under the access review policy" — review is a policy enforcement mechanism over lifecycle events Access Control ↔ Policy Enforcement | Evidence: "Separation of duties (SoD) is enforced" — SoD is both an access control mechanism and a policy mandate Two-Factor Authentication ↔ Access Control | Evidence: "Service accounts require two-factor authentication" — authentication is a condition of access Privileged Access ↔ Temporary Access | Evidence: Both are distinct access grant types; corpus describes each with different grant conditions and time properties Privileged Access ↔ Access Request Form | Evidence: "documented in the access request form" — form is the procedural artefact of the privileged access grant Policy Violation ↔ Security Incident | Evidence: "Policy violations are logged as security incidents" — direct co-occurrence with causal link Policy Violation ↔ Access Review | Evidence: Quarterly review is the detection mechanism for potential violations (INFERRED from proximity — weak link; flagged) Security Incident ↔ Deprovisioning Workflow | Evidence: Both produce documented outputs (IT ticket, incident log) as enforcement actions ``` --- ## SECTION 5 — LABEL REGISTER ``` PREFERRED LABELS (skos:prefLabel): Account Lifecycle Management → Account Lifecycle Management | Corpus frequency: inferred cluster Access Review → Access Review | Corpus frequency: 2–4 Deprovisioning → Deprovisioning | Corpus frequency: 2–4 Deprovisioning Workflow → Deprovisioning Workflow | Corpus frequency: 2–4 Service Account → Service Account | Corpus frequency: 2–4 Two-Factor Authentication → Two-Factor Authentication | Corpus frequency: 2–4 Temporary Access → Temporary Access | Corpus frequency: 2–4 Access Control → Access Control | Corpus frequency: inferred cluster Role-Based Access Control → Role-Based Access Control | Corpus frequency: 2–4 Separation of Duties → Separation of Duties | Corpus frequency: 2–4 Privileged Access → Privileged Access | Corpus frequency: 2–4 Access Request Form → Access Request Form | Corpus frequency: 2–4 Policy Enforcement → Policy Enforcement | Corpus frequency: inferred cluster Policy Violation → Policy Violation | Corpus frequency: 2–4 Security Incident → Security Incident | Corpus frequency: 2–4 ALTERNATIVE LABELS (skos:altLabel): Role-Based Access Control → RBAC | Found in: parenthetical abbreviation in corpus sentence Separation of Duties → SoD | Found in: parenthetical abbreviation in corpus sentence ``` No alternative labels identified for any other concepts — altLabel omitted for all remaining entries. ``` REJECTED LABELS: "access review policy" → Rejected: compound noun phrase used to name the governing policy document, not the review activity itself. | Replaced by: Access Review "inactivity-based deprovisioning" → Rejected: constructed compound not present in corpus as a discrete term. | Replaced by: Deprovisioning (with inactivity threshold captured in definition) ``` --- ## SECTION 6 — GAP DISCLOSURE **Concept gaps:** ``` GAP TYPE: INSUFFICIENT EVIDENCE TERM: Manager Approval EVIDENCE: "Privileged access is granted only after manager approval." REASON DEFERRED: Appears once as a prerequisite condition for privileged access; no process definition, approval chain, or further context is provided. Insufficient evidence to constitute a standalone concept. RESOLUTION PATH: Provide corpus text that describes the manager approval process, approval chain, or approval documentation requirements as a defined activity — then it can be confirmed as a narrower concept under Privileged Access. GAP TYPE: AMBIGUOUS TERM: Inactive Account EVIDENCE: "Accounts inactive for 90 days are flagged for deprovisioning." REASON DEFERRED: Appears as a threshold trigger condition rather than a defined account state. Unclear whether the corpus treats it as a named account status (analogous to a lifecycle state) or merely a parameter of the deprovisioning rule. Placing it in the hierarchy would require a forced inference about its ontological type. RESOLUTION PATH: If the IAM policy documentation explicitly defines "inactive" as a named account state (e.g., in a status table or account state model), provide that text. The concept could then be confirmed as a narrower concept under Account Lifecycle Management. GAP TYPE: OUT OF SCOPE TERM: IT Ticket EVIDENCE: "The deprovisioning workflow triggers an IT ticket (Ticket Type: IAM-DEPR)." REASON DEFERRED: IT ticketing belongs to IT Service Management (ITSM), not IAM policy. The corpus references it only as an output mechanism of the Deprovisioning Workflow. DOMAIN explicitly excludes tooling outside IAM policy scope. RESOLUTION PATH: If the intent is to model the integration between IAM policy enforcement and ITSM tooling, adjust the DOMAIN specification to include IT service management, or treat ITSM as a separate taxonomy scope and link via skos:related at the scheme level. ``` **Depth flags:** No depth flags. Standard 3-level hierarchy was achievable for all confirmed top concepts. The following concepts reached a natural evidenced depth of 2 levels (no narrower concepts supported by corpus): - Access Review (level 2 — no level 3 evidence) - Temporary Access (level 2 — no level 3 evidence) - Role-Based Access Control (level 2 — no level 3 evidence) - Separation of Duties (level 2 — no level 3 evidence) - Privileged Access (level 2 — no level 3 evidence) - Access Request Form (level 2 — no level 3 evidence) - Policy Violation (level 2 — no level 3 evidence) - Security Incident (level 2 — no level 3 evidence) This is not a depth failure — it reflects the corpus scope. No depth flag is raised because the standard depth ceiling was not breached; the corpus simply does not provide level-3 material for these branches. **Open-world notice:** "This taxonomy reflects concepts present in the provided corpus. Domain concepts not mentioned in the corpus are not represented here. Absence of a concept does not mean it is absent from the domain — it means the provided corpus did not surface it. Review the taxonomy against domain knowledge before deploying in a production system." **Refused inferences:** ``` REFUSED: Assigning skos:broader of "Privileged Access" to "Temporary Access" (i.e., treating temporary access as a subtype of privileged access). REASON: The corpus defines them independently. Privileged Access is defined by its approval requirement; Temporary Access is defined by its 30-day expiry. No corpus sentence states or implies that temporary access is a form of privileged access. The inference would rely on general world knowledge, not corpus evidence. REFUSED: Treating "Manager Approval" as a narrower concept under "Access Request Form." REASON: The corpus mentions both in the same sentence but does not establish a hierarchical relationship. Manager Approval is a prerequisite condition; the Access Request Form is a documentation artefact. Constructing a broader/narrower link between them would be a structural inference not supported by the corpus text. REFUSED: Extending "Security Incident" to cover events beyond policy violations (e.g., breach events, malware incidents). REASON: The corpus defines Security Incident solely as the classification output of a policy violation. Broadening it to cover other incident types would introduce domain knowledge not present in the corpus and would exceed the stated DOMAIN scope, which excludes network security and endpoint protection. REFUSED: Adding skos:broader relationship between "Policy Violation" and "Access Review" (i.e., treating violations as a subtype of review outcome). REASON: The corpus does not state that policy violations are detected through access reviews. The co-occurrence link surfaced as a weak related link in Section 4; it does not support a hierarchical relationship. The inference was considered and refused. ``` --- ## SECTION 7 — DOWNSTREAM COMPATIBILITY **→ Prompt Ontology Designer™ v1.0** Pass the plain-labeled concept list from Section 3 as `{EXISTING_VOCABULARY}` input. Use prefLabels as vocabulary terms (e.g., "Role-Based Access Control", "Deprovisioning", "Policy Violation"). Include scope notes where corpus meaning is narrower than general usage — particularly for Security Incident (scoped to IAM violations only) and Separation of Duties (scoped to finance and payroll systems only). AMBIGUOUS entry "Inactive Account" and INSUFFICIENT EVIDENCE entry "Manager Approval" from Section 6 are not ready for `{EXISTING_VOCABULARY}` — resolve them first using the resolution paths provided. **→ RAG Evaluation Ontology™ v1.0** Pass the three top concept names — Account Lifecycle Management, Access Control, and Policy Enforcement — as entity type seeds for `{DOMAIN_AND_CORPUS}`. These provide named entity types for IAM-domain retrieval evaluation. The notation codes (IAM-DEPR, SEC-VIOL) can serve as structured identifiers for entity recognition test cases, as they appear verbatim in the corpus and are likely to recur in production IAM documentation. **→ Ontology-Guided SysPrompt™ v1.0** This output is not directly compatible with the SysPrompt builder. Run it through Prompt Ontology Designer™ first to generate the XML ontology block. The SysPrompt builder requires the typed ontology primitives (Object, Event, State, Role, Constraint) that the Prompt Ontology Designer produces from the SKOS vocabulary as input. **Chain note:** AMBIGUOUS entries in Section 6 of this output become unresolved vocabulary items in downstream products. Do not attempt to use AMBIGUOUS concepts (Inactive Account) or INSUFFICIENT EVIDENCE concepts (Manager Approval) in the Prompt Ontology Designer or RAG Evaluation Ontology without resolving them first. If an AMBIGUOUS concept is used as `{EXISTING_VOCABULARY}`, it will produce SPECULATIVE confidence ratings and may generate ontology entries with no reliable evidence basis.