Short answer
A construction method statement describes how a specific piece of work will be done on a specific project: sequence, resources, plant, hazards and controls, and inspection points. It can ground task decomposition and hazard-aware planning. It is project-specific, records the plan and not the as-built result, and contains no motion data to train a robot's control.
What makes construction procedures different
Factory SOPs describe a repeated process in a controlled setting. A construction method statement describes a one-off: this concrete pour, this cladding install, this lifting operation, on this site, with these neighbors and this crane. The same contractor may write a different statement next month for a different site.
That changes what a buyer is purchasing. Instead of a canonical procedure, you obtain a population of plans that share structure and differ in parameters. For a robot-planning team, that structure is the asset: how skilled people break a trade task into sequence, what must be inspected before work proceeds, and which hazards trigger which controls. The wording is project-specific, but the pattern often recurs.
Naming varies by country and contract. Method statements, work plans, safe systems of work and risk assessment and method statement (RAMS) packs overlap, and a supplier may use any of them. Confirm what a document contains before judging it by its title.
What the documents usually contain
Contents vary by contractor and jurisdiction; the list below is typical, not a standard template.
- Scope and location. The work, the area and the interfaces with other trades.
- Sequence. Numbered steps, often with hold points where an inspection must pass before continuing.
- Resources. Labor roles, plant, tools and materials, sometimes with quantities.
- Hazards and controls. What can go wrong at each stage and the measures that apply.
- Permits and approvals. Hot work, confined space, lifting or excavation permits referenced by step.
- Inspection and test points. What is checked, by whom and against what specification.
- Emergency arrangements. Rescue, first aid and stop-work triggers; see exception and emergency procedures.
The hazard and control pairs overlap with job hazard analyses. When both exist for the same task, they cross-check each other, and differences are worth reading.
Aligning plans to a public vocabulary
Project-specific text is hard to compare across contractors. A public vocabulary of work tasks can serve as a shared index. The O*NET database includes Task Statements and Detailed Work Activities, and a mapping file links tasks to the activities; the project retains task statements only where the relevance rating is 25 percent or higher (O*NET Resource Center). Mapping each method-statement step to a Detailed Work Activity lets you ask questions such as which trades share a sub-task, or which activities are most covered by your corpus.
Be cautious about what that alignment achieves. O*NET is occupation-level, and a method-statement step may be finer than a work activity. Use the alignment to index and to find gaps, as in procedure coverage mapping and occupational task taxonomies, not as an assertion that the two are equivalent.
Illustrative structured record
The record is Illustrative; all values are synthetic.
# Illustrative: one step from a method statement, structured
statement_id: MS-proj_208-0017
trade: "drywall_install"
step: "5"
text_summary: "Fix boards to framing, staggering joints"
sequence_after: ["4"]
hold_point_before: false
resources: {roles: ["installer"], tools: ["screw_gun", "ladder"], materials: ["board_type_X"]}
hazards: ["working_at_height", "manual_handling"]
controls: ["platform_in_place", "two_person_lift_for_large_board"]
inspection: "framing_checked_before_boarding"
onet_dwa_ref: "DWA_mapped_by_annotator" # assigned during structuring
plan_vs_asbuilt: "plan_only"
The last field is easy to overlook. A statement approved before the work is an intention; it does not record what happened.
Evaluating a sample before you scope
Request three or four statements for the same trade from different projects and read them side by side. If the sequences are near-identical, the corpus is mostly a template and its volume overstates its variety; deduplicating procedures covers how to cluster such copies. If the sequences differ widely, find out whether that reflects real site differences or only different authors' habits.
Check hazards for specificity. A statement whose hazard column says "general site hazards" for every step carries little signal for hazard-aware planning, while one that ties a control to a particular step gives you a labeled pair. Also check whether inspection points name a criterion, since a hold point that says "inspect" without a standard cannot be turned into a success test.
What this data cannot support
Method statements cannot train a humanoid to build anything. They say a board is fixed to framing; they do not describe the grasp, alignment, force or posture involved, or how the board behaves when handled. A humanoid's control policy requires robot or teleoperation data, possibly supplemented with tracked human demonstration. SOP-style text alone cannot provide it.
Limits to expect:
- Plan versus practice. Site conditions change; crews improvise. Compare with deviation reports where available.
- Unstructured environments. Construction sites are often cluttered, changing and partly outdoor; a plan for a task does not describe the perception problem.
- Specification dependence. Many steps refer to drawings, specifications or standards that are not included in the statement.
- Safety responsibility. A hazard-and-control list is a planning aid, not evidence that a robot can operate near workers.
- Sparse sampling. A corpus may overrepresent trades the contractor performs and underrepresent others.
The adjacent marketplace category for project documents is described in construction project records; drawings and specifications there may complement method statements but carry their own rights.
Permissions and provenance
Method statements often contain client names, site addresses, subcontractor details and sometimes crew names. They may rely on a designer's drawings, a manufacturer's installation instructions or a client's safety rules, each with a different owner. A main contractor may not own a subcontractor's statement. Ask who authored each statement and who owns it; who owns a procedure develops the question. Removing names does not settle the right to license. This is not legal advice.
Questions to ask suppliers
- Are the statements written by the contractor, a subcontractor or a consultant?
- Do they include hold points and inspection criteria, or only sequence?
- Which statements are attached to drawings or specifications, and are those attachments in scope?
- How are hazards and controls recorded: tables, narrative or a separate risk assessment?
- Are as-built or completion records available for any of the same tasks?
- Which trades and project types are covered, and how many projects per trade?
- Which parts contain client, designer or manufacturer text that the contractor cannot license?
- Can site names, addresses and personnel be removed while keeping step and hazard structure?
If you want contractors approached about this, describe the trades and project types in a buyer request.
Discuss your requirements
Tell SourceX which trades, document types and rights terms matter to your program. SourceX reviews the requirement and follows up about potential sources among US businesses; a request does not guarantee a match. Construction data sits within the wider humanoid training-data section and the procedures hub; hierarchical task analyses show how to structure the steps once you have them.
Explore sourcing and licensing options with SourceX.
Sources
- O*NET Database: Task Statements and Detailed Work Activities — public task vocabulary and task-to-activity mapping.