-
-
Notifications
You must be signed in to change notification settings - Fork 0
ICS Forms
Since IRIS-NG-v2.1.1. Every war room gets a set of Incident Command System forms as room
notes: ICS 201 Incident Briefing, ICS 202 Incident Objectives and ICS 203
Organization Assignment List. They keep the FEMA numbering and field labels, so they
read as the real forms, and they are filled in three passes, in this order:
-
Deterministic seed — the moment the first case is attached, the three notes are
created in an
ICSfolder on the room's Notes tab and prefilled with what the database can answer directly. - AI pass — when an AI backend is configured, a second pass proposes text for the fields that are still empty, from the attached cases' material. Every fill is marked.
- The Incident Commander — reviews, edits and owns the notes from then on. Neither earlier pass ever rewrites what a person wrote.
Only what the room already knows. Nothing is invented at this stage.
| Form | Prefilled from room and case data |
|---|---|
| ICS 201 | Incident name (the room), date/time initiated, the attached cases as a table (customer, severity, state, opened, owner), room severity and status, the room summary, prepared-by, the lead as Incident Commander, the member list with room roles |
| ICS 202 | Incident name, the room summary as situational awareness, the attached cases inline, prepared-by, the lead as approving Incident Commander |
| ICS 203 | Incident name, the lead as Incident Commander, responders in the Operations Section, observers as Agency / Organization Representatives, prepared-by |
Every other field is a dash (—) for the Incident Commander to fill.
Rules that matter:
- One set per room. Attaching a second case adds nothing and changes nothing. The tables on the forms are a snapshot at seed time, not a live view.
- A seeded note is never edited by the seed. Once it exists it belongs to the analyst. Deleting a form and seeding again re-creates that one form from current data; the others are untouched.
-
Seeding is keyed on the note titles, not the folder. Deleting the
ICSfolder moves its notes to the root, as any folder delete does, and the forms are still recognised there. - The clipboard icon in the Notes rail header, Seed ICS forms, adds any form that is missing — one that was deleted, or a room created before this feature — and leaves the rest alone. It is safe to click repeatedly.
- A seeding failure never fails the case attachment. The forms are a convenience; the attachment is the analyst's action.
The AI pass runs automatically after the seed when an AI backend is configured (AI Features), and on demand from the sparkle icon in the Notes rail header. It is given the room, the attached cases (descriptions, tags, their cached executive summaries when one exists, open tasks and server-computed counts), the members with their roles, and recent room and case activity. It returns a proposal for these fields only:
| Form | Fields the AI may propose |
|---|---|
| ICS 201 | §4 situation summary and health & safety, §6 objectives, §7 actions to date, §9 resources |
| ICS 202 | §3 objectives, §4 command emphasis and situational awareness, §5 site safety plan required |
| ICS 203 | Deputy IC, Liaison Officer, Planning Section Chief, Situation Unit, Documentation Unit, Technical Specialists, Operations Section Chief |
Deliberately not proposed: operational periods (a command decision), the 201 Current Organization positions, and the Safety and Public Information Officers.
How it behaves:
- Only empty fields are filled. A list where the analyst has already written one item, a table with a real row, a summary the seed already carried — all left alone. Running the pass again is safe; it fills nothing and says so.
- Every fill is marked. A line at the top of the note lists which fields the AI filled, with the model and time, and each filled block carries the line AI draft — review before relying on it. Delete that line once you have reviewed the content.
- ICS 203 names are constrained. The model may only name room members and owners of the attached cases. The lead is already Incident Commander and is not a candidate. One person holds one position; a second placement for the same person is dropped, and so is any name the model invents. On a room with only a lead, the 203 stays as seeded — that is the honest answer, not a failure.
- Health & safety is usually left empty. The model fills it only when the case material mentions physical or personnel conditions.
- A failed call changes nothing. No backend configured, a backend outage, a reply the server cannot parse — the forms are untouched and the Notes rail says why.
- The proposal is cached, so re-running over unchanged case data costs no model call. Re-seed a deleted form and the cached proposal fills it immediately.
- The pass runs as a background job. If you have one of the forms open in the editor when it finishes, the view is not replaced under you; reopen the note to see the fill. Editing a form while the pass is running means your next autosave wins over the fill.
All under /api/v2/war-rooms/<id> and gated by room role, like the rest of the room
API. A non-member gets a 404.
| Method | Path | Role | Description |
|---|---|---|---|
GET |
/notes/ics |
observer | Which forms are present and missing, with note ids |
POST |
/notes/ics/seed |
responder | Create the missing forms (deterministic seed); existing forms untouched. Returns created, skipped, note_ids, and ai_task_id when the AI pass was queued |
POST |
/notes/ics/ai-draft |
responder | Seed any missing form, then run the AI pass. Returns 202 with a task_id to poll at /api/v2/ai/jobs/<task_id>; ?sync=true runs inline and returns what was filled. Body {"force": true} bypasses the proposal cache |
The case-attach response carries ics_seeded (the titles created) and ics_ai_task_id
(the queued AI job, or null). A closed room refuses all three writes.
The three templates are bundled with the release under
source/app/resources/ics_note_templates/. Editing them per instance is on the
backlog, together with further forms (204, 205A, 209, 214). Until then, an instance
that wants different wording edits the seeded notes; the seed never overwrites them.