Field Description Prompt for Product Catalogs

This prompt is designed for e-commerce and product operations teams that need to generate structured, consistent product catalog entries from unstructured or semi-structured source data. It binds each output field to a precise description, example, and constraint so the model produces records that downstream parsers, databases, and storefronts can consume without manual cleanup. Use this prompt when you are ingesting supplier spreadsheets, migrating legacy catalogs, or normalizing product data from multiple sources into a single schema. The ideal user is an engineer or product data manager who controls the target schema and needs the model to act as a disciplined data formatter, not a creative copywriter.

This is not a prompt for generating marketing copy or creative product descriptions. Its job is structural consistency and field-level discipline. Do not use it when the goal is persuasive language, brand voice development, or open-ended product storytelling. It is also not a replacement for a data validation pipeline; the prompt enforces output structure, but you must still validate units of measure, variant relationships, and referential integrity in your application layer. The prompt works best when paired with a defined JSON Schema, a set of allowed enum values, and a small number of few-shot examples that demonstrate tricky cases like multi-variant products or region-specific compliance fields.

Before using this prompt, define your target schema precisely. For each field, you should know its type, whether it is required, what format constraints apply (e.g., ISO 8601 dates, uppercase country codes), and what constitutes a valid value. If you cannot define these constraints, the model will guess, and guessing produces drift. Start with a small batch of 20-50 products, run the output through a schema validator, and review field-level accuracy before scaling to thousands of records. The next section provides the copy-ready prompt template you can adapt to your schema.

The following prompt template is designed to be placed in the system instructions or developer message layer of your AI application. It forces the model to generate structured product catalog entries where every field is explicitly defined, constrained, and exemplified. This reduces downstream parsing errors, unit-of-measure inconsistencies, and creative reinterpretation of field semantics that commonly break catalog ingestion pipelines.

textCopy
You are a product catalog data entry assistant. Your only job is to generate a structured product record from the provided source data. Follow every field description, constraint, and example exactly. Do not add fields, skip fields, or reinterpret field meanings.

## Output Schema
Generate a single JSON object with the following fields. Return ONLY the JSON object, no surrounding text, no markdown fences.

[OUTPUT_SCHEMA]

## Field Descriptions and Constraints
For each field in the schema, adhere to these rules:

[FIELD_DESCRIPTIONS]

## Source Data
Use only the following source data to populate the fields. If a field's value is not present in the source data, use null. Do not infer, guess, or hallucinate missing values.

[SOURCE_DATA]

## Critical Constraints
1. Unit of Measure: Every quantitative field must include its unit exactly as specified in the field description. If the source data uses a different unit, convert it to the required unit and note the conversion in the [CONVERSION_NOTES_FIELD] field.
2. Variant Handling: If the source data describes multiple variants of the same product, generate a separate record for each variant. Populate the [VARIANT_ATTRIBUTES_FIELD] field with the distinguishing attributes.
3. Null Handling: Use null for any field whose value cannot be determined from the source data. Never use placeholder strings like "N/A", "TBD", or empty strings.
4. Enum Adherence: For any field with a defined set of allowed values, select ONLY from that set. If the source data suggests a value outside the allowed set, set the field to null and add a note to the [FLAGGED_ISSUES_FIELD] field.
5. Confidence: If you are uncertain about the correct value for a field due to ambiguous or conflicting source data, set the field to null and document the ambiguity in the [FLAGGED_ISSUES_FIELD] field.

## Examples
Here are examples of correct output records:

[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with your specific configuration. The [OUTPUT_SCHEMA] should be a JSON Schema-like definition of your product record structure. The [FIELD_DESCRIPTIONS] should be a detailed breakdown of each field including its data type, allowed values, unit requirements, and an example value. The [SOURCE_DATA] is the raw product information you want to structure. The [EXAMPLES] should include at least one correct record and one edge case showing null handling for missing data. The optional [CONVERSION_NOTES_FIELD], [VARIANT_ATTRIBUTES_FIELD], and [FLAGGED_ISSUES_FIELD] placeholders should be replaced with the actual field names you define in your schema for those purposes. Before deploying, run this prompt against a golden dataset of known product records and validate that the output JSON parses correctly, all required fields are present, enum values are respected, and unit conversions are accurate.

The Field Description Prompt is designed to be called once per product field that needs enrichment, not once per product. In a typical catalog pipeline, you iterate over a list of field names extracted from your schema or data dictionary, calling the prompt for each field that lacks a description, example, or constraint. This per-field isolation keeps the prompt focused, reduces output variance, and makes validation failures easier to attribute and repair. The prompt expects three inputs: the field name, the product category context, and any existing catalog conventions the model should follow.

Wire the prompt into an application function that accepts a field record and returns an enriched field record. Before calling the model, validate that the field name is non-empty and that the category context is present. After receiving the output, run a structured validation pass: confirm that the description is between 20 and 200 characters, that the example value matches the field's expected data type, and that the constraint list contains at least one actionable rule. If validation fails, retry once with the specific validation error appended to the [CONSTRAINTS] placeholder. For high-volume catalogs, batch fields by category and use a single model call with a structured output schema to reduce latency, but keep per-field validation granular.

For regulated product categories such as supplements, electronics with safety ratings, or products with legal labeling requirements, route outputs through a human review queue before they land in the catalog database. Log every prompt version, input hash, output, and validation result so that field descriptions are auditable back to the model and prompt that generated them. Avoid using this prompt for fields that require precise regulatory language—those should be authored by domain experts and treated as source-of-truth records, not AI-generated content.