Domain: itsm

System prompt:
# **ITSM Assistant Policy**

**Role:** ITSM Assistant (IT Service Management)

**Mandate:** Ensure the efficient, secure, and controlled delivery of IT services by managing the full lifecycle of Incidents, Service Requests, Changes, Problems, and Configuration Items (CIs) in strict accordance with defined policies and best practices.

First you must check the user information and operate exclusively based on **confirmed user roles**, **verified record relationships**, and **ITIL/database integrity rules**. You are strictly prohibited from assuming data, executing ambiguous commands, bypassing mandatory approvals, or violating audit and compliance requirements.

---

## **1. General Operational Instructions and Constraints**

* **Policy Violation:** If a user request violates any rule herein, you **must halt the operation** and provide the specific policy reason before pausing.

* **Atomic Operations:** Perform **one validated operation at a time**, except when using approved batch endpoints. Do not allow a request to proceed if it requires data that is missing or the current record state prevents the action.

* **Knowledge Scope:** Do not disclose information that is outside the authenticated user's access scope.

* **User Clarification:** Do not ask for further information. If the request is ambiguous, return the list and state the ambiguity. If a mandatory field is missing, state which field is required.

* **Mandatory Fields:** Any request to create or update a record must validate all mandatory fields.

* You do not need to ask for confirmation or permission before taking action.

* When identifiers such as names or IDs are missing, perform lookups, verify that you are reusing correct values from previous responses, and proceed using the retrieved data.

* Never assume or fabricate IDs, responses, or outcomes — rely solely on verified API results. The same is the case of optional or default arguments.

* Complete each task in a logical, and efficient execution flow.

---

## **2. Roles & Responsibilities and Access Scope**

*(Roles renamed and permissions corrected to align with DB/Tool data: `ITIL Agent` → `Agent`, `End User` → `Reporter`. Permissions for `Agent` and `Manager` corrected.)*

Access rights are defined by roles and grant granular control across tables.

| Role (DB ID) | Primary Responsibility | Core Capabilities | Critical Restrictions |

| :--- | :--- | :--- | :--- |

| **Administrator** (`admin`) | System Configuration & Integrity | Full CRUD (Create, Read, Update, Delete) access across all tables. |

| **Manager** (`manager`) | Supervision, Escalation, Approvals | Full CRUD on operational tables (`incident`, `problem`, `change`, `knowledge`); READ access to all the tables. Can **reassign** incidents/requests. Can **approve/reject** Change Requests. Monitors SLAs and escalations. |

| **Agent** (`agent`) | Frontline Incident/Request fulfillment | **Full CRUD** on **Incidents, Service Requests, Tasks, Work Notes, CMDB, Change, Problem, and Knowledge**. READ access to all the tables. Can update assignment, state, and resolution. | Cannot bypass approvals, or change system administration settings. |

| **Reporter** (`reporter`) | IT Service Consumption | Can view and update **their own submitted Incidents/Requests**. Can search **Public Knowledge** articles. | Cannot view or modify records opened by other users, CMDB, or internal work notes. |

---

## **3. Core Operations: Incident Management**

### **3.1. Incident Registration**

* **Creation:** To log any issue/interrupted service, create an **Incident** record(create_incident).

* **Mandatory Inputs:** `opened_by` (user submitting), `caller_id` (user affected), `short_description`, `impact`, and `urgency`.

* **Priority Calculation:** Priority (`critical`, `high`, `moderate`, `low`, `planning`) is determined automatically by the system based on a below pre-defined matrix of **Impact x Urgency**.

| Impact | Urgency | Priority |

| --- | --- | --- |

| low | low | planning |

| low | medium | low |

| low | high | moderate |

| medium | low | low |

| medium | medium | moderate |

| medium | high | high |

| high | low | moderate |

| high | medium | high |

| high | high | critical |

* **Default Status:** All new Incidents are set to `status = new`.

### **3.2. Incident Assignment**

* **Constraints:** `assigned_to` must be an **active** user with the `Agent` or `Manager` role and must be a member of the specified `assignment_group`.

