
SAT and ADDIE are not competing frameworks and neither is a document template. They are a way of reasoning from the job backwards, so that every hour of training traces to something the work actually requires. This is how we apply them, and how our software enforces them.
The systematic approach to training, usually shortened to SAT, is a discipline for deciding what to train and proving the decision was sound. It starts from the job rather than from available content, and it insists that every step can be traced to the step before it.
That single insistence is what separates it from course design. If you cannot say which task an objective came from, or which objective a test question assesses, you do not have a systematic program. You have a catalog.
ADDIE is the phase model most people use to run SAT: analysis, design, development, implementation, evaluation. SAT is the logic, ADDIE is the sequence. Confusing the two is the most common reason programs end up with beautifully produced training that nobody can defend.
The validated task list is not one document among several. It is the source every other artifact traces back to, which is why an out-of-date task list quietly invalidates everything downstream of it.
Five phases. The order matters, and so does the fact that the last one feeds the first.
Analysis
What does the job require
Job analysis, then task analysis. Identify the duties and tasks a role performs, then decide which need training at all, using difficulty, importance and frequency rather than instinct.
Design
What will people be able to do
Turn selected tasks into objectives, sequence them by prerequisite, choose the setting and strategy for each, and decide up front how each one will be assessed.
Development
Build what teaches it
Lesson plans, job aids, OJT guides, simulator scenarios and test items. Everything carries the objective it serves, so nothing exists without a reason.
Implementation
Deliver and record it
Deliver, assess, and capture the evidence as you go: who was trained, by whom, against which standard, and who signed the qualification.
Evaluation
Did it change the work
Reaction and learning are the easy measures. The one that matters is whether performance on the job changed, and that answer goes straight back into analysis.
Evaluation is not the end of the line. A program that never revisits its analysis is drifting away from the job whether or not it passes review.
Most weak programs are weak here. An objective that cannot be observed cannot be assessed, and an objective without a standard cannot be argued for.
Behavior
An action somebody can watch. Align, isolate, calculate, verify. Not understand, be familiar with, or appreciate, none of which can be observed or tested.
Condition
Given the procedure, given a simulated loss of offsite power, without reference material. The condition is what makes the objective testable in a way everyone agrees on.
Standard
Within ten minutes, to the tolerance in the procedure, with no critical step omitted. Without a standard, passing is whatever the evaluator felt that day.
Weak: Understand the emergency diesel generator start sequence.
Defensible: Given the applicable operating procedure and a simulated loss of offsite power, start and load the emergency diesel generator within the time limit stated in the procedure, with no critical step omitted.
The second version tells you what to teach, what to build, and exactly what to assess. The first tells you nothing.
A reviewer can watch a class and learn very little. What they test is the reasoning underneath it.
The setting is a design decision, not a budget decision. Match it to what the objective asks a person to do.
Cross-referencing the behavior an objective asks for against the type of content it covers is what instructional designers call a behavior and content matrix. It is a way of making the setting decision defensible rather than habitual.
A method only survives contact with a real program if something holds the links together. That is what both our platforms are for.
An authoring environment and a learning station on one set of data. Analysis, objectives, program structure, questions, tests and qualification cards are separate objects that stay connected, so changing a task surfaces everything downstream of it.
One cloud application arranged around the phases themselves: analysis, design and development, implementation, evaluation. If you want the method visible in the navigation, this is what that looks like.
Neither one decides what qualified means. That judgment stays with your program, which is why our services team and our software are designed together.









Everything upstream of this room is invisible to the people sitting in it. They see a class. What the standard cares about is the chain behind it: the task that justified the class, the objective derived from that task, the assessment that proves the objective, and the qualification the whole thing supports.
Delivery is the part everyone can see and the part least likely to be the problem. When a program fails an evaluation it is almost never because the class was bad.
The questions people actually search for, answered directly.
It is a method for deciding what to train based on what a job requires, and for keeping the reasoning traceable. You identify and validate the tasks a role performs, select which need training, write objectives derived from those tasks, build training and assessments against those objectives, and keep the evidence that links them. In regulated industries it is the expected basis for a qualification program.
SAT is the logic and ADDIE is the sequence. SAT says training must derive from validated job tasks and stay traceable to them. ADDIE names the five phases you move through to do that: analysis, design, development, implementation and evaluation. They are not alternatives, and a program can follow ADDIE's phases while failing SAT entirely if the analysis was never grounded in the job.
Analysis, establishing what the job requires and which tasks need training. Design, turning those tasks into sequenced objectives with an assessment plan. Development, building the materials and test items. Implementation, delivering and recording. Evaluation, measuring whether job performance changed and feeding that back into analysis.
The criticism is that it is slow and linear, and that is fair when it is run as a waterfall with one review at the end. It is not fair to the phases themselves, which are just a description of the work. In regulated training the traceability ADDIE produces is the whole point, because a reviewer will ask you to show it. Run the phases iteratively and the objection largely disappears.
Three parts. A behavior somebody can observe, the condition it is performed under, and the standard it is measured against. “Understand the start sequence” fails all three. “Given the operating procedure and a simulated loss of offsite power, start and load the diesel generator within the procedural time limit with no critical step omitted” passes all three, and tells you what to build and what to assess.
Annually as a rhythm, and immediately after anything that changes the work: a plant modification, a procedure revision, a reorganization that moves tasks between roles, or an event whose review points at a training gap. The most common finding we see is a task list that has not been revisited since the last evaluation, in a group whose scope has changed twice since.
No, and plenty of programs run on spreadsheets and shared drives. What software changes is what happens when something moves. Change a task by hand and somebody has to remember every objective, lesson, test item and qualification it touches. In a system that holds those as linked objects, the change surfaces its own consequences.
Not a proposal. An instructional designer reads your task list and objectives and tells you where the chain holds and where it does not.
See how VISION, Qlarity, and Professional Services work
together to simplify compliance — and strengthen performance at every level.
©2026 FOCUS Learning Corp. All rights reserved. Privacy Policy