EM-TEC-05 · Subject model · W1
Incident, problem and root cause
Service disruption, cause investigation, impact, response and recovery. Incident, problem, security event, defect and task play different roles.
Queued for research
Claude: not-started; Grok: not-started.
Research note, in Russian: Entire research brief pending
Subject boundary and candidate types
- Incident
- Problem
- ImpactAssessment
- ResponseAction
- RootCauseClaim
Deep research questions
- How to separate an observation event from an incident?
- How to link recurring incidents to a single problem?
- When does service recovery not eliminate the cause?
Verifiable invariants
- A cause has evidence and confidence
- Recovery does not close the problem automatically
- Severity and priority are separate
End-to-end acceptance scenario
Three incidents, a temporary recovery and one disputed cause preserve causality and the status of follow-up actions.
Negative case
Closing an incident deletes an unfinished root cause fix.
Approaches to compare
- AISMM/WM-SFT and ArchiMate: product, system and architecture
- CSDM: business application, service and runtime instance
- SPDX/OpenTelemetry/Google SRE: delivery, observation and reliability; choose by boundary
Candidates in the live catalogue
- WM-ACT-019 · Incident / Emergency · 0.2.0-legacy · not installed automatically
Semantic fit requires boundary research; a published model does not by itself complete this card. - WM-ACT-020 · Cyber Incident · 0.3.0-research.1 · installable
Semantic fit requires boundary research; a published model does not by itself complete this card.
Result requirements
Every card is executed together with the full research contract: definitions, fields and cardinalities, lifecycle, sources, data mastership, rights, the five object facets, at least eight invariants, positive and negative examples, dependencies, migration and applicability limits.