Bill of Materials Extraction Prompt

This prompt is designed for manufacturing and integration engineers who need to convert unstructured Bill of Materials (BOM) text into a strict, typed JSON schema. The core job-to-be-done is building a reliable data pipeline that ingests BOMs from spreadsheets, legacy system exports, or technical specification documents and produces records safe for downstream PLM, ERP, or MRP systems. The ideal user is an engineer who understands BOM structure—parent-child assembly hierarchies, phantom assemblies, reference designators, and the distinction between a missing field and a field that is genuinely empty—and needs a prompt that enforces these distinctions programmatically rather than relying on post-processing cleanup.

Use this prompt when you have unstructured or semi-structured BOM text and need a predictable extraction contract. It handles the complexity that breaks naive extraction: a part number that appears in multiple assemblies with different quantities, a reference designator that applies to some instances but not others, a phantom assembly that should be flattened into its parent, and optional fields like revision or unit of measure that may be absent from the source. The prompt is built to produce output that can pass a JSON Schema validator before insertion into a database, with explicit null handling for fields the source does not provide and empty-string handling for fields the source provides but leaves blank. This distinction matters because downstream systems often treat a missing field as an error and an empty field as valid data.

Do not use this prompt for generating new BOMs, suggesting alternative parts, or performing design validation. It is an extraction and normalization tool only—it reads what exists and structures it. It will not catch engineering errors like a part number that does not exist in your master data or a quantity that violates assembly rules. Those checks belong in application-layer validation after extraction. Do not use this prompt when the source text is too ambiguous to resolve without domain expertise; if a human engineer cannot determine the parent-child relationship from the text, the model will guess, and guessing in a manufacturing pipeline creates costly errors. For high-stakes BOMs where an extraction error could cause a production line stoppage, always route low-confidence extractions to a human review queue and log the original source text alongside the extracted record for auditability.

The following prompt template is designed to extract a structured Bill of Materials (BOM) from raw text. It instructs the model to identify parts, their hierarchical relationships, quantities, units of measure, and revision data while explicitly handling null fields for optional attributes like reference designators. The template uses square-bracket placeholders that you must replace with your specific input data, output schema requirements, and operational constraints before use.

textCopy
You are a manufacturing data extraction system. Your task is to parse the provided text and output a structured Bill of Materials (BOM) as a JSON object.

## Input Text
[INPUT]

## Output Schema
Produce a JSON object conforming to this exact structure. Do not include any text outside the JSON object.
{
  "bom_name": "string | null",
  "parts": [
    {
      "part_number": "string",
      "description": "string",
      "quantity": "number",
      "unit_of_measure": "string (e.g., EA, M, KG, L)",
      "revision": "string | null",
      "reference_designators": ["string"] | null,
      "parent_part_number": "string | null",
      "is_phantom_assembly": "boolean"
    }
  ]
}

## Extraction Rules
1.  **Hierarchy:** Use `parent_part_number` to link a child part to its immediate assembly. The top-level assembly should have a `null` parent.
2.  **Phantom Assemblies:** If a sub-assembly is described as transient or not stocked, set `is_phantom_assembly` to `true`. Otherwise, `false`.
3.  **Null Handling:** If a field like `revision` or `reference_designators` is not present in the text, set its value to `null`. Do not hallucinate values.
4.  **Quantity:** Extract the numeric quantity. If a quantity is described as "AR" (As Required), set the value to `-1`.
5.  **Unit Normalization:** Normalize common units to a standard abbreviation (e.g., "pieces" -> "EA", "kilograms" -> "KG").

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

To adapt this template, replace the placeholders with your concrete data. [INPUT] should be your raw BOM text. [CONSTRAINTS] can be used to add domain-specific rules, such as "Ignore parts with a 'DEPRECATED' flag" or "Map all vendor names to their three-letter codes." The [EXAMPLES] placeholder is critical for teaching the model the desired behavior for edge cases like phantom assemblies or "AR" quantities. Start with 2-3 few-shot examples that pair a text snippet with its correct JSON output.

