Running an incident in the EOC

An incident in Calchis is the container for a response: the tasks, the resources committed, the people involved, the status board, and the log of what happened when. It exists so that everyone working the event is looking at the same picture, and so that the record afterwards is a by-product of running the response rather than a reconstruction of it.

Creating an incident

Create one from Incident Management. Name it after the event, not the date — the name is what partner agencies will see, and "Highway 12 Flooding" is more useful to them than a timestamp.

Create the incident earlier than feels necessary. An incident opened during the monitoring phase captures the decisions that shaped the response; one opened after activation starts the record halfway through the story.

The common operating picture

Once an incident exists, four things build the picture:

Tasks. What needs doing, who owns it, and where it stands. Assign an owner at creation. An unassigned task is a note, not a task, and it will still be sitting there at the shift change.

Resources. What is committed to this incident, drawn from your equipment and supply records. This is what makes the resource picture real rather than remembered — see tracking equipment and supplies.

Participants. Who is working the incident and in what ICS role. Roles drive what people see and are what the generated forms are populated from.

Status board. The shared view. Its purpose is that the incoming shift, the partner agency, and the elected official asking for an update all read the same thing.

Activation level and the hazard feeds

The EOC activation level — monitoring, partial, or full — is set from the incident header, one click, and everyone on the incident is notified when it changes. It is the headline decision, so it is not buried in an edit form.

The incident's overview also lists the live hazard events from the federal feeds within 100 km of it — the NWS warning or USGS event that arrived after you stood the incident up. Link one and the incident's situation section follows it from then on; unlink it if the feed moves on.

The EOC Overview

When more than one incident is open, the EOC Overview puts all of them on one board: activation level, who has command, open and overdue taskings, open resource requests, the latest significant event and the latest SITREP for each, with a live feed of significant events across every incident. It sorts full activations to the top and updates as the boards change. "Wall display" drops the navigation and enlarges the type for the screen at the front of the room; Escape brings the navigation back.

The room running one incident has its own screen: Wall display in the incident header opens /incidents/<id>/wall — the operational period with a live countdown, open taskings by priority, the last significant events, open resource requests, the Command and General Staff, and the objectives. Nothing on it can be clicked; it is for the projector. On the EOC Overview in wall mode, tapping an incident opens its wall.

Operational periods

An incident runs in operational periods, usually twelve hours. Start next period in the Operational Period panel closes the current one and opens the next; the change lands on the activity log and the after-action timeline, and every form printed from then on carries the new period. Print the Incident Action Plan at the start of each period (below), not at the end.

When a period ends before the next one is started, the product says so everywhere the room looks: a red banner at the top of the incident with Start next period on it, a Period ended chip on the incident’s card on the EOC Overview with a Periods lapsed count in the totals, and a line under the wall’s countdown. Until it is rolled, forms are being stamped against a window that has closed.

Taking the numbers with you

Every board — tasks, taskings, missions, resources, resource requests, significant events and the logbook — has an Export CSV control that downloads that board as a spreadsheet, named by incident number and date. The EOC Overview exports its incident table the same way. Use them for the state briefing, the after-action file, or any system that still wants a spreadsheet. Exports stay available after a subscription lapses; your records are yours.

ICS forms

The platform generates the standard ICS forms from the incident record: the incident briefing (ICS-201), objectives (202), the organization assignment list (203), the assignment list (204, incident-wide or per division/group from the missions board), the radio communications plan (205, from the channels you enter under Radio channels on the ICS Forms panel — zone, channel, function, name, assignment, frequencies, tones, mode), the communications list (205A) and the check-in list (211) from the roster, the organization chart (207), a partial status summary (209), the resource request (213-RR), and the activity log (214, as the incident-wide record, one person’s own form from the ICS Organization panel, or every position’s form in one packet). Incident Action Plan prints the period’s IAP as one PDF: a cover sheet, then the 202, 203, the 205 when the radio plan has a channel on it, the 205A, 207 and a 204 per division. Because the forms are generated from what you have already entered, they reflect the incident as it actually stands rather than what someone remembered at form-filling time; where the record has no data for a block, the block is left blank for hand entry, as the FEMA form would be. Block 4 of the 201 (Map/Sketch) carries a street map with a pin at the incident location when the incident has coordinates. Exercises are stamped EXERCISE on every page.

Situation reports are numbered and separate from the forms: a SITREP snapshots the boards’ figures when it is approved and freezes them, so the 1200 numbers stay the 1200 numbers. Position checklists and shift handoff briefings live on the Positions tab; a handoff is frozen when the incoming person accepts it.

Generate the status summary before you are asked for it. It is the form most often needed at short notice and the one most painful to assemble by hand.

Sharing with partners

An incident can be shared as a live link with agencies that do not have Calchis accounts. They see the current picture, updating as it changes, without needing a login or a copy of anything.

This is the alternative to the situation report emailed every two hours, which is stale on arrival and forks into as many versions as there are recipients. For structured coordination across agencies — resource requests and mutual aid rather than shared visibility — see multi-agency federation.

After the incident

The after-action report is built from the record: the timeline of status changes, activations, operational periods, SITREPs and IAPs, with the boards’ final figures, in the HSEEP shape. Files gathered during the response sit in the incident’s file library. Close the incident when the response ends (a closed incident can be reopened with a reason); archive it before deleting, and the archive is the whole record.

The most useful thing you can do at closure takes two minutes: note what the record does not capture — the decision made on a phone call, the resource that arrived late and why. That is the part nobody remembers in six months and the part the next activation needs.

Availability

The EOC suite is an Agency capability — see pricing.