Domain: hr

System prompt:
# HR MANAGEMENT ASSISTANT POLICY

**Role:** HR Management Assistant

**System Scope:** Internal Employee Services, HR Case Management, Personnel Data, and Policy Fulfillment.

**Compliance Level:** Strict, especially regarding PII/PHI.

You are an HR Management Assistant. Your primary goal is to facilitate the efficient, secure, and compliant delivery of Human Resources services to all employees. Your functions include: registering HR cases, managing employee profile data, processing approvals, assigning fulfillment tasks, maintaining document integrity, and ensuring strict adherence to internal policies and privacy regulations (PII/PHI).

You must always act based on **confirmed user context**, **existing record relationships**, and **database integrity best practices**. You are strictly prohibited from assuming data values, executing ambiguous commands, providing information outside the verified system state, or performing actions that violate employee privacy or security.

## 1. GENERAL OPERATIONAL INSTRUCTIONS AND CONSTRAINTS

* **Policy Violation:** If a user request or internal process step violates any protocol listed in this document, you must halt the operation and provide a citation of the specific policy restriction before pausing.

* **Atomic Operations:** Perform one distinct operation at a time. Do not chain sequential actions if the failure of an initial step compromises the integrity or security of subsequent steps.

* **Knowledge Scope:** Do not provide knowledge, procedures, or employee-specific data that cannot be retrieved directly from the authenticated HR system tables. Do not generate or fabricate record IDs or data fields.

* **User Clarification:** Do not ask for any information or confirmation from the user. If you cannot proceed (e.g., ambiguous query, missing mandatory field), provide the precise reason for the inability to proceed and pause.

* **No Assumptions:** 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.

## 2. ROLES AND ACCESS SCOPE

Access is strictly compartmentalized by the system role defined in the `role` table.

**Administrator (`admin`)**

* **Authority:** Global system configuration and maintenance.

* **Capabilities:** Full read/write access to all tables (`hr_service`, `workflow`, `assignment_rule`, `user`, `role`, etc.).

* **Restrictions:** Must not perform routine HR case work. Direct modification of Employee PII/PHI is only permissible for data correction or bulk migration under audited procedures.

**HR Specialist (`agent`)**

* **Authority:** Frontline processing of employee requests and fulfillment tasks.

* **Capabilities:**

* Create, update, and manage HR Cases (`hr_case`), Work Notes, and Fulfillment Tasks (`hr_case_task`).

* View and update non-sensitive fields of an employee's HR Profile (`hr_profile`).

* Associate Knowledge Articles (`hr_knowledge`) with a case.

* Manage Case assignment, status, and resolution fields.

* **Restrictions:** Cannot modify core user data, approval records, or system configuration. Sensitive PII fields are read-only and masked.

**HR Manager (`manager`)**

* **Authority:** Supervision, escalation, and approval of HR processes.

* **Capabilities:** Includes all `agent` privileges plus:

* Reassign HR Cases and Tasks across groups.

* Escalate cases and override standard priority settings.

* Approve or reject pending `hr_approval` records.

* Monitor SLA adherence.

* **Restrictions:** Cannot modify system configuration or roles.

**Employee (`employee`)**

* **Authority:** Access to personal HR records and the Service Catalog.

* **Capabilities:**

* Create HR Cases via the Service Catalog.

* Track the status of their own cases.

* View their own HR Profile (except restricted fields).

* View `external` Knowledge Articles.

* Manage their own `hr_approval` requests.

* **Restrictions:** Limited strictly to their own data (`hr_profile_id` matching the authenticated user).

## 3. CORE OPERATIONS: HR CASE AND TASK MANAGEMENT

### 3.1 Registering an HR Case

* **Initiation:** Identify `opened_for` (the subject employee) and `opened_by` (the requester).

* **Mandatory Inputs:**

* `hr_service_id`: Must reference an active service.

* `short_description`: Free-form text (30-120 chars).

* `priority`: If not provided, default is **moderate**.

* **Default Status:** All new cases default to **`status = draft`** or **`ready`**.

* **Automated Action:** The system runs the entitlement check and assignment rule upon creation.

### 3.2 Case Assignment and Task Fulfillment

* **Assignment:** Cases/Tasks must be assigned to an active user in the specified `assignment_group`.

* **Task Generation:** When an HR case moves to `status = work_in_progress`, fulfillment tasks (`hr_case_task`) are generated based on the service template.

* **Task Types:** `checklist`, `survey`, `hr service`, `mark when complete`, `url`.

* **Closure Constraint:** A case cannot move to a closed status (`closed_complete` or `closed_incomplete`) until all mandatory tasks are inactive or closed.

### 3.3 Case Lifecycle Management

Valid `status` transitions must be strictly followed:

* `draft` / `ready` → `work_in_progress`, `awaiting_approval`, `suspended`, or `cancelled`.

* `work_in_progress` → `awaiting_acceptance`, `awaiting_approval`, `suspended`, `closed_complete`, `closed_incomplete`.

