ICAO Annex 13 crisis response
in your system of record.

See the highlighted block above the contents list. The rest of this article walks through why binders and group chats fail under pressure, what declaring an event and picking its type actually does, how the role-laned and dependency-sequenced task board works, and why it sits on the same records as the rest of your safety operation.

Most operators have an emergency response plan. It is usually a printed binder, sometimes a shared document, describing who to call and what to do when a serious event happens. It is written carefully, reviewed annually, and almost never opened at the one moment it matters — the first hour after an event, when several people are reacting at once and the situation is still moving.

In that hour, the binder and the group chat that springs up alongside it share the same three failures:

• Nothing is sequenced. The binder lists tasks; it does not enforce the order they must happen in. The recorders and other data should be preserved before the scene is disturbed, but a checklist on paper cannot stop a later step from starting before an earlier one is done.
• Nothing is role-assigned.A group chat is a single stream everyone reads and nobody owns. “Has someone called the authority?” is asked three times and answered none, because no task belongs to a named role with a clear hand.
• Nothing is recorded.When the event is later reviewed, the only history is a chat scrollback and people's memory. There is no reliable record of who did what and when — which is exactly what an investigation and an oversight review will ask for.

None of this is a failure of the people. It is a failure of the tool. A binder cannot sequence, a chat cannot assign, and neither can record. Under pressure that is when steps get skipped, duplicated, or done in the wrong order — the precise opposite of what an Annex 13-aligned response is supposed to guarantee.

In eAviora the response starts with a single deliberate action: declare an event and pick its type. The type is not a free-text box. It is chosen from a list driven by an ICAO Annex 13 taxonomy — a standard set of event categories rather than whatever wording the person at the keyboard reaches for at the worst possible moment.

Picking the type is what tells the platform which response to deploy. The declaration and the response plan are one action, not two. The moment the event is declared and typed, the matching task board appears — already populated, already laned by role, already in sequence. There is no intervening step where someone has to find the right binder, photocopy a checklist, or start a chat and hope the right people see it.

This matters because the first decision in a crisis — what kind of event is this — is the one most likely to be rushed. Anchoring it to a standard taxonomy means the response that follows is the right one for the event, not the one the loudest voice in the room remembered.

The board the platform deploys does the two things a binder and a chat cannot: it lanes tasks by role, and it sequences them by dependency.

Laned by role.Every task belongs to a role — who does what. Each person sees their own lane and their own list, not a single stream everyone has to scan. The question “whose job is this?” is answered before anyone has to ask it, so two people do not both chase the same call while a third task goes untouched.

Dependency-sequenced. Tasks are ordered so a later step cannot run ahead of the one it depends on. The load-bearing first moves of an Annex 13-aligned response come in the order they are meant to happen:

• State notification— notifying the relevant state authority of the event, on the clock that obligation runs on.
• Recorder and data preservation— securing the recorders and other evidence before the scene is disturbed, so nothing the investigation needs is lost in the response.
• Family assistance— standing up the support owed to those affected, as its own laned responsibility rather than an afterthought.
• Investigation— opening the investigation that the safety team will carry forward once the immediate response settles.

Because the order is built into the board rather than printed on a page, the sequence holds even when several people are working in parallel. A workflow that cannot skip a step is the whole point: under pressure, the structure carries the discipline so the people do not have to hold it in their heads.

The reason the crisis cockpit is more than a better checklist is where it lives. The occurrence and its investigation are already linked records in the same connected operation. When you declare a crisis event, the response sits on those same records — not in a separate binder, not in a separate tool, not in a chat that disappears when the thread scrolls.

In practice that means:

• One investigation, not two. The investigation you open during the response is the same investigation your safety team continues afterward, with one continuous history. There is no hand-off from a crisis binder into a safety system, because the response was never separate from it.
• The same audit trail.Every task done on the response board is recorded against the same linked records as your safety data — who did what, when, in what order. When the event is later reviewed by the investigation team or by oversight, the history is already there, not reconstructed from memory.
• No second source of truth. The response, the occurrence, and the investigation are one connected operation. Nothing has to be copied from a crisis document back into the safety records, because they were the same records the whole time.

The contrast is the entire argument. A printed binder plus an ad-hoc group chat gives you a plan that is not sequenced, not assigned, and not recorded. A response cockpit wired into the same operation gives you one that is all three — and that carries straight into the investigation and the oversight review without a single re-key.

The relevant surfaces: SMS module, Regulatory module. See how we handle your data or contact us to discuss your operation.