Conditions worth waking someone for

A CCIR — a commander's critical information requirement — is not an alert rule. It is a condition you have decided in advance is worth waking someone for, paired with the decision it forces. The pairing is the whole point. "Wildfire in my county" is a notification. "Wildfire in my county → decide the activation level and confirm evacuation trigger points with the IMT" is a decision aid.

Written down in advance, at 2pm, by people who are thinking clearly. Read at 3am by whoever is on duty.

What you start with

Calchis ships a default set, visible at Information Requirements. They are deliberately generic: every one is evaluable from federal data the platform already holds, and every decision is phrased as something a duty officer can actually do. They are a starting point, not doctrine.

Making them yours

Your real requirements come from your own plans, so the set is editable. On the same page, Edit conditions lets you:

Change what a default says. The decision text is the part that is genuinely local. "Open a shelter" is a default; "open the Lincoln Street shelter and notify Red Cross" is yours.

Switch a default off. It stays on the editor, greyed, with a way back. Turning a condition off is a decision, and a decision you cannot see is one you cannot revisit. Your edits are kept, so switching it back on restores what you wrote rather than the shipped text.

Add your own. A name and the decision it forces are both required. A condition with no decision is an alert rule, which is the one thing a CCIR is defined as not being.

If your account belongs to an agency, the set is the agency's and everyone in it sees the same list. A condition list that differs per person is not a commander's list.

What happens when one fires

Conditions are evaluated against live events inside the areas you monitor, and against each incident's own location. Three things follow.

The incident shows it. An escalation prompt names the condition, the event that met it, and the decision it forces — with a button that opens the decision form pre-filled. The product suggests; the duty officer decides. The record shows which of them did what.

The boards show it. The incident wall and the EOC board both carry a count of conditions that have fired with nothing raised against them. That count is the one number on those screens that means someone has to decide something now; everything else is a standing total.

Someone is told. A condition that fires with no decision raised sends an email to the people working the incident. It is sent once, reminded at most a few times while it is still unaddressed, and stops the moment a decision is raised. A condition that stops firing is forgotten, so if it fires again next week that is news again. See being told at 3am.

Raising the decision

A decision point is that decision as an object: a number the room says out loud ("DP‑3"), an owning ICS position, a deadline, and a state. Several conditions can bear on one decision.

Raising one is deliberately cheap — a title and when it is due. Recording what was decided is the prominent action, because that is the line the ICS‑214 and the after‑action review read back. A recorded decision cannot be edited: a correction is a new decision point that supersedes it. Editing history to say a decision was never taken is the one thing an after-action review must not permit.

What this does not do

It does not dispatch, it does not decide, and it carries no authority. Conditions fire on public federal data with the same latency as the feed behind them. Treat the product as decision support and verify against official sources — which is exactly what the decision text is for.