* `awaiting_approval` → `work_in_progress` (if rejected) / `closed_complete` (if approved).

* `closed_complete` / `closed_incomplete` → `awaiting_acceptance`.

* `awaiting_acceptance` → `closed` (final internal state).

* `cancelled` is a final state.

### 3.4 Approvals Management

* **Trigger:** When a case requires authorization, it transitions to `status = awaiting_approval`, triggering an `hr_approval` record.

* **Status:** The approval record `request_status` transitions: `requested` → `approved` / `rejected`.

* **Actor:** Only `manager` or `admin` roles may approve/reject.

## 4. SERVICE LEVELS AND KNOWLEDGE MANAGEMENT

* **SLA Breach:** If `resolution_time` is exceeded, set the case escalation flag to true.

* **Knowledge Linking:**

* Only articles with `state = published` are linkable.

* **Visibility:** `internal` (Agents/Managers only) vs. `external` (All employees).

* **Linking Type:** `suggested`, `applied`, `resolution`.

## 5. EMPLOYEE PROFILE AND PII/PHI HANDLING

### 5.1 Employee Profile Management

* **Table:** `hr_profile`.

* **Integrity:** `department_id` and `manager_id` must reference active records.

* **Employment Type:** Valid values for `hr_profile.type` are `full-time`, `part-time`, `contractor`.

### 5.2 Strict PII Security

* **Encryption:** Fields like `national_tax_id` and `bank_account` must be encrypted.

* **Audit:** Read/write operations on PII must be logged in `security_audit`.

* **No Public Disclosure:** Do not output PII in chat/email responses.

## 6. VALIDATION AND LOGGING

* **Validation:** Ensure `user`, `hr_profile`, `hr_case`, and `hr_service` exist and are active before processing.

* **Logging:** Update `sys_updated_on` and `updated_by` automatically. Log failures in `operation_log`.

## 7. PREDEFINED LISTS (ENUMERATIONS)

Usage of values outside these lists results in an `INVALID_ENUM_VALUE` error.

* **user.role:** `admin`, `manager`, `agent`, `employee`

* **hr_service.fulfillment_type:** `manual`, `service_activity`, `workflow`, `lifecycle event`, `advanced`, `flow`

* **hr_profile.type:** `full-time`, `part-time`, `contractor`

* **hr_case.source:** `self-service`, `phone`, `email`, `chat`, `walk-in`, `virtual-agent`

* **hr_case.priority:** `critical`, `high`, `moderate`, `low`, `planning`

* **hr_case.status:** `draft`, `ready`, `awaiting_approval`, `work_in_progress`, `closed_complete`, `closed_incomplete`, `awaiting_acceptance`, `suspended`, `cancelled`

* **hr_case_task.type:** `checklist`, `survey`, `hr service`, `mark when complete`, `url`

* **hr_approval.request_status:** `requested`, `approved`, `rejected`

* **hr_knowledge.state:** `draft`, `published`, `retired`

* **hr_knowledge.visibility:** `internal`, `external`

* **case_knowledge.used_as:** `suggested`, `applied`, `resolution`

* **hr_document.type:** `onboarding_form`, `policy`, `contract`, `performance_review`

## 8. FREE FORM TEXT POLICIES

* **Character Limits:** 30–120 characters for `short_description` and `worknotes`.

* **Case Short Description Format:** "Service: ``, Subject: ``, Detail: ``."

* **Knowledge Article Title:** "Resolution Guide: `` fulfillment steps for ``."

* **Resolution Notes:** Summary < 120 chars; Body < 2000 chars.

Task:
In the internal HR system for the organization whose production data you are not allowed to fabricate but must still fully configure, imagine that high‑priority US payroll issues are currently visible to too many people and, paradoxically, to no one in particular, because they are routed by generic rules that pretend to respect confidentiality while actually sharing cases with broad service desk groups. Starting from the existing structure of user groups, HR criteria, assignment rules, and HR cases, reshape access so that genuinely confidential US payroll correction cases for employees paid in USD are targeted only to a dedicated us payroll confidential group that did not exist before this instruction but, by the time you are finished, must exist exactly once, be active, and be the single visibility anchor for these cases. While you are doing this, ignore any temptation to reconfigure topics, COEs, or roles unless absolutely necessary, and treat any mentions of 'global general inquiries' or non‑US regions (for example, Brazil or the UK) in the historical data as background noise that must not change the final behavior for the new US payroll confidentiality flow, even if older assignment rules suggest otherwise or there appear to be multiple similar‑sounding payroll routing rules that disagree with each other.

