JHWiggins/logistics_golden_development_pilot

Logistics Golden Set Development Pilot

About This Dataset

The goal was to come up with an initial 15 logistics scenarios that will be used to conduct experiments around SFT and RL of models. This dataset is purely taking standard logistical processes and breaking them down into individualized steps. Anyone is welcome to use this dataset as they see fit, there will be others made in the future to build this out even further. My socials are available on my profile for any questions or opprotunities.

Annotation Conventions

• —Single participant: Each example represents one human operator or one autonomous participant. Human-operated equipment is recorded as equipment, not as a separate actor.
• —Ordered steps: Steps follow process order. Action wording may vary while preserving the same operational meaning.
• —Step-specific process units: Each step defines its own reference unit, such as a pallet, trailer, tote, or route. Different units may coexist within one process.
• —Quantities: A dictionary records supported physical quantities and action counts. Repeated scans can be consolidated using scans; repeated step executions can use cycles. Physical quantities describe each execution and should not be multiplied by the cycle count twice.
• —Frequency: Frequency represents the proportion of a step’s process units on which the action occurs. Repetition belongs in quantities. Unknown frequencies remain null.
• —Alternative outcomes: Described alternatives use separate, outcome-qualified actions. Known outcome proportions determine frequency; unknown proportions remain null. Mutually exclusive alternatives are not interpreted as sequential work on the same item.
• —Warehouse motion: Travel follows a rectilinear convention with efficient 90° or 180° turns. This is a project modeling assumption, not a claim about every warehouse layout.
• —Scan timing: When confirmation scanning is established but timing is unspecified, physical pickup precedes pickup confirmation and placement precedes placement confirmation. Explicit source timing overrides this default.
• —Rack positioning: Unspecified rack levels are represented through positioning at pickup/placement height and travel height, without inventing numeric heights or adjustment directions.
• —Execution mode and equipment: Scanning, driving, display reading, and pushing carts use human_operated_equipment. Mounting/dismounting is manual. Passive jig positioning remains manual with the jig recorded. Powered dock-door controls use human_operated_equipment with dock_door.
• —Missing information: Unsupported values are not invented. Empty quantities ({}) mean no quantity was extracted, not zero. Equipment null means unspecified; [] means explicitly none.

Limitations

• —Development pilot: This release contains 15 human-authored examples and 129 annotated steps. The examples informed annotation-rule development and are not an untouched test set.
• —Review scope: Labels received AI-assisted consistency review under the author's domain judgment. Independent annotator agreement has not been established.
• —Limited coverage: The dataset does not establish coverage of all logistics processes, equipment types, writing styles, or operational exceptions.
• —Single-participant scope: Multi-operator coordination, handoffs, and joint work are outside the current experiment.
• —Flat process representation: Explicit loop boundaries and branch relationships are omitted. Adjacent steps with equal cycle counts do not necessarily belong to the same loop. Detailed control flow may require the original text or a future schema extension.
• —Mixed-unit conversion: Converting per-tote, per-pallet, or per-route work into a common basis may require additional information. A frequency of 1 does not imply those conversion quantities are known.
• —Downstream engineering: Travel distances, numeric placement heights, MTM/MOST calculations, labor standards, and optimization are outside the output scope.
• —Project-specific conventions: Annotations follow the documented modeling rules; they should not be interpreted as universal industry standards.
• —Validation boundary: Parser validation confirms structural requirements, not operational correctness. No model performance or generalization claim is established by this dataset release.