# ApprovalPolicyStepAssignee

## Description

ApprovalPolicyStepAssignee represents one named approver — either a specific `User` or every member of a `Role` — that must vote on a particular `ApprovalPolicyStep`.

## Domain Model Definitions

### Model type

Standard

### Command Definitions

- [createApprovalPolicy](../command/CreateApprovalPolicy.md)
- [updateApprovalPolicy](../command/UpdateApprovalPolicy.md)

### Query Definitions

### Models

- ApprovalPolicyStepAssignee

### Invariants

- Exactly one of `userId` or `roleId` is set per row (XOR); rows that set both or neither are invalid
- `required` is a boolean (default false) and is meaningful only on user assignees (`userId` is set); on role assignees `required` must be false
- `roleQuorum` is an enum (`ALL` / `ANY` / null) and is meaningful only on role assignees (`roleId` is set); on user assignees `roleQuorum` must be null
- Within a single step, `roleId` is unique among role assignees (no two role rows on the same step may target the same role)
- A row is editable while the parent policy is in `DRAFT`; once the parent policy transitions to `ACTIVE` or `INACTIVE`, the row is immutable

### Relationships

- **Belongs To ApprovalPolicyStep**: Each assignee row references exactly one parent step
- **References User (cross-module)**: When `userId` is set, references a `User` in the `user-management` module
- **References Role (cross-module)**: When `roleId` is set, references a `Role` in the `user-management` module; runtime expansion at step activation calls `listUsersByRole` to materialize one runtime assignee per current ACTIVE member
- **Used As Template By ApprovalStepAssignee**: At request creation time the policy assignee row is copied into an `ApprovalStepAssignee` row that then carries runtime status independently