---
title: 'Operational issues and lifecycle'
description: 'The Operational Issue as the unit of work — base model, Issue vs Task, single and massive kinds, the status workflow with its transition matrix, and the immutable audit trail.'
section: 'Operations Center'
weight: 4
related:
- domain-model
- priorities-and-sla
- execution-and-queue
---
import Image from '@/components/docs/Image.astro';
## Operational Issue
`Operational Issue` is the central entity of OHM.
It is a stateful object that represents an operational problem throughout its entire lifecycle.
### Base Model
```yaml
id: OHM-2026-001842
kind: single
canon: no_hourly_archive
title: 'Hourly archive is missing'
priority: P1
severity: critical
confidence: 0.94
scope:
organization: 'Demo Gas Utility'
region: 'Tashkent'
asset_id: 'station-5690'
ownership:
zone: backend_integration
assignee: 'Integration-2'
timestamps:
first_detected_at: '2026-07-21T04:00:00Z'
created_at: '2026-07-21T04:03:12Z'
acknowledged_at: '2026-07-21T05:10:00Z'
due_at: '2026-07-22T04:00:00Z'
resolved_at: null
status:
workflow: in_progress
snapshot: persistent
overdue: false
unattended: false
chronic: false
root_cause:
class: communication
hypothesis: 'device does not establish a communication session'
confidence: 0.82
confirmed: false
evidence: []
tasks: []
history: []
related_issues: []
knowledge_articles: []
```
### Issue and Task Are Distinct Entities
An Issue answers the question:
> Which operational problem must be resolved?
A Task answers the question:
> Which specific action must be performed?
A single Issue may contain multiple tasks. For the Issue _archive is missing for 38 devices_:
- Task 1 — check gateway availability;
- Task 2 — check the server queue;
- Task 3 — compare firmware versions;
- Task 4 — contact the mobile network operator;
- Task 5 — perform a sample field inspection.
Closing a single task does not automatically close the Issue.
### Single and Massive Issues
OHM uses one model for both scales:
| Kind | Description |
| ---------- | --------------------------------------------------- |
| `single` | a problem affecting one asset or one logical entity |
| `massive` | a system-wide incident affecting a group of assets |
| `manual` | a problem registered by a person |
| `external` | a problem imported from an external system |
## Operational Issue Lifecycle
### Primary Workflow
```mermaid
flowchart TD
S1["Detected"] --> S2["Triaged"]
S2 --> S3["Assigned"]
S3 --> S4["Accepted"]
S4 --> S5["In Progress"]
S5 --> S6["Awaiting Verification"]
S6 --> S7["Verified"]
S7 --> S8["Resolved"]
S8 --> S9["Archived"]
```
Additional terminal outcomes:
- Cancelled;
- Duplicate;
- Not Reproduced;
- Won't Fix;
- Accepted Risk.
### Workflow Statuses
| Status | Meaning |
| ----------------------- | --------------------------------------------------------------------- |
| `detected` | the Issue was created automatically or manually |
| `triaged` | severity, responsibility zone, and initial context have been reviewed |
| `assigned` | a responsible assignee has been determined |
| `accepted` | the assignee has confirmed acceptance |
| `in_progress` | work is underway |
| `awaiting_verification` | the work is reported as completed and awaits verification |
| `verified` | the result has been confirmed |
| `resolved` | the Issue is closed with an established outcome |
| `archived` | the completed object has been moved to long-term history |
| `cancelled` | the Issue was cancelled for a documented reason |
| `duplicate` | the Issue is a duplicate of another object |
| `not_reproduced` | the problem was not confirmed during verification |
| `wont_fix` | a management decision was made not to remediate |
| `accepted_risk` | the risk was formally accepted by an authorized person |
### Snapshot status
In addition to the workflow, OHM tracks the problem state based on the daily detector snapshot:
| Snapshot status | Meaning |
| --------------- | --------------------------------------------------------------- |
| `new` | the problem appeared for the first time |
| `persistent` | the problem persists |
| `worsened` | the condition has deteriorated |
| `improved` | the condition has improved, but the problem has not disappeared |
| `cleared` | the detector no longer confirms the problem |
| `reopened` | the problem reappeared after closure |
The workflow status and the snapshot status are never mixed.
Example: `workflow_status = in_progress` together with `snapshot_status = improved`.
This means that work is still in progress while objective data already shows improvement.
### Transition Matrix
| Current status | Allowed transitions |
| --------------------- | ----------------------------------------------- |
| detected | triaged, assigned, duplicate, cancelled |
| triaged | assigned, cancelled, accepted_risk |
| assigned | accepted, in_progress, reassigned |
| accepted | in_progress, reassigned |
| in_progress | awaiting_verification, escalated, accepted_risk |
| awaiting_verification | verified, in_progress |
| verified | resolved |
| resolved | reopened, archived |
| reopened | triaged, assigned, in_progress |
| any active | duplicate, cancelled |
Every transition is recorded in an immutable event log.
## Audit Trail
All significant actions are recorded in an immutable history.
An event contains:
```yaml
event_id: EVT-9038172
issue_id: OHM-2026-001842
event_type: status_changed
timestamp: '2026-07-23T10:14:00Z'
actor:
type: user
id: 'usr-231'
role: 'zone_manager'
before:
status: assigned
after:
status: in_progress
reason: 'Diagnostics started'
source:
ip: 'masked'
client: 'web'
correlation_id: 'req-982310'
```
The following are always logged:
- creation;
- assignment;
- reassignment;
- priority change;
- deadline change;
- status change;
- comment;
- Evidence addition;
- root cause confirmation;
- manual verification;
- risk acceptance;
- KB article application;
- merging and splitting of Issues;
- detector configuration change;
- export and integration actions.