Emergency Plans and Incident Records

An emergency plan is a decision you make before stress makes the decision harder.

An incident record is the evidence you preserve after something abnormal happens.

Those are different tools, and a strong operation needs both.

Emergency planning starts with conditions, not panic

“Emergency” is too broad to be useful by itself.

A mission plan should identify specific abnormal conditions such as:

• lost or degraded command link;
• unexpected aircraft behavior;
• low-energy or power-system warning;
• navigation-state failure;
• person or vehicle entering the operating area;
• weather moving outside the approved limit;
• payload or data failure that invalidates the mission;
• aircraft damage after an impact or abnormal landing;
• battery abnormality found during handling.

Each condition needs a preplanned decision path.

Do not invent live-flight responses from this course. Real emergency actions must come from the aircraft documentation, current operating rules, qualified operator training, and the organization’s approved procedure.

Plan authority before the abnormal event

A weak plan says:

If something goes wrong, somebody should tell the pilot.

A stronger plan defines:

• who can call an immediate abort;
• who holds operational authority;
• which condition requires no-go or termination of the mission objective;
• who handles the ground/site response;
• who preserves records;
• who contacts school administration or emergency services under the approved procedure.

Under stress, ambiguous authority creates delay.

Separate aircraft response from human response

Suppose a simulated lost-link condition occurs.

Two systems respond:

Aircraft/autopilot response

The configured platform behavior executes according to its documented logic.

Crew response

The crew recognizes the condition, communicates, protects the operating area, follows the approved procedure, and decides what happens next when human authority is available.

The crew should understand the automation without assuming the automation eliminates the crew’s responsibilities.

Emergency memory aids should be short

A long paragraph is hard to use during a fast-moving abnormal event.

A classroom emergency card might use this structure:

CONDITION
→ CALL / ACKNOWLEDGE
→ PROTECT PEOPLE / AREA
→ EXECUTE APPROVED RESPONSE
→ STOP MISSION OBJECTIVE
→ PRESERVE EVIDENCE
→ ESCALATE / REPORT UNDER PROCEDURE

The exact actions belong to the approved platform and school procedure. The structure is what matters: recognize, communicate, control the immediate hazard, then preserve information.

Incident records should begin with facts

After an abnormal event, memory changes quickly.

Write down facts while they are fresh.

Useful fields include:

• date/time;
• mission/configuration identifier;
• people/roles involved;
• weather/site state;
• aircraft/payload state before event;
• event sequence;
• warnings or telemetry observed;
• commands/actions taken;
• final aircraft/site condition;
• injuries or property effects if any;
• evidence files preserved;
• unresolved questions.

Avoid root-cause conclusions in the initial fact section unless evidence already proves them.

Build a timeline before a story

Suppose a fictional mission packet says:

10:14:02 — position-hold mode active
10:14:07 — navigation warning appears
10:14:09 — aircraft begins lateral drift in simulator
10:14:10 — abort call recorded
10:14:12 — approved recovery state begins
10:14:28 — simulated aircraft reaches recovery area

That timeline is more useful than:

GPS failed and the drone almost flew away.

The second sentence compresses observations and assumptions into one dramatic conclusion.

The timeline lets investigators ask which state changed first.

Preserve evidence before “fixing” the system

A common post-incident mistake is immediately changing settings, clearing logs, updating firmware, repairing configuration, or reorganizing files before the original state is preserved.

For a classroom simulation, preserve:

• screenshots;
• logs;
• mission file/version;
• configuration snapshot;
• site/weather packet;
• checklist version;
• crew notes;
• payload output.

Then make changes in a copy or documented new revision.

Otherwise the repair can erase the evidence needed to understand the failure.

Internal record versus external reporting

A school incident record and a regulatory report are not the same artifact.

Real FAA reporting obligations depend on the applicable operating framework, the event, and current rules. For example, Part 107 has specific accident-reporting requirements and timelines for certain events.

Students should not decide those obligations from memory.

The qualified operator or responsible organization should check current FAA requirements and the school’s reporting procedure.

Current FAA Part 107 information is available at:

• FAA — Part 107 Small UAS Regulations

Your classroom record is designed to preserve evidence so the responsible adult can make that determination correctly.

Worked incident: abnormal battery discovered before operation

Not every incident happens in the air.

A fictional crew finds a swollen battery during pre-operation inspection.

The correct sequence is not “nothing happened, so no record needed.”

A useful record captures:

• pack ID;
• observed condition;
• where/when it was found;
• previous known status;
• no-go decision;
• adult escalation;
• updated equipment status;
• whether similar packs/configuration need review.

That record turns one caught hazard into organizational learning.

Near miss is useful evidence

A near miss is an event where harm did not occur but the sequence revealed a meaningful weakness.

Example classroom scenario:

• student notices recovery zone is occupied seconds before a simulated approach;
• mission is held;
• nobody is injured and nothing is damaged.

The absence of harm does not mean the system was strong.

Ask:

Why did the conflict survive until the final seconds?

Maybe the checklist timing was wrong. Maybe crew ownership was unclear. Maybe the site status was not rechecked.

Near misses let you improve the system without paying the full cost of failure.

Build an emergency-and-incident packet

For one supplied scenario, create:

Emergency card

• condition;
• immediate call;
• authority;
• approved response reference;
• site/person protection action;
• escalation path.

Incident timeline

At least five timestamped or ordered events.

Evidence inventory

List every file, screenshot, configuration, and note to preserve.

Unknowns

Write three questions the initial record cannot answer.

Follow-up ownership

Who reviews aircraft/configuration, site procedure, data, and current reporting obligations?

Misconception: incident documentation is about blame

Blame makes people hide information.

Engineering review needs accurate evidence.

The first job is to reconstruct what the system and people did, which controls worked, which controls failed, and what should change.

Accountability matters, but it should be built on evidence rather than guesses made five minutes after an event.

The Week 12 idea

Emergency planning and incident documentation form a loop:

anticipate failure → define authority and response → detect abnormal condition → protect people/system → preserve evidence → learn → revise procedure

The operation gets stronger when the lesson from one event changes the system instead of living only in somebody’s memory.