Study AUVSI TOP Level 3 by learning the decision frameworks that advanced UAS operations are built on: hazard and risk vocabulary, likelihood-by-severity assessment, PAVE pre-mission screening, DECIDE in-flight decision-making, and crew resource management. Work scenarios until you can justify a go/no-go call in writing, then score yourself with the rubric in the final section. Confirm administrative details such as eligibility and booking directly with AUVSI, since those change and are not covered here.
Level 3 preparation starts with the competency map, not the question bank
Before drilling questions, map what the credential actually certifies: AUVSI describes the Trusted Operator Program as a tiered pathway, and the top tier is associated with advanced, higher-responsibility operations. Anchor every study session to a named competency rather than to isolated facts.
Pull the official TOP materials and write out the competency areas in your own words. For each area, note which aviation concepts it implies: risk assessment, aeronautical decision-making, human factors, safety management thinking, and operational procedures. This turns a long syllabus into a small number of frameworks you can rehearse. A concept-first map also tells you what not to over-study; if a topic has no decision attached to it, it probably needs one reading pass, not flashcards.
Order your study by framework depth, not by page count. Spend your first block on hazard-versus-risk vocabulary, your second on the risk matrix and mitigation types, your third on pre-mission and in-flight decision models, and your fourth on crew and human-factors material. Each block should end with one written scenario. This sequence works because later concepts reuse earlier ones: you cannot apply DECIDE mid-flight unless you can already classify hazards and judge severity quickly.
- Week-shape: vocabulary first, matrix second, decision models third, crew factors fourth
- Every study block ends with one written go/no-go scenario, not a quiz score
- Keep a one-page glossary of terms you define yourself, then check it against official definitions
Hazard, risk, and mitigation are three different words - stop using them interchangeably
A hazard is a condition with potential to cause harm; risk is the judged likelihood and severity of that harm in a specific operation; a mitigation is a control you add to change one of those two judgments. Confusing the three produces vague answers and weak safety cases.
Practice the separation with a running example. A worn propeller is a hazard. The risk in a given mission is the chance that it fails in flight combined with what that failure would damage. Grounding the aircraft until the propeller is replaced is a mitigation that removes the hazard; a lighter mitigation, such as re-inspecting it before each flight, only changes your likelihood estimate. When you can state all three for any condition you notice, you are doing the analytical work that operational assessments ask for.
Build this into a habit: whenever you read any scenario, write three lines - hazard, risk judgment, mitigation - before answering anything else. The discipline matters because risk is conditional. The same hazard carries very different risk in a closed agricultural field versus a public event site, and a mitigation that is proportionate in one may be inadequate in the other. Examiners and employers alike are looking for the conditional reasoning, not a memorized definition.
| Concept | What it is | Example | What you do with it |
|---|---|---|---|
| Hazard | A condition with potential to cause harm | Worn propeller; low sun angle; unsecured bystander line | Identify and record it during planning |
| Risk | Judged likelihood and severity of harm in this operation | Prop failure near spectators: low likelihood, high severity | Rate it on a likelihood-by-severity matrix |
| Mitigation | A control that changes likelihood or severity | Replacement prop; re-inspection; cordon and crew spotter | Apply, then re-rate the residual risk |
Worked scenario: rating a mission with the likelihood-by-severity matrix
Scenario: you plan a photogrammetry flight over a rural site with a farm track 80 meters away, forecast winds gusting to your airframe's practical limit, and one crew member. Rate the risk, choose mitigations, and re-rate. The common mistake is treating severity as fixed.
Plausible mistake: a planner rates the gusting wind as high severity and high likelihood, declares the mission too risky, and cancels. Severity is not wrong - losing control near any occupied area is severe - but the cancellation decision came from a single cell of the matrix rather than from comparing mitigations. A better process: rate wind as moderate likelihood, high severity; add mitigations that attack likelihood specifically, such as launching from a position that shortens exposure to the gust line, reducing the flight area to the windward portion, and setting a hard abort wind threshold checked at the site. The residual rating drops to acceptable-with-controls.
A second scenario variant shows why severity moves too: move the same flight to a site where the downwind area contains a busy road. Now the same wind hazard has higher severity because a flyaway consequence lands on traffic. The correct response shifts from likelihood mitigations to consequence mitigations - reorient the flight line so a failure path clears the road, or choose a different site entirely. The lesson is that the matrix is a tool for comparing options, not a score to report; every rating change should be traceable to a named mitigation.
Practice this with a numbered 5-by-5 matrix you draw yourself. Take five invented sites and one aircraft, vary only bystander exposure and terrain, and write the rating before and after two mitigations each. Expected observation: your post-mitigation ratings should drop along one axis at a time - likelihood for exposure controls, severity for consequence controls. If both numbers drop for the same mitigation, you have probably double-counted a single control.
PAVE screens the mission before you leave; DECIDE decides when conditions change
PAVE is a pre-mission checklist across Pilot, Aircraft, enVironment, and External pressures. DECIDE is an in-flight loop: Detect, Estimate, Choose, Identify, Do, Evaluate. They differ in timing, and using the wrong one at the wrong moment wastes the little time you have.
Use PAVE on the ground, where time is abundant. Walk each letter: is the pilot current, rested, and within any personal limit you set; is the aircraft inspected, charged, and configured for the payload; what are the weather, airspace, terrain, and people factors; what pressures - a client waiting, fading light, an approaching deadline - might push you past your own judgment. PAVE works because external pressures are named explicitly; a pressure you never say out loud still steers your decisions. Write the PAVE result as a go/no-go with conditions, not a feeling.
Use DECIDE once airborne, where time is scarce. Detect the change, estimate its effect on the mission, choose among options, identify the one you will act on, do it, then evaluate whether it worked. The key difference is cadence: PAVE is a one-time gate with rich analysis, while DECIDE must complete in seconds and favors the option that reduces immediate danger first, mission second. Rehearse DECIDE out loud on scripted changes - a gust front, a lost link, a person entering the area - until the order of the letters is automatic, because under stress you will fall back on whatever sequence you drilled.
- PAVE: Pilot, Aircraft, enVironment, External pressures - a ground-phase gate
- DECIDE: Detect, Estimate, Choose, Identify, Do, Evaluate - an airborne loop
- Write PAVE as go / conditional go / no-go, with the condition stated precisely
Worked scenario: plan continuation bias when the light starts to fail
Scenario: a mapping flight is 70 percent complete when cloud thickens and your minimum usable contrast threshold is nearly reached; the client is watching and asks to finish. The realistic mistake is incremental continuation; the better decision comes from a pre-committed limit.
Plausible mistake: the operator decides the last two survey lines look 'probably fine' and continues, then re-decides the same thing at the next line, and the next. Each individual call feels defensible, which is exactly how plan continuation bias works - the decision keeps being remade in small increments against a moving baseline, so the operation drifts past the point where anyone would have approved it from the start. The cost compounds: image quality degrades, the deliverable fails review, and the reflight costs more than the aborted flight would have.
Better decision: at the pre-mission PAVE step, write an objective abort criterion - for example, a ground target becomes unreadable at a set distance, or a set clock time passes - and tell the crew the criterion before launch. In flight, when the criterion trips, the DECIDE sequence is short: detect the trip, estimate that data quality is now below contract, choose to land, identify the recovery point, do it, and evaluate afterward that the remaining lines are scheduled for reflight. The criterion converts an emotional negotiation into a factual trigger, and the crew briefing recruits the client-facing pressure into the solution instead of against it.
Why it matters: this scenario has no dramatic failure - the aircraft lands safely either way. The damage is to the safety system itself, because every time a stated limit bends under pressure, the crew learns that limits are negotiable. Practicing the written-criterion habit on low-stakes training flights is what makes it available on the flights where the pressure is real.
Multi-person UAS work runs on crew resource management, not on a single strong pilot
Crew resource management (CRM) is the practice of using every crew member's information and authority well: defined roles, closed-loop communication, and a norm that any crew member can call a stop. Single-pilot habits - silent planning, unspoken assumptions - are what CRM replaces.
Start with role definition for the common UAS crew: the pilot in command flies and holds final authority; a visual observer tracks the aircraft and the airspace; a mission coordinator handles bystanders, the client, and the clock. The CRM skill is not assigning the roles but running closed-loop communication: the observer says 'aircraft, two o'clock, low,' and the pilot repeats it back, so both know the message landed. Brief the communication phrases before launch, not during the event; improvised warnings under load are slower and ambiguous.
Then rehearse the challenge culture. CRM holds that any crew member who sees a safety problem should voice it plainly, and the decision-maker should acknowledge it and either act or explain why not. Practice with a role-play: your observer calls that a person has walked inside your planned area while you are mid-task. A weak response is continuing while 'watching it'; a CRM response is a DECIDE-style call to pause or reposition, with the observer confirming the area is clear before resuming. Debrief each role-play on two questions only: was information shared early enough, and was the stop authority real?
- Closed-loop communication: every warning is repeated back by the receiver
- Roles: pilot in command, visual observer, mission coordinator - briefed before launch
- Stop authority belongs to every crew member; debrief whether it was actually used
Self-check rubric and a four-week preparation sequence you can adapt
Score yourself weekly on written scenarios using five criteria: correct hazard-risk-mitigation separation, a traceable matrix rating, a stated PAVE gate, a DECIDE sequence under time pressure, and a named crew factor. A milestone of 4 of 5 consistently indicates concept fluency, not a passing prediction.
The rubric: take any new scenario and write a half-page response. Score one point each for - (1) naming the hazard separately from the risk; (2) giving a likelihood-and-severity rating and listing which axis each mitigation moves; (3) stating a PAVE gate with an objective abort criterion; (4) writing the DECIDE steps for the scenario's in-flight change in under five lines; (5) naming one human factor and one CRM behavior that applies. Scores are learning milestones for your own tracking; they tell you which framework is weak, and they are not a prediction of any exam outcome.
A realistic adaptable sequence: weeks one and two, one framework block per session plus one written scenario, aiming for rubric scores of 2-3; week three, time-limited scenarios at ten minutes each, and one role-played CRM exercise with a study partner, aiming for 4; week four, mixed scenarios where two frameworks overlap - for example, a client pressure that trips your abort criterion mid-flight - plus a review of your own written responses from week one to see the vocabulary improve. For administrative matters such as eligibility, scheduling, and current program requirements, check directly with AUVSI at auvsi.org, since those details sit outside this study plan.
Readiness checks to finish with: you can define hazard, risk, and mitigation without notes and give a fresh example of each; you can draw and use the matrix from memory, moving one axis per mitigation; you can recite PAVE and DECIDE and say which one belongs on the ground; you can write a closed-loop communication exchange for a stray-person event in under a minute. If any check fails, return to that framework's section and redo one written scenario before moving on.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.