Short answer
A data center method of procedure is a pre-approved, step-by-step change document, usually with prerequisites, a verification step after each action and a back-out plan. It is a dense source of ordered, checkable physical steps such as swapping a drive or re-cabling a rack. It gives task structure and success criteria, not motion data, and it is often security-sensitive.
The buyer's problem
Teams exploring humanoids for structured indoor facilities often start from the same question: where is there a large body of physical procedures written precisely enough to plan against? Data centers are a candidate because change control forces operators to write down what will be done, in what order, with what check afterward, before anyone touches equipment.
A method of procedure (MOP), sometimes called a runbook when it covers recurring operations, is that document. The buyer's job is to find out which MOPs involve physical manipulation, how detailed they are, and whether an operator can license them at all. This page covers the document type. For the broader question of what procedures can teach a robot, see what SOPs can and cannot teach a humanoid.
What a MOP contains
Structures differ by operator, but a typical physical-change MOP includes:
- Scope and purpose. The change, the affected systems and the maintenance window.
- Prerequisites. Approvals, spare parts on hand, tools, permits, personnel roles and a read-through of the document.
- Pre-checks. Evidence that the system is in the expected state before work starts, for example redundant power confirmed on the second feed.
- Numbered steps. Each with an actor, an action, a target identifier such as a rack or port label, and an expected result.
- Verification points. Indicator states, link lights, monitoring readings or a second person's confirmation.
- Back-out plan. The conditions that stop the work and the steps that restore the prior state.
- Sign-off. Who executed, who verified, timestamps and any deviation noted.
This is close to the structure formal technical publication standards impose. S1000D, for example, defines stand-alone data modules of descriptive, procedural or operational data identified by a unique code and stored in a common source database (S1000D). A MOP is usually less formal, but the same ideas, discrete units with identifiers and defined outcomes, make it easy to convert into a schema; see the procedure step schema.
Physical content versus software content
Many MOP steps are not physical. A change may be mostly console commands, configuration pushes and monitoring checks. A buyer interested in manipulation should ask for a breakdown by step type before licensing a corpus.
| Step type | Example (synthetic) | Value for embodied planning |
|---|---|---|
| Physical manipulation | Unlatch and withdraw drive tray at bay 7 | High: object, action, target |
| Physical verification | Confirm amber indicator is off | High: visual success check |
| Navigation / access | Badge into cage, proceed to row 14 | Medium: location and order |
| Tool use | Torque cage-nut fastener, then inspect seating | Medium: tool and part named, no force data |
| Software / console | Run diagnostic, confirm status | Low for manipulation; useful for agents |
| Coordination | Notify operations desk, wait for go | Medium: dependencies and gating |
Operators who run a mix of staffed and remote-hands services may hold many short physical MOPs, for example swap-and-verify tasks, alongside long software-heavy ones. Cataloging steps by type in a sample is the fastest way to estimate usable volume.
What this data can support, and what it cannot
MOPs can support:
- Instruction grounding and step decomposition, because steps are atomic, ordered and carry an expected outcome.
- Precondition and postcondition modeling, since pre-checks and verifications are explicit; see preconditions and postconditions.
- Failure and rollback structure, from the back-out plan, which links to exception and emergency procedures.
- Formal task representations. Ordered steps with verification and fallback map naturally onto behavior trees, which structure switching between tasks in an agent (Colledanchise and Ogren, 2017).
- Evaluation sets that ask whether a planner puts steps in a safe order or omits a verification.
Procedures for a single piece of equipment, such as a UPS or a cooling unit, overlap with equipment operating procedures; a MOP differs by being a one-off change plan with approval and back-out.
They cannot support:
- Physical control. There is no hand trajectory, grasp, force profile or sensor stream. The MOP says "withdraw the tray" and nothing about how.
- Proof that practice matches the document. Technicians often work from experience; the written steps may omit shortcuts and fixes. Completed MOPs with sign-offs and deviation notes are closer to practice than blank templates.
- Perception. Rack labels, cable colors and indicator appearances are described, not shown, unless images are attached.
- Generalization to other facilities. A procedure tied to one vendor's chassis and one operator's labeling scheme transfers poorly.
Combining MOPs with recorded demonstrations of the same tasks is a separate collection effort; the SOP-to-video step alignment page explains the alignment work, and the maintenance data hub covers hands-on repair data.
Illustrative package: MOP corpus prepared for planning research
# Illustrative - synthetic identifiers
package: dc_mop_physical_v0
document_count: "buyer-defined sample"
per_document:
mop_id: mop_0192
revision: "B"
change_class: standard # standard | normal | emergency
step_types_present: [physical, verification, access, software]
steps:
- n: 4
actor_role: technician
action: "withdraw drive tray"
target_label: "rack_R14/bay_07" # label scheme kept, site names removed
expected_result: "tray released; amber indicator off"
verification: second_person
back_out_trigger: "indicator remains amber after reseat"
executed_record: false # blank template vs completed with sign-off
redaction:
removed: [tenant_names, ip_ranges, badge_ids, floor_plans]
kept: [step_structure, label_scheme, expected_results]
Redaction and security
Data center procedures carry information operators protect: tenant identities, network addressing, physical layout, access controls and alarm behavior. A single MOP can reveal where critical equipment sits and how to reach it. Expect operators to remove or generalize these fields, and expect some documents to be withheld entirely.
Redaction reduces what the data can teach: replacing every location with a token removes the navigation signal, and removing expected results removes the success criteria. Ask what was removed and keep the removed-field list in the delivery notes. See redacting SOPs.
Existing versus commissioned
Existing MOPs are the realistic route for text. They are already written, already approved and often already in a document system. Commissioning new MOPs defeats the point, since the value is that they were written for real changes. The commissioned route that does make sense is capture: recording technicians performing a documented MOP under a designed plan, which belongs to the demonstrations cluster and requires consent and site access. Whether an operator would allow cameras in a secured hall is a diligence question, not an assumption.
Questions to ask suppliers
- How many MOPs involve physical manipulation, and what share are software-only?
- Are the documents blank templates, completed records with sign-offs, or both?
- Do steps carry stable identifiers and expected results?
- Which fields were removed for security and tenant confidentiality, and is the list documented?
- Do MOPs reference vendor manuals or other documents that are not part of the license?
- Are revisions and superseded versions retained?
- Were any MOPs authored by a customer, a vendor or a contractor rather than the operator?
- Are photos or diagrams attached, and are they covered by the same rights?
- Who can authorize licensing: facilities, security, legal or the customer?
Permissions and provenance
Operators frequently work under contracts that restrict disclosure of customer environments, and some procedures derive from equipment vendors' proprietary guidance. Ask whether tenant agreements permit licensing even redacted material, and whether vendor-derived text can be included. This is not legal advice. Redaction lowers exposure but does not by itself settle who may license the underlying document. See who owns a procedure.
Discuss your requirements
If you are looking for structured physical procedures from controlled facilities, describe the task types, document form and permitted uses to SourceX. SourceX looks for US businesses that hold the material you describe, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. Whether a data center operator can supply is not known in advance, and a request does not guarantee a match; SourceX follows up about potential sources. For the wider map, see the humanoid training data guide and the procedures hub. The catalog page on internal documentation describes the general category.
Discuss your humanoid training-data requirements with SourceX
Sources
- S1000D International specification for technical publications using a common source database — stand-alone, coded procedural data modules in a common source database.
- Behavior Trees in Robotics and AI: An Introduction — behavior trees structure switching between tasks.