Extracting Parameters, Tolerances and Units From Procedures

The buyer's problem

A procedure that says "tighten to 12 N·m, then verify gap 0.5 +0.2/-0.1 mm" looks like clean data. In a corpus of several thousand documents it is not. The same quantity appears as "12Nm", "106 in-lb", "approx. 9 ft-lb" or "hand tight, then a quarter turn". Tolerances are written as symmetric, one-sided, ranges, percentages or words. Tables repeat a parameter per variant, and footnotes override the table.

A model that plans against these numbers, or an evaluation set that checks whether a planner respected them, needs them as typed fields. Free text forces every downstream user to re-parse. This page describes a deliverable a buyer can specify and test. For the surrounding step structure, see the procedure step schema; this page covers only the numeric layer inside it.

What parameter data can support, and what it cannot

Typed parameters can support:

• Constraint-aware planning. A planner that knows a part must reach a temperature before the next step can order or gate steps correctly.
• Procedural evaluation sets. Questions such as "which step has the tightest tolerance" or "does this plan violate a stated limit" have checkable answers.
• Retrieval and grounding. Structured values make it possible to retrieve the exact limit for a named component rather than a paragraph near it.
• Success criteria. Parameters with tolerances are the numeric half of a postcondition; the preconditions and postconditions page covers the logical half.

They cannot support:

• Physical control. A torque value is a target, not a force trace. It says nothing about how a hand reaches the fastener, how the tool seats, or how a gripper modulates force. Control needs robot-specific observations, actions and, for contact tasks, force or tactile signals.
• Proof of practice. A documented tolerance is what the organization says should happen. Whether operators actually hit it is a separate question; the tacit knowledge gaps in SOPs page explains why.
• Measured values. A procedure carries a specified value, not a measured one. Records of measured results live in quality records, covered under manufacturing quality records.

Where numbers hide

Before pricing extraction, sample the corpus and count where parameters sit. Typical locations are the step text, a parameter table at the top of the document, a warning box, a figure callout, a footnote, a revision-change note and an appendix of variants. Layout-aware parsing is usually needed: the DocLayNet benchmark annotates 11 layout classes across 80,863 manually annotated pages, including a manuals category (Pfitzmann et al., 2022); tables, captions and footnotes generally need to be separated from body text before fields can be read reliably. Scanned sources add OCR error on top; see parsing scanned manuals.

Some sources arrive already structured. S1000D data modules are stand-alone units of procedural data stored in a common source database and identified by a data module code (S1000D), so parameters may already sit in XML elements. The preparation question there is mapping, not parsing.

Illustrative parameter record

All values below are synthetic.

# Illustrative parameter record
parameter_id: P-000417
doc_id: doc_0231
revision: "C"
step_id: "6.3"
step_text_span: {page: 14, bbox: [72, 310, 520, 346]}
subject: "bracket_fastener_A"          # what the value applies to
quantity_kind: torque                   # from a controlled list
value: 12.0
unit: "N*m"                             # normalized unit
original_string: "106 in-lb"            # exactly as printed
original_unit: "in-lb"
conversion: {factor: 0.11298, rule_id: "u-torque-03"}
tolerance:
  form: bilateral                       # bilateral | unilateral | range | percent | verbal | none
  lower: -0.6
  upper: 0.6
  basis: "stated"                       # stated | inferred | default_from_doc_note
condition: "dry thread, ambient 15-30 C"
applies_to_variants: ["model_X1", "model_X2"]
source_kind: step_text                  # step_text | table | warning | footnote | figure
confidence: 0.93
review: {status: double_keyed, reviewer: reviewer_07}

Three design choices matter. The original string is retained so any conversion can be audited. The tolerance has an explicit basis, because a tolerance supplied by a document-wide note is different from one printed beside the value. And applies_to_variants stops a table-per-model value from being attached to every model.

Unit normalization rules to specify

