Rescue plans

Why it's mandatory

ICOP Annex R requires a documented rescue plan before any rope access work begins. No plan, no work — that's the rule, and an auditor checking the job pack will look for the plan, the rescue method, the designated rescuer, and the senior who confirmed it.

The rescue plan answers a single question: if a technician is incapacitated on rope right now, who reaches them, with what technique, in how long? Vague answers fail the audit. Specific answers save lives.

One plan per site per day

RopeLogix uses a site-based rescue plan — one plan per building per day, shared across every job running at that site. Open the job, tap the Rescue Plan card. RopeLogix loads today's site rescue plan; if no plan exists yet for this site today, it starts the derive flow.

The SWMS may reference rescue procedures, but the rescue plan itself isn't embedded in the SWMS body. That's deliberate — one source of truth, one version chain, one confirming senior.

Carry-forward

If a confirmed rescue plan exists for this site from the previous day, today's plan is pre-filled from it automatically. A blue banner appears: “Pre-filled from yesterday's confirmed plan for this site. Review all fields and re-confirm.”

Derive inputs

When deriving a fresh plan, the senior confirms four inputs about today's site conditions:

• ● Worst-case casualty mode — what the casualty is most likely doing at time of incident: descent, ascent, mid-rope transfer, aid-climb, or fall-arrest.
• ● Releasable rig pre-configured — whether the system is rigged for releasable lower (SR-1 prerequisite).
• ● Rigging obstructions on the rescue route — deviation, re-anchor, mid-rope knots, horizontal traversal required, and wide re-anchor gap (>1.5 m).

The rest of the engine inputs — drop heights, aerial access, crew IRATA levels, equipment checks — are drawn automatically from today's pre-start and the job's SWMS drop data.

Smart method suggestion

After the senior answers the derive inputs, the engine runs a deterministic ICOP method-selection cascade. It combines the senior's inputs with the pre-start data (crew IRATA levels, equipment checks) and the SWMS drop data (descent heights, aerial access, emergency services lead time) to suggest the optimal rescue method.

The result shows: the suggested method (e.g. Releasable lower SR-1, Descent with casualty SI-2), its ICOP category, the minimum IRATA level required, plain-English reasons, and any guardrail advisories (e.g. “method requires min IRATA L2; highest present today is L1”).

Confirming the plan — designated rescuer required

Before the plan can be confirmed, the senior must:

• ● Select the rescue method (engine's suggestion or override).
• ● Assign a Designated Rescuer — the specific crew member who will execute the rescue if needed. This is a hard block (G1): the plan cannot be confirmed without one. The designated rescuer must be a different person from the senior on site.
• ● Set a target rescue time (minutes).

The senior's confirmation is the authoritative record. Only the senior on site confirms the plan — there is no crew-wide multi-party sign-off on the rescue plan itself.

Amending after confirmation

If conditions change — anchor moves, access route changes, weather shifts — tap Amend plan (conditions changed). A new iteration is added to the plan; prior iterations are never overwritten. Tap the version counter at the bottom of the plan to expand the full iteration history inline.

Templates

ORG_ADMIN users can create and manage rescue plan templates at Settings → Rescue plan templates in the web app. When deriving today's plan, tap Start from template to pre-fill the method and defaults. The senior can override anything — the template is a starting point, and the engine still runs its suggestion independently.

Why the rescue plan is its own form

The AI-generated SWMS used to include a rescue section in the body. That created two sources of truth: the rescue text in the SWMS, and the standalone rescue plan — each with its own version history. When they drifted, nobody knew which was authoritative.

The AI now skips rescue deliberately. The site rescue plan is the one source of truth — its own form, its own version chain, its own confirming senior. The SWMS may name-check the rescue plan but doesn't duplicate it.

Audit pack export

Confirmed rescue plans appear in the job's export pack alongside the SWMS, pre-starts, and toolbox talks. Every iteration is included with its method, designated rescuer, target time, and the guardrail warnings acknowledged at confirm — so the auditor can see the rescue posture at every point in the job's timeline.