Before deploying this prompt into a production pipeline, you must add a validation layer. The model's JSON output should be validated against the defined schema to catch missing required fields or type errors. For high-stakes manufacturing data, implement a human review step for any record where a required field like part_number is null or where the quantity is -1, flagging it for manual clarification. This prompt is a starting point; its reliability will depend on the clarity of your input text and the quality of your few-shot examples.

The Bill of Materials extraction prompt is designed to sit inside a structured ingestion pipeline, not as a standalone chat interaction. The typical integration pattern is: receive raw BOM text from a file upload, ERP export, or API payload; assemble the prompt with the text inserted into the [BOM_TEXT] placeholder; send the request to the model; validate the returned JSON against the expected schema; and route the output to a downstream system or a human review queue. Because BOM data feeds directly into procurement, inventory, and production planning systems, the extraction pipeline must treat every field as potentially wrong until validated. The prompt itself handles null fields, parent-child hierarchy assembly, and phantom part detection, but the application layer owns schema enforcement, confidence thresholding, and the decision to escalate.

Validation and schema enforcement. Before any extracted record reaches a downstream system, validate the model's output against a strict JSON schema. Required fields such as part_number, description, and quantity must be present and non-null for every line item. Optional fields like reference_designator and revision can be null, but their types must match the expected schema (string or null, not an empty object or a number). Use a JSON Schema validator at the application layer—do not rely on the model to self-correct without a validation gate. If validation fails, capture the specific schema errors and feed them into a repair prompt or a retry loop. For BOM extraction, common validation failures include missing unit_of_measure on child items, malformed parent_part_number references that don't match any item in the extracted list, and quantity fields that are strings instead of numbers. Your validator should also check referential integrity: every parent_part_number value must resolve to a part_number present in the same BOM, and top-level assemblies should have parent_part_number set to null.

Retry and repair strategy. When validation fails, implement a two-stage recovery pattern. First, send the original BOM text plus the validation error messages back to the model with a repair instruction: 'The previous extraction failed schema validation with the following errors. Return a corrected JSON object that satisfies the schema.' This repair prompt should include the full schema definition and the specific field paths that failed. If the repair attempt succeeds validation, proceed. If it fails again, or if the model returns low confidence on critical fields like part_number or quantity, escalate to a human review queue. Do not retry more than twice—beyond two attempts, the failure mode is usually ambiguous source text that requires human judgment, not a better prompt. Log every extraction attempt, validation result, and repair outcome for auditability. For high-volume BOM ingestion, track extraction success rates by supplier or source format to identify patterns that need prompt tuning or preprocessing.

Model choice and performance considerations. This prompt works best with models that have strong JSON mode or structured output capabilities. Use a model that supports guaranteed schema adherence (such as GPT-4 with structured outputs or Claude with tool-use mode) rather than relying on prompt-level format instructions alone. The BOM extraction task benefits from models with large context windows when processing multi-level assemblies with dozens of line items. For cost-sensitive pipelines, consider routing simple flat BOMs (no parent-child hierarchy) to a smaller, faster model and reserving the larger model for deeply nested BOMs with phantom assemblies. Always set temperature to 0 or near-zero for extraction tasks—variability in part numbers or quantities is a defect, not a feature. If your pipeline processes BOMs in batch, implement rate limiting and exponential backoff to handle API throttling without data loss.

Human review integration. Build a review queue for records that fail validation after retries, have low confidence scores on safety-critical fields, or contain phantom assembly references that the model flagged but couldn't fully resolve. The review interface should display the original BOM text alongside the extracted JSON, with validation errors and confidence flags highlighted. Reviewers should be able to correct fields, approve the extraction, or reject the record and flag the source text as unparseable. Track review decisions to build a feedback dataset for future prompt improvements or fine-tuning. For regulated manufacturing environments, require human approval on every BOM before it enters the production system—the prompt and validation pipeline reduce review time, but they don't eliminate the need for sign-off when part errors have safety or compliance consequences.