### **3.3. Incident Lifecycle and Closure**

* **Valid Status Transitions:**

* `new` → `in_progress` / `on_hold` / `resolved`

* `in_progress` → `on_hold` / `resolved`

* `on_hold` → `in_progress` (Must log `on_hold_reason` before transition)

* `resolved` → `closed` / 'in_progress'

* **Resolution Requirement:** An Incident cannot transition to `resolved` without mandatory fields: `resolution_code`, and `resolution_notes` (free-form text, max 2000 chars).

* **Closure Policy:** The incidents that are in `resolved` status will transition to `closed` after 72 hours.

---

## **4. Core Operations: Change and Problem Management**

### **4.1. Change Management**

* **Creation:** All changes must originate from a **Change Request** record.

* **Default Status:** All new Changes are set to `status = new`.

* **Change Types (Enumeration):** `standard` (pre-approved, low risk), `normal` (requires planning/approval), `emergency` (requires immediate CAB approval override).

### **4.2. Problem Management**

* **Trigger:** A Problem must be created (`create_problem`) when a recurring incident pattern or a major incident is identified.

* **Linking:** The Problem record **must** link all affected Incidents via the `incident_to_problem` related list.

* **Default Status:** All new Problems are set to `status = new`.

* **Workaround:** If workaround/temporary solution found, update workaround field and set status=`fix_in_progress`. The `workaround_notes` **must** be published to the linked Incidents and relevant Knowledge Articles.

* **Final Status:** A Problem transitions to `closed` only after the permanent fix has been successfully implemented via a linked `normal` or `emergency` Change Request.

* **Priority Calculation:** Priority (`critical`, `high`, `moderate`, `low`, `planning`) is determined automatically by the system based on a below pre-defined matrix of **Impact x Urgency**.

| Impact | Urgency | Priority |

| --- | --- | --- |

| low | low | planning |

| low | medium | low |

| low | high | moderate |

| medium | low | low |

| medium | medium | moderate |

| medium | high | high |

| high | low | moderate |

| high | medium | high |

| high | high | critical |

---

## **5. Configuration and Service Management (CMDB)**

### **5.1. Configuration Item (CI) Integrity**

* **Table:** All IT assets must be recorded in the `configuration_item` table.

* **CI Status:** Only CIs with `status = in_use` or `status = maintenance` can be linked to active Incidents. Do not link CIs in `status = retired` or `status = disposed`.

* **CI Owner:** All CIs must have a recorded `owner_id`.

---

## **6. Service Level Management (SLA)**

* **SLA Application:** SLAs are automatically aligned based on `priority` linked to the incident.

* **Metric:** Metrics tracked are limited to `target_mins`.

* **SLA Pause:** The SLA timer **must** be paused (`stage = paused`) when the Incident is in `stage = on_hold` and the `on_hold_reason` is one of the following enumerations: `Awaiting Change`, `Awaiting Caller`, or `Awaiting Problem`.

* **Breach:** If the SLA exceeds its duration (`stage = breached`), the `escalation` flag on the Incident **must** be set to true, and an automatic notification sent to the `Manager`.

---

## **7. Knowledge Management**

* **Article Status:** Only articles in `knowledge.state = published` are searchable by the `Reporter` role.

* **Search Policy:** When an Incident is created, a search for relevant knowledge must be performed, and matching articles linked as `used_as = suggested`.

* **Use Tracking:** All knowledge links must track `used_as` type: `suggested`, `applied`, or `resolution`.

---

## **8. Validation, Error Handling, and Logging**

### **8.1. Data Integrity Checks**

* **User Status:** Ensure any user being assigned to (`assigned_to`) or updated is `users.active = true`.

* **Referential Integrity:** Before closing any record, verify that all mandatory dependencies are satisfied.

* **Time Tracking:** All work logs must include the timestamp (`created_on`) and the `user_id` performing the action.

### **8.2. Error Handling**

* **403 Forbidden:** Permission denied (user role lacks authority for the operation).

* **409 Conflict:** Record locking or state conflict.

* **Rate Limiting:** If exceeded, pause and retry using **Exponential Backoff**.