Ask the supplier to publish a conversion table and a controlled list of quantity kinds. At minimum:

Normalization should never overwrite the printed value, and it should never guess a unit that is missing. A bare "12" with no unit is stored with unit: null and a flag.

Acceptance tests a buyer can set

• Round-trip check. Render the structured record back to text and compare with the source span. Mismatches in value or unit are errors, not warnings.
• Double-key sample. Have two independent reviewers key a random sample of pages and compare with the extracted set. The sample size and the acceptable disagreement rate are the buyer's call, set per document class.
• Unit audit. Every non-target unit in the corpus appears in the conversion table; every conversion has a rule ID.
• Tolerance coverage. Report, per document, the share of numeric parameters with form: none. A high share can mean the document is loose, or that the extractor missed a note.
• Variant integrity. For multi-variant tables, spot-check that values land on the correct variant.
• Held-out split. If the records will feed an evaluation set, split by document family or site, not by row, so near-duplicate documents do not leak across train and test.

Automated extraction with a language model is common here; the validating LLM-extracted procedure steps checklist covers how to test it. General dataset-quality frameworks, such as the ISO/IEC 5259 series, are a vocabulary for reporting, not a shortcut for these checks.

Limitations and additional preparation

• Interpretation is not extraction. "Torque to specification" points to another document. Resolving references requires linking documents, which may be outside the licensed set.
• Context-dependent values. A tolerance may hold only at a stated temperature or for a specific lot. If the condition is lost, the number misleads.
• Superseded values. Without revision metadata, old and new limits mix. Pair this work with revision history where it exists.
• Redaction cuts value. Suppliers often want exact parameter values removed as trade secrets. Keeping the structure, units and tolerance form while masking values still supports many language and planning tasks, but not evaluations that depend on the true number.
• No physical grounding. Linking a parameter to a video segment or sensor stream is a separate alignment job; see SOP-to-video step alignment.

Permissions and provenance

Parameters are often the most commercially sensitive part of a procedure: they encode process know-how. Ask who owns the document, whether it contains customer- or vendor-supplied specifications, and whether the supplier may license derived structured records as well as the original text. Anonymizing names does not settle ownership of the underlying numbers. This is not legal advice; involve counsel on trade-secret and third-party content questions. See redacting SOPs for what is typically removed.

Questions to ask suppliers

1. Which document classes are in scope, and what share is native digital versus scanned?
2. Is there a controlled list of quantity kinds and a published conversion table?
3. Is the original printed string stored beside every normalized value?
4. How are tolerances without a printed form recorded, and what does basis show?
5. How are multi-variant tables mapped to variants?
6. What was double-keyed, by how many reviewers, and what was the disagreement rate?
7. Which parameters were masked for confidentiality, and is the mask documented per field?
8. Can each record be traced to a page and region of the source?
9. Are revision identifiers retained so superseded values can be excluded?

Discuss your requirements

If you are specifying a numeric layer for procedural data, describe the document types, quantity kinds and permitted uses to SourceX. SourceX looks for US businesses that may hold suitable procedures, checks the data and the supplier's licensing permissions, and coordinates the license and delivery; parsing and annotation are scoped case by case. A request does not guarantee a match, and SourceX follows up about potential sources. For the wider map, start at the humanoid training data guide or the SOPs and procedural data hub. The catalog entry on SOPs and playbooks describes the general document category.

Discuss your humanoid training-data requirements with SourceX

Sources

• DocLayNet: A Large Human-Annotated Dataset for Document-Layout Analysis — 11 layout classes, 80,863 annotated pages, manuals category.
• S1000D International specification for technical publications using a common source database — data modules as structured procedural units.
• MTM ASSOCIATION e. V. (Methods-Time Measurement) — TMU as a domain unit needing conversion.
• ISO/IEC 5259-1:2024 Artificial intelligence - Data quality for analytics and machine learning (ML) - Part 1: Overview, terminology, and examples — data-quality framework and terminology.