Operational issues and lifecycle

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.

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: []

Operational Issue card showing the workflow stepper, detector evidence, an AI root-cause hypothesis with its probability, the business impact summary, and ranked knowledge-base articles — Issue card: workflow stepper, detector evidence, AI Root Cause with probability, business impact, ranked Known-solution (KB) 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

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.

Reference screen listing the Issue lifecycle statuses with their allowed transitions, the snapshot statuses, and the incident stages — Statuses and workflow: the Issue lifecycle with allowed transitions, snapshot statuses and incident stages

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.

Continuation of the Issue card with the tasks checklist and the chronological event timeline recording every action taken on the Issue — Issue card (continued): tasks checklist and the full event timeline — the single source for all KPIs

Verwandte Themen

Zuletzt aktualisiert am 25. Juli 2026

War diese Seite hilfreich?