Short answer
A hierarchical task analysis (HTA) breaks a job into goals, sub-goals and operations, with plans that say when each applies. Human factors and ergonomics teams already produce them for training, job aids and error prediction. They give a buyer a validated task hierarchy and often performance notes, but they hold no motion, force or perception data and vary widely in rigor.
The buyer's problem
Most procedure corpora are flat lists of steps. Planning research needs hierarchy: a goal such as "replace filter" decomposes into sub-goals, each with ordering rules, conditions and termination criteria. Producing that decomposition from scratch with annotators is slow and subjective. Human factors teams have often done the work already, by observing workers, interviewing them and writing the result down.
HTA is a well-established method. A review in Applied Ergonomics describes it as a core ergonomics approach with more than 30 years of continuous use, originally developed to identify training needs, with applications including interface design and evaluation, allocation of function, job aid design, error prediction and workload assessment (Stanton, 2006). That history is why files exist at employers, consultancies and universities. This page covers finding and evaluating them. To derive graphs from ordinary SOPs instead, see task graphs from procedures.
What an HTA file holds
A typical analysis contains:
- A top-level goal and a numbered hierarchy beneath it (1, 1.1, 1.1.1).
- Plans attached to each node, stating order and conditions: do 1.1 then 1.2; repeat 1.3 until the gauge reads in range; if the part is damaged, go to 2.
- Stopping rules. The level at which decomposition ended, judged by the cost of further detail or the risk of error.
- Task conditions and context. Who performs it, with what equipment, in what environment and at what frequency.
- Annotations. Error-prone steps, workload notes, information required, training needs or hazards.
Files appear as diagrams, indented outlines, tables or spreadsheets, sometimes inside a larger study report. A single analysis often supports a training package, so it may sit next to a job hazard analysis or a competency record.
What this data can support, and what it cannot
HTA can support:
- Task decomposition research. Expert-built hierarchies are a reference against which to compare model-generated decompositions.
- Planning representations. The plan notation, with sequences, selections and loops, maps onto task graphs and behavior-tree-style structures.
- Step granularity decisions. The stopping rule shows where a human analyst judged that more detail was unnecessary; this is useful when choosing step granularity.
- Evaluation items. Questions such as "which sub-goal must precede X" have an expert answer.
- Annotation guides. A hierarchy can seed labels for video; COIN, for instance, annotates instructional video with a hierarchical structure and step descriptions with temporal boundaries (Tang et al., 2019). HTA nodes could be aligned in a similar way, but that alignment is a separate project.
It cannot support:
- Robot actions or physical control. HTA ends at operations described in human terms, such as "seat the cover". It records no joint motion, forces or sensor data.
- A robot-executable plan. Plans assume a human's perception and judgment. "Check that it looks right" is a stopping rule, not a perception test.
- Full task coverage. Analyses are done for chosen tasks, often problematic or safety-relevant ones, not for the whole job.
- Evidence of current practice. An analysis reflects the system when it was studied.
- Timing precision. Timing data, if any, may be rough; motion-level timing comes from predetermined motion time analyses, which are a different asset.
Who holds them
| Holder | Why they exist | What to expect |
|---|---|---|
| Employers with human factors or ergonomics staff | Training design, workstation redesign, incident review | Internal documents, mixed formats |
| Industrial engineering and EHS consultancies | Client studies | Report-embedded, consultancy-owned |
| Safety-critical operators | Procedure design and error analysis | Rigorous, often confidential |
| Training departments | Curriculum development | Task lists with competency criteria |
| Universities and research groups | Studies of tasks and interfaces | Published or study-specific; permissions vary |
Rights are an issue here more than for ordinary SOPs. A consultancy may own the analysis even though the employer owns the site, and a study may have been done under participant consent that did not anticipate model training. The who owns a procedure page lays out the ownership questions.
Illustrative package
# Illustrative - synthetic values
package: hta_set_v0
analyses:
- hta_id: hta_0044
top_goal: "Replace inlet filter on unit_type_M"
format_source: spreadsheet
node_count: "buyer-recorded"
nodes:
- id: "1"
label: "Isolate unit"
plan: "do 1.1 then 1.2 then 1.3"
- id: "1.2"
label: "Verify zero energy"
plan: "repeat until indicator off, max 3 attempts, else escalate"
stopping_rule: "risk of omission high; decompose further"
error_notes: ["skips verification when hurried"]
context: {actors: 1, tools: [wrench_set_A], environment: indoor_plant_floor}
linked_video: [clip_0312, clip_0313] # only if recorded and licensed
study_method: [observation, interview, document_review]
analyst_id: analyst_03
date_range: "synthetic"
rights:
document_owner: employer_X
analysis_owner: consultancy_Y
participant_consent_scope: "internal training"
Evaluating an offered set
Check the method first: was the analysis built from observation of real work, from interviews, or from reading the SOP? An HTA derived only from a procedure adds little beyond the SOP. Check plans: analyses with only a numbered outline and no plans lose ordering logic. Check consistency: nodes at the same level should be of comparable scale. Check validation: was the hierarchy reviewed by workers or supervisors? Check linkage: can nodes be tied to procedure steps, video or work orders? Without linkage, the analysis is a standalone reference.
Because analyses vary in notation, plan to normalize them into one schema. The procedure step schema and occupational task taxonomies pages cover target structures.
Limitations and additional preparation
- Small volume. An employer may hold a handful of analyses. This is a quality asset, not a bulk one.
- Notation drift. Different analysts use different plan syntax and numbering; normalization is manual work.
- Redaction. Employee names, error narratives and incident references need removal; recorded video of the analyzed task requires consent review.
- Alignment effort. Linking nodes to video or steps requires annotators who know the work.
- Decision logic. Branches in plans must be captured explicitly; see branching procedures and decision points.
- Bias toward problem tasks. Analyses are commissioned where something went wrong or needed training, so coverage skews toward difficult or risky work.
Questions to ask suppliers
- Who performed each analysis, using what method, and was it validated with workers?
- Do the files include plans, stopping rules and error or workload notes?
- What format are they in, and is there a consistent numbering scheme?
- Was video, photo or sensor data collected during the study, and under what consent?
- Who owns the analysis: the employer, a consultancy or a university?
- Do the participants' agreements permit model training use?
- How many distinct tasks and sites are covered?
- Have the analyses been updated since the process changed?
How HTA files relate to other procedure assets
An HTA sits between a job description and a step-level SOP. A job description names duties; the SOP lists actions in order; the HTA explains how goals decompose and when to use which branch. Buyers who already hold an SOP corpus gain most from HTAs when they cover tasks where the SOP is thin, such as diagnosis or setup with several possible routes. Where the HTA and an SOP for the same task both exist, comparing them is itself informative: differences show steps the SOP omits or ones that analysts judged riskier than the SOP implies.
In practice, a first request should name two or three tasks and ask suppliers whether any analyses exist for them, instead of requesting all analyses. Ask to see one sample redacted file per task. That limits effort for the supplier and lets you judge whether plans and stopping rules are present before negotiating a larger set.
Discuss your requirements
If you need expert-built task hierarchies for particular workplace tasks, describe the tasks and permitted uses to SourceX. SourceX looks for US businesses that hold the material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX follows up about potential sources. See the humanoid training data guide and the procedures hub for the wider picture. The catalog page on SOPs and playbooks describes the nearby document category.
Explore sourcing and licensing options with SourceX.
Sources
- Hierarchical task analysis: Developments, applications, and extensions — HTA history, origin and applications.
- COIN: A Large-scale Dataset for Comprehensive Instructional Video Analysis — hierarchical step annotation of instructional video.