models Package

Overview#

Package models provides core data structures and types for the incident management platform.

This package defines the fundamental data models used throughout the system, including:

• Incident structures with severity levels and status tracking
• Timeline events for audit trails and state changes
• Data types compatible with external ITSM systems (ServiceNow, Jira, PagerDuty)
• CloudEvents v1.0 compliant event structures for event sourcing

The models in this package are designed to be:

• JSON serializable for REST APIs
• Compatible with external connector interfaces
• Event-sourced with immutable timeline tracking
• Policy-aware for access control and data classification

Example usage:

incident := &models.Incident{
	ID:       "INC-12345",
	Title:    "Database Connection Issues",
	Severity: models.SeveritySEV2,
	Status:   models.StatusOpen,
	Service:  "payment-api",
}

event := &models.TimelineEvent{
	ID:         uuid.New().String(),
	IncidentID: incident.ID,
	EventType:  models.EventTypeDeclare,
	Actor:      "john.doe@company.com",
	Title:      "Incident declared",
}

Import Path: github.com/systmms/incidents/internal/models

Constants#

EventTypeDeclare (and others)#

Incident management event types following CloudEvents naming conventions.

Event types are hierarchically organized using reverse domain notation with the “im” (incident management) prefix to avoid naming conflicts.

Event types are organized into two main categories:

• im.incident.* - Events related to incident lifecycle management
• im.alert.* - Events related to alert processing and correlation

const EventTypeDeclare const EventTypeAck const EventTypeMitigate const EventTypeResolve const EventTypeClose const EventTypeNote const EventTypeStateChange const EventTypeRoleAssign const EventTypeAlert const EventTypeAlertAck const EventTypeAlertResolve

ExtIncidentID (and others)#

CloudEvent extension keys for incident management specific metadata.

Extensions provide additional context and metadata beyond the standard CloudEvents attributes. All extensions use the “im.” prefix to avoid conflicts with other systems and follow the CloudEvents extension guidelines.

These extensions enable:

• Cross-event correlation and grouping
• Actor attribution for audit trails
• Data classification for policy enforcement
• Visibility controls for multi-tenant environments

const ExtIncidentID const ExtActor const ExtTags const ExtCorrelationKey const ExtDataClass const ExtVisibility

Types#

CloudEvent#

CloudEvent represents a CloudEvents v1.0 compliant event structure.

CloudEvents provide a standardized way to describe event data in a common format, enabling interoperability between different event systems and cloud providers. This implementation follows the CloudEvents v1.0 specification.

The incident management platform uses CloudEvents as the canonical format for:

• Event sourcing and timeline reconstruction
• Cross-system event publishing and consumption
• Webhook payloads to external integrations
• Real-time event streaming to subscribers

All incident-related events are published as CloudEvents to ensure compatibility with event meshes, message brokers, and external event processing systems.

Example CloudEvent for incident declaration:

event := &models.CloudEvent{
	SpecVersion: "1.0",
	ID:          uuid.New().String(),
	Source:      "im://api",
	Type:        models.EventTypeDeclare,
	Subject:     "incident/INC-12345",
	Time:        time.Now(),
	Data:        incidentData,
	Extensions: map[string]interface{}{
		models.ExtIncidentID: "INC-12345",
		models.ExtActor:      "john.doe@company.com",
	},
}

{<nil> 1256 type 0 [0x140003d3000] 0}

Incident#

Incident represents a service incident with full lifecycle tracking.

Incidents are the core entity in the system and serve as the single source of truth across all integrated platforms (chat, paging, ITSM). Each incident maintains:

• Unique identification and metadata
• Severity and status classification
• Timestamp tracking for SLA management
• Role assignments for incident command structure
• Labels for categorization and routing

Incidents are event-sourced, meaning all changes are tracked through TimelineEvent records which maintain an immutable audit trail. The current incident state is materialized from the event stream.

Field mappings allow incidents to be synchronized with external systems while maintaining data integrity and avoiding conflicts through field ownership rules.

{<nil> 9582 type 0 [0x140003d3b80] 0}

IncidentStatus#

IncidentStatus represents the current lifecycle state of an incident.

The status follows a standard incident management workflow:

1. open - Incident has been declared but not yet acknowledged
2. mitigated - Impact has been reduced but root cause not resolved
3. resolved - Root cause has been fixed, monitoring for recurrence
4. closed - Incident is fully resolved and post-mortem completed

Status transitions are enforced by the state machine and tracked in the timeline. External systems may use different status values which are mapped through connectors.

{<nil> 8247 type 0 [0x140003d3a40] 0}

Constants#

const StatusOpen const StatusMitigated const StatusResolved const StatusClosed

Severity#

Severity represents the incident severity level following industry standards.

Severity levels follow the common SEV-1 through SEV-4 classification:

• SEV-1: Critical/P1 - Complete service outage, customer impact
• SEV-2: High/P2 - Major functionality impaired, some customer impact
• SEV-3: Medium/P3 - Minor functionality impaired, minimal customer impact
• SEV-4: Low/P4 - Cosmetic issues, no customer impact

These values are compatible with external ITSM systems and can be mapped to different priority schemes through connector field mappings.

{<nil> 7158 type 0 [0x140003d3880] 0}

Constants#

const SeveritySEV1 const SeveritySEV2 const SeveritySEV3 const SeveritySEV4

TimelineEvent#

TimelineEvent represents a single event in an incident’s timeline.

Timeline events provide an immutable audit trail of all actions and state changes related to an incident. Events are append-only and form the source of truth for incident state reconstruction.

Events support:

• Multiple event types for different actions (declare, ack, resolve, etc.)
• Actor tracking for accountability
• Structured and unstructured data attachment
• Source attribution for multi-system environments
• Precise timestamp tracking for SLA compliance

Events are compatible with CloudEvents v1.0 specification and can be published to event streams for real-time processing and external system integration.

{<nil> 11982 type 0 [0x140003ee400] 0}

Generated automatically from Go source code. Last updated: 2025-08-25T07:51:05-04:00