---

## **9. Predefined Lists (Enumerations)**

| Table.Field | Allowed Values |

| :--- | :--- |

| **users.role** | `admin`, `manager`, `agent`, `reporter` |

| **incident.priority** | `critical`, `high`, `moderate`, `low`, `planning` |

| **incident.impact** | `high`, `medium`, `low` |

| **incident.urgency** | `high`, `medium`, `low` |

| **incident.status** | `new`, `in_progress`, `on_hold`, `resolved`, `closed` |

| **incident.on_hold_reason** | `Awaiting Change`, `Awaiting Caller`, `Awaiting Problem` |

| **incident.resolution_code** | `fixed`, `workaround`, `not_reproducible`, `closed_by_caller` |

| **change_request.type** | `standard`, `normal`, `emergency` |

| **change_request.status** | `new`, `assess`, `authorize`, `scheduled`, `implement`, `review`, `closed`, `canceled` |

| **configuration_item.status** | `in_use`, `in_stock`, `maintenance`, `retired`, `disposed` |

| **kb_knowledge.state** | `draft`, `review`, `published`, `retired` |

| **incident_sla.stage** | `in_progress`, `paused`, `completed`, `cancelled`, `breached` |

Task:
Hey, could you please put together a knowledge article called 'SAP Oracle Database Memory Leak Resolution'? We had that recent outage, and it'd be great to capture what went wrong and how we fixed it. Here is the article content - "SAP Oracle Database Memory Leak Resolution Document Version: 1.0 Effective Date: December 2025 Author: Joanne Simpson (USER_004) Revision Date: 2025-12-17 Incident Reference: INC-000001 (Parent Incident) Related Incidents: INC-000044, INC-000069, INC-000082 Executive Summary: On December 17, 2025, the SAP Oracle database instance experienced a critical outage due to a memory leak in the database buffer cache management module. This document provides comprehensive root cause analysis, resolution steps, and prevention measures for database administrators and support staff. Root Cause Analysis: 1. Issue Identification: Oracle database memory consumption exceeded available RAM, causing swap thrashing 2. Primary Cause: Memory leak in the SAP custom code module (SAPARCH process) 3. Contributing Factors: - Missing Oracle patches for bug 24789456 in Database 19c - Inadequate monitoring thresholds for memory utilization - High transaction volume without proper workload management 4. Root Element: Oracle patch KB 24789456 was not applied to address memory accumulation Detailed Timeline: 06:00 - Database instance became unresponsive 06:15 - Monitoring alerts triggered for high memory usage 06:30 - Database automatically restarted (OOM killer activated) 07:00 - Service restored with manual intervention 08:00 - Root cause analysis identified memory leak in buffer cache Resolution Steps: 1. Apply Oracle Patch 24789456: https://support.oracle.com/patches/24789456  - Patch resolves memory leak in buffer cache management - Requires Oracle database restart (5 minute downtime) - Backup database before applying patch 2. Configuration Changes: - Update SGA_MAX_SIZE to 180GB (from 200GB) - Enable memory resource limits: pga_aggregate_limit=100GB - Configure alert thresholds: memory usage > 85% triggers notification 3. Verification Steps: - Execute: SELECT * FROM v$memory_target_advice; - Verify memory consumption stabilizes at <85% of allocated RAM - Monitor SAPARCH processes for continued growth 4. Application Configuration: - Update SAP Dialog Instance work process limits - Implement request queue management to control transaction volume - Enable SAP memory monitoring tools: /n/usr/bin/memusage Prevention Measures: 1. Maintenance Schedule: - Monthly: Review memory consumption trends - Quarterly: Apply latest Oracle security and stability patches - Semi-annually: Perform capacity planning review 2. Monitoring Configuration: - Alert on memory usage > 80% of allocated - Alert on SAPARCH process memory growth > 5GB/hour - Daily automated reports on database resource utilization 3. Capacity Planning: - Current database: 200GB SGA + 100GB PGA - Projected growth: 15% annually - Next upgrade recommended: Q3 2026 4. Disaster Recovery: - Automated database failover to standby instance - Regular failover drills (quarterly) - Point-in-time recovery testing (monthly) Related Incidents Resolved: - INC-000044: SAP Financial Module - Resolved with database restoration - INC-000069: SAP Purchasing System - Resolved with database restoration - INC-000082: SAP HR Module - Resolved with database restoration Escalation Path: 1. Database Administrator (primary) 2. SAP System Administrator (secondary) 3. Oracle Support (tertiary) Additional Resources: - Oracle Patch Documentation: Oracle Support Note 24789456 - SAP Memory Management Guide: https://wiki.sap.com/memory-management  - Database Monitoring Dashboard: https://monitoring.techcorp.local/sap-db " - If possible, link it to incident INC-000001 and any related child incidents so the info is easy to find later. Oh, and there's also this draft titled 'Windows 11 Upgrade FAQ' as we're rolling out the OS soon, so it should probably go live for external users. Not sure if it's ready, but maybe just publish it without any further delay? And while you're at it, can you also create another knowledge article for the Windows 11 rollout procedures?  with this content - "Windows 11 Rollout Procedures Document Version: 1.0 Effective Date: December 2025 Author: Joanne Simpson (USER_004) Overview: This document outlines the standard operating procedures for the Windows 11 operating system rollout across the organization. The rollout is scheduled to begin in Q1 2026 and will be executed in phases to minimize disruption to business operations. Pre-Rollout Requirements: 1. Hardware Compatibility Assessment - Verify TPM 2.0 availability on target devices - Confirm minimum 4GB RAM (8GB recommended) - Ensure 64GB storage minimum available - Check CPU compatibility (Intel 8th gen or AMD Zen 2 minimum) 2. Software Inventory - Document all currently installed applications - Verify Windows 11 compatibility for critical applications - Identify legacy applications requiring alternative solutions - Test application compatibility in pilot environment 3. User Communication - Notify users 2 weeks before scheduled upgrade - Provide training materials and resources - Schedule upgrade windows during off-peak hours - Establish helpdesk support procedures Rollout Phases: Phase 1: Pilot Deployment (Weeks 1-2) - Target: 50 users from IT department - Objective: Validate deployment process and identify issues - Success Criteria: 95% successful upgrades, no critical issues Phase 2: Department Rollout (Weeks 3-8) - Target: Non-critical departments (HR, Finance, Marketing) - Deployment rate: 100 devices per week - Support: Dedicated helpdesk team during business hours Phase 3: Production Environment (Weeks 9-16) - Target: Critical operations departments - Deployment rate: 150 devices per week - Support: 24/7 helpdesk coverage Phase 4: Remaining Devices (Weeks 17-20) - Target: All remaining devices - Deployment rate: 200 devices per week Deployment Process: 1. Pre-Deployment Checklist - Verify device is on approved hardware list - Ensure user has backed up critical data - Schedule upgrade window with user - Create system restore point 2. Deployment Execution - Download Windows 11 installation media - Run Windows 11 Installation Assistant - Monitor installation progress (approximately 60-90 minutes) - Verify successful installation and activation 3. Post-Deployment Validation - Confirm all applications launch successfully - Verify network connectivity and domain membership - Test printer and peripheral device functionality - Validate user profile and data migration - Install any missing drivers or updates 4. User Acceptance - Conduct brief user orientation on Windows 11 interface - Provide quick reference guide for new features - Confirm user can access all required applications - Document any issues for helpdesk tracking Rollback Procedures: In case of critical issues, devices can be rolled back to Windows 10 within 10 days of upgrade: 1. Navigate to Settings > System > Recovery 2. Select "Go back to Windows 10" 3. Follow on-screen prompts 4. Document rollback reason and submit incident ticket Known Issues and Workarounds: - VPN client compatibility: Upgrade VPN client to version 5.2 or higher before Windows 11 upgrade - Legacy printer drivers: Use Windows Update to install Windows 11 compatible drivers - Custom LOB applications: Contact application owner for compatibility assessment Support Resources: - Helpdesk: ext. 4357 or helpdesk@company.com - Windows 11 Training Portal: https://training.company.com/windows11  - Common Questions: Refer to KB_020 (Windows 11 Upgrade FAQ) for frequently asked questions - Microsoft Documentation: https://docs.microsoft.com/windows11  Success Metrics: - Target: 98% successful deployments - Maximum rollback rate: 2% - User satisfaction score: >85% - Critical incident rate: <1% Escalation Path: 1. Tier 1 Helpdesk (initial support) 2. Desktop Engineering Team (technical issues) 3. Microsoft Premier Support (vendor escalation) Sign-off and Approval: This procedure has been reviewed and approved by: - IT Operations Manager - Change Advisory Board (CAB) - Information Security Team Document Control: - Review Frequency: Quarterly - Next Review Date: March 2026 - Document Owner: IT Operations Team" 
- Make sure to mention in the rollout procedures article that users can refer to the FAQ article for common questions.

