# personnel_and_dclass_state

## Purpose

This document defines the runtime state behavior of all personnel within the facility system.

It describes how their operational states change over time, what triggers those changes and how those changes affect system behavior.

This system is strictly event driven and must remain synchronized with log and task system.

---

## Personnel Lifecycle Status

### Status

- active
- unavailable
- retired
- deceased

### Rules

- retired or deceased personnel must be excluded from all task assignments
- unavailable personnel may still exist but cannot be assigned tasks unless overridden

---

## Task State Behavior (!same for both normal personnel and D-Class personnel!)

### States

- idle
- assigned
- on_task
- unknown

### Transitions

#### idle -> assigned
- task is assigned to personnel

#### assigned -> on_task
- task execution begins

#### on_task -> idle
- task is completed
- task is cancelled or reassigned

#### any -> unknown
- system cannot determine state
- personnel is unreachable

---

## Health State Behavior

### States

- normal
- injured
- critical
- unknown

### Transitions

#### normal -> injured
- personnel gets injured he/she can still operate

#### normal/injured -> critical
- personnel gets severely injured where he/she cannot temporary operate

#### injured/critical -> normal
- personnel is healed and can operate normally again

#### any -> unknown
- system cannot determine health status
- personnel is unreachable

---

# D-CLASS STATE SYSTEM

## Status States

- active
- expired
- terminated
- unknown

## Transitions

#### active -> expired
- `expires_at` date is reached

#### active -> terminated
- D-Class has deceased in a experiment or in a containment breach

#### expired -> terminated
- automated disposal procedure is executed

---

## Experiment Interaction Rules

- active D-Class may participate in experiments
- all D-Class assignments are immutable once experiment state becomes completed
- terminated or expired D-Class must be excluded from new experiments automatically

---

# LOGGING REQUIREMENTS

Every state transition must generate:

- **activity_log** entry (standard transitions)
- **incident_log** entry (critical or containment-related transitions)

---

# NOTES

- State changes are event-driven and should never be applied manually without triggering logs.
- Personnel and D-Class systems are intentionally separated but share similar state logic patterns for consistency.