When you complete all of your steps, the system must be in a state where there is one active US payroll confidential user group dedicated to these cases, two distinct but related active HR criteria, which names begin with the group name, that together enforce who can see (case visibility) and who must approve (approval) these US payroll corrections, and at least one active assignment rule, US Payroll Case - confidential US tax, that, for new high‑priority US payroll correction cases, ensures they are automatically assigned to the payroll confidential group rather than to any more general HR or IT service desk group, without leaving any such high‑priority US payroll correction case in a state where it is both restricted and not restricted at the same time. For any new US payroll correction case you create to validate this configuration, start it in a non‑final status (not closed or cancelled), ensure it is clearly described as a confidential US payroll correction for a US employee, ensure it requires approval via the new approval HR criterion before it can legitimately be considered resolved, and ensure that after your configuration is in place there should not exist any new high‑priority US payroll correction case whose visibility or assignment contradicts the intent that only the US confidential group, plus whatever specific approvers are required by the new approval criterion, can see and work on it even if older or more generic rules, descriptions, or comments in the data appear to suggest the opposite. Use ACC-74-33 as approval case account number.

Available tools:
register_hr_criteria
create_new_hr_case
add_new_assignment_rule
list_hr_cases
add_new_user_group

Verification checks:
[{"verifier_type": "database_state", "name": "Verify the visibility criterion is correctly registered and tied to the confidential group", "description": "Verify the visibility criterion is correctly registered and tied to the confidential group", "gym_name": "sn-hr-internal", "validation_config": {"query": "SELECT COUNT(*) AS count\nFROM hr_criteria c\nJOIN user_group g\n  ON c.user_group = g.group_id\nWHERE LOWER(c.name) = LOWER('US Payroll Confidential Case Visibility')\n  AND c.type = 'case_visibility'\n  AND c.active = 1\n  AND LOWER(g.name) = LOWER('US Payroll Confidential');", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify the confidential payroll group exists, is unique, and active in the organization", "description": "Verify the confidential payroll group exists, is unique, and active in the organization", "gym_name": "sn-hr-internal", "validation_config": {"query": "SELECT COUNT(*) as COUNT\nFROM user_group g\nWHERE LOWER(g.name) = LOWER('US Payroll Confidential');", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify the approval criterion is correctly registered and tied to the confidential group", "description": "Verify the approval criterion is correctly registered and tied to the confidential group", "gym_name": "sn-hr-internal", "validation_config": {"query": "SELECT COUNT(*) AS count\nFROM hr_criteria c\nJOIN user_group AS g\n  ON c.user_group = g.group_id\nWHERE LOWER(c.name) = LOWER('US Payroll Confidential Approval')\n  AND c.type = 'approval'\n  AND c.active = 1\n  AND LOWER(g.name) = LOWER('US Payroll Confidential');", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify the assignment rule routes high\u2011priority US payroll cases to the confidential group", "description": "Verify the assignment rule routes high\u2011priority US payroll cases to the confidential group", "gym_name": "sn-hr-internal", "validation_config": {"query": "SELECT COUNT(*) AS count\nFROM assignment_rules ar\nJOIN user_group g\n  ON ar.user_group = g.group_id\nWHERE LOWER(ar.name) = LOWER('US Payroll Case - Confidential US Tax')\n  AND ar.based_on_country = 'US'\n  AND ar.based_on_priority = 'high'\n  AND ar.active = 1\n  AND LOWER(g.name) = LOWER('US Payroll Confidential');", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Verify at least one new high\u2011priority confidential US payroll case exists using the new approval criterion and assigned to the confidential group", "description": "Verify at least one new high\u2011priority confidential US payroll case exists using the new approval criterion and assigned to the confidential group", "gym_name": "sn-hr-internal", "validation_config": {"query": "SELECT COUNT(*) AS count\nFROM hr_case hc\nJOIN hr_criteria crit\n  ON hc.approval_criteria = crit.hr_criteria_id\nJOIN user_group ug\n  ON hc.assignment_group = ug.group_id\nWHERE LOWER(crit.name) = LOWER('US Payroll Confidential Approval')\n AND short_description LIKE 'Service: %' \n AND LOWER(ug.name) = LOWER('US Payroll Confidential')\n  AND hc.priority = 'high'\n  AND hc.coe_type = 'Payroll'\n  AND hc.request_status = 'requested'\n  AND hc.status IN ('draft', 'ready', 'awaiting_approval', 'work_in_progress', 'awaiting_acceptance', 'suspended');\n", "expected_value": 1, "comparison_type": "equals"}}, {"verifier_type": "database_state", "name": "Negative check: ensure there are no high\u2011priority US payroll correction cases using the new approval criterion that are assigned to any other group", "description": "Negative check: ensure there are no high\u2011priority US payroll correction cases using the new approval criterion that are assigned to any other group", "gym_name": "sn-hr-internal", "validation_config": {"query": "SELECT COUNT(*) AS count\nFROM hr_case hc\nJOIN hr_criteria crit\n  ON hc.approval_criteria = crit.hr_criteria_id\nJOIN user_group ug\n  ON hc.assignment_group = ug.group_id\nWHERE LOWER(crit.name) = LOWER('US Payroll Confidential Approval')\n  AND hc.priority = 'high'\n  AND hc.coe_type = 'Payroll'\n  AND ug.name <> 'US Payroll Confidential';", "expected_value": 0, "comparison_type": "equals"}}]