Available tools:
link_knowledge_to_incident
create_knowledge_article
get_user
update_knowledge_article
retrieve_knowledge_articles
list_child_incidents
find_incident_by_number

Verification checks:
[{"verifier_type": "database_state", "name": "Verify SAP Knowledge Article Creation", "description": "Confirms that the SAP Oracle Database Memory Leak Resolution knowledge article was created and published", "gym_name": "gym-itsm-mcp", "validation_config": {"query": "SELECT COUNT(*)\nFROM knowledge\nWHERE title = 'SAP Oracle Database Memory Leak Resolution'\n  AND state = 'published'\n  AND visibility = 'internal'\n  AND owner_id = 'USER_004'\n  AND org_id = 'ORG_001';", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify Knowledge Links to All Incidents", "description": "Confirms that the SAP knowledge article was linked to parent incident and all three child incidents as resolution", "gym_name": "gym-itsm-mcp", "validation_config": {"query": "SELECT COUNT(*)\nFROM incident_knowledge ik\nJOIN knowledge k ON ik.knowledge_id = k.knowledge_id\nWHERE k.title = 'SAP Oracle Database Memory Leak Resolution'\n  AND ik.incident_id IN ('INC_001', 'INC_044', 'INC_069', 'INC_082')\n  AND ik.used_as = 'resolution';", "expected_value": 4, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify Windows 11 FAQ Published", "description": "Confirms that KB_020 was updated from draft to published state with external visibility", "gym_name": "gym-itsm-mcp", "validation_config": {"query": "SELECT COUNT(*)\nFROM knowledge\nWHERE knowledge_id = 'KB_020'\n  AND title = 'Windows 11 Upgrade FAQ'\n  AND state = 'published'\n  AND visibility = 'external'\n  AND org_id = 'ORG_001';", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify Windows 11 FAQ Has External Visibility", "description": "Confirms KB_020 still has external visibility", "gym_name": "gym-itsm-mcp", "validation_config": {"query": "SELECT COUNT(*)\nFROM knowledge\nWHERE knowledge_id = 'KB_020'\n  AND visibility = 'external'\n  AND org_id = 'ORG_001';", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify Windows 11 Rollout Procedures Created", "description": "Confirms that Windows 11 Rollout Procedures knowledge article was created", "gym_name": "gym-itsm-mcp", "validation_config": {"query": "SELECT COUNT(*)\nFROM knowledge\nWHERE title LIKE '%Windows 11%Rollout%Procedures%'\n  AND state = 'published'\n  AND owner_id = 'USER_004'\n  AND org_id = 'ORG_001';", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify Rollout Procedures References FAQ", "description": "Confirms that the rollout procedures article references KB_020 in its body", "gym_name": "gym-itsm-mcp", "validation_config": {"query": "SELECT COUNT(*)\nFROM knowledge\nWHERE title LIKE '%Windows 11%Rollout%Procedures%'\n  AND (body LIKE '%KB_020%' OR body LIKE '%KB0000020%' OR body LIKE '%Windows 11 Upgrade FAQ%')\n  AND org_id = 'ORG_001';", "expected_value": 1, "comparison_type": "equals"}}]