Core Algorithms & Business Logic

This document outlines the main routines that keep Crisis-Monitor running. Understanding them helps new contributors navigate the code base.

Ticket processing

Ticket creation

TicketService.create builds a CrisisTicket instance from form data. It validates numeric fields, saves uploaded files, logs the creation action, writes an info log entry about the new ticket and emits notifications via event_stream. After committing the ticket a metric counter is incremented.

Duplicate detection

find_duplicate_ticket checks for an existing ticket with a similar title and incident time ±24 hours. When a match is found the duplicate ID is stored in ActivityLog and a message is published.

Ticket updates and SLA logic

TicketService.update applies new field values and records the change in TicketAudit. Status transitions trigger additional steps: - Moving to В работе sets time_response and emits an SLA miss event if the deadline has passed. - Moving to Ликвидирован records time_resolved and performs the same check.

Overdue monitoring

check_overdue_tickets finds open tickets past their deadline. It logs an audit record and publishes an sla_breached event for each new case.

SLA statistics

sla_stats aggregates counts of tickets completed on time, late and overdue. Only records with an explicit time_resolved enter the completed SLA sample; later edits do not rewrite the historical result. Closed records without a measurable resolution time are reported as unmeasured.

Data quality

The data-quality-audit report uses the crisis-quality-v2 formula. Its secondary composite index exposes five dimensions: completeness 35%, freshness 15%, provenance 25%, human verification 15%, and uniqueness 10%. Freshness is averaged across the active corpus using 1/3/7/30-day bands. Non-compensable readiness gates prevent strong values from hiding critical completeness, provenance, or uniqueness gaps.

CAP certainty

Severity, urgency, and certainty remain separate. Observed requires corroborated evidence or multiple reviewed independent sources; Likely requires reviewed evidence with confidence above 50%; unreviewed links cannot raise certainty above Possible. Risk level is never evidence of truth.

Automatic severity triage

The hazard-impact-v2 formula uses the strongest detected hazard as its base signal and adds explicit numeric impact indicators such as magnitude, fatalities, and injuries. Correlated synonyms are not summed as independent evidence, and negated impact phrases such as “no casualties” are removed before scoring. Critical severity requires multiple indicators or explicit impact. The output is a triage suggestion, not a probability or an operator decision.

Operational analytics

Trend series use complete calendar buckets and include the current day, hour, or week. Hourly output is capped at 31 days and other windows at 365 days. Escalation rate uses unique incidents in the selected cohort, while notification actions remain a separate count. Averages, SLA, and percentiles are reported only for measurable samples; negative durations are treated as invalid data.

Tag suggestions

utils/tag_suggest.suggest_tags first checks a list of common phrases that map directly to tag names. If none are found, the function extracts named entities and verbs with the Natasha NLP library and appends them to the text before running a TF‑IDF search against the existing tag vocabulary.

Time cluster detection

utils/analytics.find_time_clusters slides a window over ticket creation times and reports periods where the count significantly exceeds the average.

Deadline reminders

utils/reminders.send_deadline_reminders queries upcoming deadlines and sends email or Telegram notifications. Sent reminders are tracked to avoid duplicates.

Event stream and metrics

utils.event_stream implements a lightweight publish/subscribe queue used by SSE endpoints. utils.metrics keeps a counter of created tickets and can send it to an external service from a background job.