Events monitor

The map answers what is happening; the events monitor is where it is worked. An event is a record raised from a signal on the platform — a seismic reading above a threshold, a weather warning over a province, a vessel that has stopped reporting, a report typed in from the field — and from that moment it has a severity, an owner, a status and a timeline of its own.

That is the difference the console makes: a reading stops being something an operator looks at and becomes something a person is responsible for. The same event can be opened from the map, from an alert rule or from the list, and it is one record in every case.

• Raised from a signal — a layer, an alert rule, an entity, or a field report.
• Severity — how much attention the event demands, carried on the record itself.
• Owner — the person or team accountable for it.
• Status — where the event stands in the response workflow.
• History — everything recorded about it, in order.

Events arrive from several directions and land in one list. A rule that fires on a metric creates an event carrying the value and the threshold that produced it, so the record explains its own origin instead of asking the reader to reconstruct it. A hazard layer can be carried into the console from the marker that prompted it, place and time included.

Reports from the field and operator-defined locations enter the same queue, which matters more than it sounds: an observation made on the ground and a satellite detection are then read side by side in one list, rather than in two systems that never meet.

• Alert rules — a firing arrives with its metric, its value and its threshold.
• Map events — an event raised from a marker keeps its place, time and layer.
• Detected signals — events drawn from media and social sources enter the same queue.
• Field reports — observations logged in the field appear beside the platform's feeds.
• Manual entry — an event can be raised by hand when no feed carries it yet.

Severity is set when the event is raised and revised as the picture sharpens; the list sorts on it, so the queue order is an argument about importance rather than a chronology of arrival. Assignment puts a name on the record, and a named record is what separates a board from a noticeboard.

The workflow runs on columns, and moving an event through them records the decision: first report, impact, review, handling, monitoring, closing. Every move is appended to the same history, so an event that was closed can be read backwards without asking anyone what happened.

• Severity — sorts the queue, and is revised as the event is understood.
• Assignment — a named owner per event, and a team behind it.
• Columns — the stage the event has reached, recorded rather than implied.
• Comments — reasoning is kept with the record it concerns.
• Reopening — an event that returns is the same record, not a new one.

A single reading is only useful next to what came before it, and the console keeps that context with the event rather than in a message thread. Additions, severity changes, reassignments and closures all append to the timeline, and the timeline is what a handover is read from.

The record also outlives the shift. An event raised at the end of a watch is understood by whoever picks it up, because nothing about it lived only in somebody's memory of a screen.

An event is not a notification that vanishes when it is dismissed; it is a record with an owner.

The events monitor is one surface of Xentinel Watchtower rather than a separate system. Events are entities in the entity graph, so an event connects to the places and organisations around it; the same metric that raised an event can be charted and summarised; and the automated situation report describes the events the console tracked over the period it covers.

That is deliberate. A console that received signals and kept them to itself would be a new silo, which is precisely what a single operational picture is meant to avoid.

• Graph — an event is an entity, so it links to the places and organisations around it.
• Reports — tracked events are summarised in the automated situation report.
• Map — an event can be read back on the layer it came from.
• Assistant — the chat assistant answers over platform data, event records included.

The console shows what the platform knows, and it keeps the difference between an event and a conclusion visible. Severity is a person's judgement recorded on the record, assignment is a decision about who looks, and neither is inferred by the software on the operator's behalf.

Nothing is deleted quietly. An event that turns out to be wrong is closed with its reason attached, because the record of a false alarm is how a threshold gets corrected — and that correction is a change to the rule, not a change to the console.